This chapter explains how to configure security for Oracle Exadata System Software.
This chapter contains the following topics:
Oracle Exadata System Software data security is implemented by controlling which Oracle Automatic Storage Management (Oracle ASM) clusters and database clients can access specific grid disks on storage cells. By default, all database and Oracle ASM instances have access to all storage cell grid disks.
To set up security so that all database clients of an Oracle ASM cluster have access to specific grid disks, configure Oracle ASM-scoped security.
To set up security so that specific database clients of an Oracle ASM cluster have access to specific grid disks, configure database-scoped security.
To have consistent Oracle Exadata System Software security, ensure the following:
All grid disks that belong to the same Oracle ASM disk group have the same cell-side grid disk security defined to avoid confusion and errors.
All Oracle Real Application Clusters (Oracle RAC) servers in an Oracle ASM cluster have the same content, ownership, and security for the Oracle ASM
All Oracle RAC servers in a database cluster have the same content, ownership, and security for the database
If database-scoped security is implemented, then ensure it is implemented for all databases accessing the grid disks. Do not mix Oracle ASM-scoped security and database-scoped security.
While setting up security, it is imperative that the configuration is the same across cells. Using the dcli utility to make configuration changes ensures consistency by eliminating the potential of user errors.
Oracle Exadata System Software security allows open security, Oracle ASM-scoped security, or database security. The following sections describe each mode:
To implement security, you must establish a security key.
Open security mode enables access by any database client to a grid disk. Open security mode is useful for test or development databases where there are no security requirements. This is the default security mode after creating a new storage cell.
To use this security mode, you do not set up any security functionality for an Oracle ASM cluster or a database client for the grid disk. You do not set up any security key files.
Oracle ASM-scoped security mode enables access by all the database clients of an Oracle ASM cluster to grid disks on cells.
Oracle ASM-scoped security is appropriate when you want all databases on a host cluster to have access to the cell grid disks in the Oracle ASM disk groups managed by the Oracle ASM cluster. This includes the case when there is only one database in an Oracle ASM cluster.
When Oracle ASM-scoped security is set up for an Oracle ASM cluster and grid disks, the grid disks are available only to the databases on the Oracle ASM cluster.
Starting with Oracle Exadata 188.8.131.52.0, you can define Oracle ASM-scoped security based on ASM clusters. Once you have set up your ASM clusters, you can use the same database unique name in one or more clusters. Within each ASM cluster, the database names still have to be unique. The ASM cluster name is used to qualify the database unique name.
Database-scoped security mode configures access to specific grid disks on cells for specific database clients of an Oracle ASM cluster.
Database-scoped security mode is appropriate when multiple databases are accessing cells, and you want to control which databases can access specific grid disks that compose Oracle ASM disk groups. Set up Oracle ASM-scoped security for your initial security mode, then set up database-scoped security for specific database clients and grid disks. After setting up database-scoped security among the database clients and grid disks, only those specific grid disks are available to the specified database clients.
When using database-scoped security, there is one key file per database per host, and one access control list (ACL) entry per database on each cell.
The security of the operating system on Oracle Exadata Storage Servers consists of the following:
Enforcing security policies
Protecting network access paths to the cells
Monitoring operating system-level activities
Oracle Exadata System Software includes security features to ensure the operating system and network access to the Oracle Exadata Storage Servers are secure.
User access to the operating system can be secured by the use of secure, hardened passwords. The passwords for users who administer Oracle Exadata Storage Server Software adhere to the following security guidelines:
Passwords must be changed every 90 days.
Passwords cannot be changed within 24 hours of the last change.
Passwords must use at least three character classes. Character classes for passwords are digits, lowercase letters, uppercase letters, and other characters.
Minimum password length is 12 characters when using three character classes. Minimum password length is 8 characters when using four character classes.
Uppercase letters at the beginning of the password, and digits at the end of the password are not counted when calculating the number of character classes.
Passphrases are allowed. A passphrase should contain at least three words, be 16 to 40 characters in length, and contain different character classes.
Maximum password length is 40 characters.
A new password cannot be similar to the existing password.
A user account is temporarily locked for 10 minutes after one failed login attempt.
A user account is locked after five failed attempts.
A log in session will terminate after 14400 seconds of no input.
An SSH session will terminate after 7200 seconds of inactivity.
Users are notified of the need to change their passwords 7 days before the expiration date. To change a password, use the following command:
In the preceding command, username is the user name. The following is an example of the command:
/opt/oracle.cellos/RESECURED_NODE file enables the security policies. If the file does not exist, then do the following:
cellcli -e alter cell shutdown services all
The preceding command restarts the cell. After the cell is up, you need to set a new password.
To view failed password attempts, use the following command:
If a user account has 5 failed login attempts, then the account is locked.
To reset an account, use the following command:
/sbin/pam_tally2 --user username --reset
In the preceding command, username is the name of the user that has the locked account.
The password policies cannot be modified for Oracle Exadata Storage Servers. They can be modified for the database servers. The following procedure describes how to modify the database server password policies:
/etc/login.defsfile to change the aging policies. The following is an example of the policies:
PASS_MAX_DAYS 90 PASS_MIN_DAYS 1 PASS_MIN_LEN 8 PASS_WARN_AGE 7
/etc/pam.d/system-authfile. The current min values are
min=disabled,disabled,16,12,8. These values are in place after running the
/opt/oracle.SupportTools/harden_passwords_reset_root_sshscript. A setting of
5,5,5,5,5allows passwords to be as short as five characters, and removes character class restrictions.
Refer to the login.defs and passwdqc.conf man pages for additional information
Oracle Exadata Storage Server Software includes the cellwall service that implements a firewall on each cell. The service is located in the
/etc/init.d/cellwall directory, and implements iptables firewall on the cell. In addition, the SSH server is configured to respond to connection requests only on the management network (NET0), and the InfiniBand network (BONDIB0).
To review the firewall rules, run the following command as the
There is no firewall automatically configured for the database servers. Implement a set of iptables on the database servers to meet your network requirements for Oracle Exadata Database Machine.
Each Oracle Exadata Storage Server is configured with
auditd to audit system-level activity. To manage audits and generate reports use the
auditctl command. The audit rules are in the
/etc/audit/audit.rules file. Any changes are not preserved when applying a patch set.
To set up security on the host computers that contain clients that access an Oracle Exadata Storage Server, you must configure the
cellkey.ora file, and place the file on all the computers.
cellkey.ora file is required for Oracle ASM-scoped security, and another
cellkey.ora file is required for each database client using database-scoped security. The key file for Oracle ASM-scoped security has the same contents on all database servers. However, the contents of the key file for database-scoped security are different for each database client.
cellkey.ora file contains entries that configure security among Oracle ASM, database clients and cells. The
asm values in the
cellkey.ora files on the Oracle ASM and database host computers must match the values assigned to the clients on the cells.
cellkey.ora file contains the following fields:
key — This field is required.
For Oracle ASM-scoped security, this key must match the value of the key assigned to the Oracle ASM cluster with the CellCLI
ASSIGN KEY command.
For database-scoped security, this key must match the value of the key assigned to the database client with the CellCLI
ASSIGN KEY command.
asm — This field is required.
This field must be unique among all the clusters that access the storage servers in the storage grid. This value is used in the
ASSIGN KEY command run on each cell, and the
ALTER GRIDDISK and
CREATE GRIDDISK commands used to configure grid disks to allow access from only a specific Oracle ASM cluster.
asmfield is used for both Oracle ASM-scoped security and database-scoped security.
Example 4-1 cellkey.ora File Entries
This example shows the entries for the
A security key is used to authenticate and protect messages between cells and the clients of the cells. The CellCLI
CREATE KEY command generates a random hexadecimal string for use as a security key.
CREATE KEY command can be run on any cell and only must be run when you need to create a new unique key.
For Oracle ASM-scoped security, you only run
CREATE KEY once to create the single key necessary in that security mode.
For database-scoped security, create one security key for Oracle ASM and one security key for each database that use database-scoped security.
Example 4-2 Creating a Security Key for Oracle ASM-Scoped Security
CellCLI> CREATE KEY 66e12adb996805358bf82258587f5050
You can configure Oracle ASM-scoped security for grid disks on Oracle Exadata Storage Servers.
CREATE KEYcommand to generate a random hexadecimal string. The command can be run on any cell.
CellCLI> CREATE KEY 66e12adb996805358bf82258587f5050
This key is used for the Oracle ASM cluster client and for the key entry in the
cellkey.orafile using the format shown in Example 4-1.
ASSIGN KEYcommand to assign the security key to the Oracle ASM cluster client on all the cells that you want the Oracle ASM cluster to access. The following is an example of the command:
CellCLI> ASSIGN KEY FOR 'unique_name_across_all_clusters' - ='66e12adb996805358bf82258587f5050'
In the preceding command, unique_name_across_all_clusters is a unique and consistent value on the cell and cluster. The Oracle Clusterware cluster name can be used if the clusters have a unique name. A unique name must be used when assigning a key.
You add the
ASMCLUSTER keyword if you are using Oracle ASM-scoped security based on Oracle ASM clusters. In this case, you specify the Oracle ASM cluster name for the unique name parameter. For example:
CellCLI> ASSIGN KEY FOR ASMCLUSTER 'Oracle_ASM_cluster_name' - ='66e12adb996805358bf82258587f5050'
availableToattribute with the
ALTER GRIDDISKcommand to configure security on the grid disks on all the cells that you want the Oracle ASM cluster to access. The following are examples of the commands to create a new grid disk with security and to change security on existing grid disks:
Create new grid disk with security:
CellCLI> CREATE GRIDDISK ALL PREFIX=sales, size=75G, - availableTo='unique_name_across_all_clusters'
Change security on existing grid disks:
CellCLI> ALTER GRIDDISK sales_CD_01_cell01, sales_CD_02_cell01, - sales_CD_03_cell01, sales_CD_04_cell01, sales_CD_05_cell01, - sales_CD_06_cell01 - availableTo='unique_name_across_all_clusters'
In the preceding commands, the unique_name_across_all_clusters is a unique and consistent value on the cell and cluster. When a value is entered for
availableTo, then only the specified clients have access to the grid disk. If a value is not entered, then any client has access.
cellkey.orafiles for each ASM cluster to
/etc/oracle/cell/network-configon each database node.
chown grid:oinstall /etc/oracle/cell/network-config/cellkey.ora chmod 600 /etc/oracle/cell/network-config/cellkey.ora
database and Oracle ASM instances
clusterware. The commands to stop and start the clusterware are:
crsctl stop crs
crsctl start crs
Before making updates to the security setups on cells, you must shut down the database and Oracle ASM instances. After you complete the steps in this section, you must ensure the key is formatted correctly, as described in "Understanding the cellkey.ora File". After the
cellkey.ora file configuration is complete, start the database and Oracle ASM instances.
To set up database-scoped security, perform the following procedure:
You should only set up database-scoped security after configuring and testing Oracle ASM-scoped security.
When there is only one Oracle ASM cluster, then using
availableTo=+asm is acceptable. If there is more than one cluster, then refer to "Setting Up Oracle ASM-Scoped Security on Oracle Exadata Storage Servers" to see how to set unique clusters.
CREATE KEYcommand to create security keys for those database clients that you want to access specific grid disks. The command can be run on any cell. After running the command, the system displays the new key.
CellCLI> CREATE KEY 66e12adb996805358bf82258587f5050
cellkey.orafile using the format shown in Example 4-1.
ASSIGN KEYcommand to assign the keys to database clients on the cells that contain the grid disks, as shown in Example 4-3.
availableToattribute with the
ALTER GRIDIDISKcommand to configure security on grid disks. You must include the Oracle ASM cluster name with the database clients names when setting the value of the
availableToattribute. The names must be unique and consistent, usually the Oracle Clusterware cluster name.
In Example 4-4, database-scoped security is configured when the grid disks are created with the use of the
availableTo attribute. This attribute determines which specific clients are configured to access the grid disks.
You can change security on existing grid disks with the
ALTER GRIDDISK command, as shown in Example 4-5.
availableTo='+asm' argument is mandatory.
cellkey.orafile configuration is complete for all computers, restart the database and Oracle ASM instances.
Refer to "Setting Up the cellkey.ora File on the Client Computers" for information about configuring the
cellkey.ora file on the client computers.
Example 4-3 Assigning Keys to Database Clients
CellCLI> ASSIGN KEY FOR 'db1'='51a826646ebe1f29e33c6ed7c4965c9a', 'db2'='bd0843beeed5e18e6664576cf9805b69', 'db3'='6679ef9ec02fa664582c3464d4b0191f'
Example 4-4 Creating Grid Disks with Database-Scoped Security
CellCLI> CREATE GRIDDISK sales_CD_00_cell01, sales_CD_01_cell01 size=75G, - availableTo='+asm,db1' CellCLI> CREATE GRIDDISK sales_CD_02_cell01, sales_CD_03_cell01 size=75G, - availableTo='+asm,db2' CellCLI> CREATE GRIDDISK sales_CD_04_cell01, sales_CD_05_cell01 size=75G, - availableTo='+asm,db3'
Example 4-5 Altering Grid Disks to Configure Database-Scoped Security
CellCLI> ALTER GRIDDISK sales_CD_01_cell01, sales_CD_02_cell01 - availableTo='+asm,db1' CellCLI> ALTER GRIDDISK sales_CD_03_cell01, sales_CD_04_cell01 - availableTo='+asm,db2' CellCLI> ALTER GRIDDISK sales_CD_05_cell01, sales_CD_06_cell01 - availableTo='+asm,db3'
You can configure the
cellkey.ora file on client computers.
If file permissions are not set correctly for the
cellkey.ora file, then access to the file is open and anyone can read it.
cellkey.orafile on the Oracle ASM cluster for ASM-scoped security.
cellkey.orafile in the
If you use a single installation user for all Oracle software, then set the permissions on the file to be read-only by the owner.
If you use role-separated management, then set the permissions on the file to be read-only by the
oinstall group that contains the installation users for both Oracle Grid Infrastructure (
grid) and Oracle Database (
chmod 600 /etc/oracle/cell/network-config/cellkey.ora
chown grid:oinstall /etc/oracle/cell/network-config/cellkey.ora
cellkey.orafile for database-based security.
You need a
cellkey.ora file for each database, and the file would be different for each database. For example, if you have three databases, you would have four different
cellkey.ora files: one for each database, plus another one for ASM.
cellkey.orafile in the
cellkey.orafile to the same user that owns the Oracle home for that database. The file should not be owned by the
oinstallgroup, or any other global operating system group.
cellkey.orafile on the client computers.
A database client
cellkey.ora must be located in the
$ORACLE_HOME/admin/db_unique_name/pfile/ directory of the database client that you want to restrict access.
The key value in this file must match the value of the key assigned to the database client. See Example 4-1 for an example of the file contents.
cellkey.ora key file must be only readable by the database client that owns the Oracle home.
If you have configured Oracle ASM-scoped security or database-scoped security in your Exadata environment, direct cell-to-cell operations may not work due to access control restrictions. To ensure cells have access to other cells when they need to communicate directly with one another, for example, for offload operations, you need to set up “cell keys” for each cell.
The following steps show how to create a cell key and assign the key to cells:
Generate a random hexadecimal string. The command can be run on any cell.
CellCLI> CREATE KEY fa292e11b31b210c4b7a24c5f1bb4d32
Assign the key to each cell.
CellCLI> ASSIGN KEY FOR CELL 'fa292e11b31b210c4b7a24c5f1bb4d32'
It is not necessary to make any grid disks “availableTo” the new key. The cells use the existing access control policy by making sure the originating client is identified at the remote target cell.
The steps above use a single key that is used for both inbound and outbound cell-to-cell traffic. The simple version of the
ASSIGN KEY command is used.
You can configure your cells to accept multiple remote cell keys. This might be the case temporarily during rekeying, or perhaps you want to assign a unique key to each cell. In this case, you need to specify
REMOTE in the
ASSIGN KEY command.
The following command sets the cell key for the local cell:
CellCLI> ASSIGN KEY FOR LOCAL CELL mykey='fa292e11b31b210c4b7a24c5f1bb4d32'
The following command sets the cell keys that the local cell will accept:
CellCLI> ASSIGN KEY FOR REMOTE CELL - 'cellkey1'='b67d5587fe728118af47c57ab8da650a', - 'cellkey2'='118af47c57ab8da650ab67d5587fe728'
The name parameter does not have to be “cellkey1”, “cellkey2”, or “mykey”. You can specify any value for the name parameter, as long as it matches the name in the client’s
Switching Between the Simple Format and the LOCAL/REMOTE Format
If you attempt to assign a LOCAL or REMOTE key to an existing cell key (that is, you have run the simple
ASSIGN KEY FOR CELL format, and you want to switch to the explicit LOCAL or REMOTE format), you will get the following error: “
CELL-02911: Remove existing CELL key before assigning LOCAL CELL key”. You must remove the cell key before assigning any new keys with the explicit LOCAL or REMOTE format. This is to protect you from inadvertently breaking your configuration by having different remote and local keys.
If you attempt to go the other way and run
ASSIGN KEY FOR CELL when there is more than one existing remote cell key, you will get the following error: “
CELL-02912: Remove all existing LOCAL and REMOTE CELL keys before assigning a CELL key. Use LIST KEY FOR CELL to show all LOCAL and REMOTE CELL keys, then use ASSIGN KEY to assign an empty value to each.” You must remove all existing LOCAL and REMOTE cell keys before assigning a simple cell key.
A key that is designated as LOCAL is implicitly also accepted from REMOTE cells, for ease of use and simpler configuration.
Listing the Cell Keys for a Cell
You use the
LIST KEY command to show all the keys assigned to a cell:
CellCLI> LIST KEY db1 b67d5587fe728118af47c57ab8da650a asm1 118af47c57ab8da650ab67d5587fe728 ASMCLUSTER cell fa292e11b31b210c4b7a24c5f1bb4d32 CELL
To show only cell keys, you can specify “
FOR CELL” in the
LIST KEY command:
CellCLI> LIST KEY FOR CELL DETAIL key: fa292e11b31b210c4b7a24c5f1bb4d32 type: CELL
CellCLI> LIST KEY FOR CELL mykey fa292e11b31b210c4b7a24c5f1bb4d32 LOCAL-CELL cellkey1 b67d5587fe728118af47c57ab8da650a REMOTE-CELL cellkey2 118af47c57ab8da650ab67d5587fe728 REMOTE-CELL
You must remove database-scoped security on a grid disk before removing Oracle ASM-scoped security.
Before making updates to the security on cells, you must shut down the database and Oracle ASM instances. After all of the changes to security configuration are complete, start the database and Oracle ASM instances.
To remove database-scoped security on grid disks, perform the following procedure:
availableToattribute of the grid disks for which you want to remove database-scoped security. Example 4-6 shows how to do this for a group of grid disks.
ASSIGN KEYcommand as follows:
CellCLI> ASSIGN KEY FOR 'db_client'=''
In the preceding command, db_client is the name of the database client. To the right of the equal sign are two single quote characters with no space between them.
cellkey.orafile located in the
$ORACLE_HOME/admin/db_unique_name/pfile/directory for the database client.
availableToattribute using the following command:
ALTER GRIDDISK ALL availableTo='+asm'
Example 4-6 Removing Database Clients from Grid Disks
The following command removes all database clients from a group of grid disks:
CellCLI> ALTER GRIDDISK sales_CD_01_cell01, sales_CD_02_cell01, - sales_CD_03_cell01, sales_CD_04_cell01, sales_CD_05_cell01, - sales_CD_06_cell01 - availableTo='+asm'
The following command removes specific database clients from a group of grid disks:
CellCLI> ALTER GRIDDISK sales_CD_04_cell01, sales_CD_05_cell01, - sales_CD_06_cell01, sales_CD_07_cell01, sales_CD_08_cell01, - sales_CD_09_cell01, - availableTo='+asm,db2,db3'
If you want open security for the grid disks, then you must remove Oracle ASM-scoped security after removing the database-scoped security,
After you have removed database-scoped security, you can remove Oracle ASM-scoped security if you want open security for grid disks on cells.
availableToattribute of the grid disks on cells, as shown in Example 4-7.
ASSIGN KEYcommand, as follows:
CellCLI> ASSIGN KEY FOR 'asm_cluster'=''
In the preceding command, asm_cluster is the name of the Oracle ASM cluster client.
cellkey.orafile located in the
/etc/oracle/cell/network-config/directory on each computer host in the Oracle ASM cluster.
ALTER GRIDDISK ALL availableTo=''
Example 4-7 Removing the Oracle ASM Cluster Client from Grid Disks
The following command removes the ASM cluster client from all grid disks on a cell:
CellCLI> ALTER GRIDDISK ALL availableTo=''
The following command removes the ASM cluster client from a group of grid disks:
CellCLI> ALTER GRIDDISK sales_CD_01_cell01, sales_CD_02_cell01, - sales_CD_03_cell01, sales_CD_04_cell01, sales_CD_05_cell01, - sales_CD_06_cell01 availableTo=''
You can control which commands users can run by granting privileges to roles, and granting roles to users.
For example, you can specify that a user can run the
list griddisk command but not
alter griddisk. This level of control is useful in Cloud environments, where you might want to allow full access to the system to only a few users.
In Cloud environments, to run ExaCLI, users need to log in with a user name and password. Exadata's Management System (MS) authenticates the user credentials, then performs authorization checks on the commands issued by the user. If the user does not have the proper privileges to run a command, MS returns an error.
Users are required when running ExaCLI. ExaCLI enables you to manage cells remotely from compute nodes. When you run ExaCLI on a compute node, you need to specify a user name to use to connect to the cell node.
Password security key is encrypted using Password-Based Key Derivation Function 2 (PBKDF2) with HMAC-SHA1.
To set up users and roles, you would perform these steps:
Create roles using the CREATE ROLE command.
Grant privileges to roles using the GRANT PRIVILEGE command.
Create users using the CREATE USER command.
Grant roles to users using the GRANT ROLE command.
CREATE ROLE command to create roles. For example:
CellCLI> CREATE ROLE admin
To get detailed information about a role, use the
LIST ROLE command. For example, the following command returns all the attributes for the
CellCLI> LIST ROLE admin ALL DETAIL
GRANT PRIVILEGEcommand to grant privileges to roles.
The following example grants all privileges to users with the
CellCLI> GRANT PRIVILEGE ALL ACTIONS ON ALL OBJECTS TO ROLE admin
Use the CREATE USER command to create users.
The following command creates a user called "fred" with password "changeME123".
CellCLI> CREATE USER fred PASSWORD = "changeME123"
A newly created user does not have any privileges. You have to grant roles for the user to have any privileges.
By default, SSH is enabled on storage servers. If required, you can "lock" the storage servers to block SSH access. You can still perform operations on the cell using exacli, which runs on compute nodes and communicates using https and REST APIs to a web service running on the cell.
When you need to perform operations that require you to log in to the cell, you can temporarily unlock the cell. After the operation is complete, you can relock the cell.
Two new cell attributes control cell locking:
accessLevelPerm : This attribute specifies the access level at which the cell runs by default. It is either
remoteLoginEnabled: SSH service is enabled. You can access the cell using ssh or exacli. This is the default value for
remoteLoginDisabled: SSH service is disabled. You can access the cell only through exacli.
accessLevelTemp: The access level can be changed temporarily for a specified duration. Once the duration has expired, the access level reverts back to the accessLevelPerm value. You typically change the cell's access level when the cell needs a software update.
The access level persists across cell reboots.
You lock a cell by setting its
accessLevelPerm attribute to
You must use a user that has the privilege to alter the
On the storage server, run these commands:
cellcli> create role administrator cellcli> grant privilege all actions on all objects all attributes with all options to role administrator cellcli> create user celladministrator password=* cellcli> grant role administrator to user celladministrator
celladministratoruser and run the ALTER CELL command:
$ exacli -l celladministrator -c exam08cel01 Password=******** exacli> alter cell accessLevelPerm = remoteLoginDisabled
You can unlock a locked cell for a short period of time to perform operations such as maintenance or upgrades that require SSH login to the cell. You can specify the start time of this "temporary access window" and how long it should last by setting the cell's
accessLevelTemp attribute. This attribute has the following properties:
Table 4-1 Properties of accessLevelTemp
Specifies whether SSH is enabled (
This value needs to be specified. There is no default value.
Specifies when the specified access level starts. The time is specified in the ISO 8601 format: "yyyy-MM-ddTHH:mm:ssZ".
You can also specify the keyword "
Specifies how long the access level should last. The duration is specified in the following format:
[any number of digits, followed by
[any number of digits followed by
[any number of digits followed by
To specify 1 hour:
To specify 90 minutes:
To specify 1 day:
To specify 1 day and 12 hours:
Specifies a reason for changing the access level, for example: performing an upgrade.
Default value: "none"
1. The following example creates a two-hour temporary access window that will begin on June 20, 2015, at 1:01 AM.
exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", - startTime="2015-06-20T01:01:00-07:00", - duration="2h", - reason="Quarterly maintenance"))
2. The following example creates a two-hour temporary access window that starts immediately. The command uses the default values for start time and duration.
exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", - reason="Quarterly maintenance"))
3. The following example creates a 30-minute temporary access window that starts immediately
exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", - startTime="now", - duration="30m", - reason="Quarterly maintenance"))
4. The following example creates a two-hour temporary access window that will begin on June 20, 2015, at 1:01 AM. The command uses the default duration value.
exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", - startTime="2015-06-20T01:01:00-07:00", - reason="Quarterly maintenance"))
5. The following example extends the temporary access window created in example 4 above to 5 hours. Note that the start time has to match the window that is being adjusted.
exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", - startTime="2015-06-20T01:01:00-07:00", - duration="5h", - reason="Quarterly maintenance window extended to 5 hrs - Joe"))
6. The following example deletes the temporary access window. If the temporary access window is currently active, it is closed immediately and the access level will be set back to the permanent access level. If the temporary access window is in the future and not yet active, it is cancelled.
exacli> alter cell accessLevelTemp=''
Note the following:
Only one temporary access window is allowed at any time. You will get an error message if you try to create a new temporary access window when one is already in effect.
If the temporary access window is not yet active and is in the future, the newly created temporary access window will replace the one that is in the future.
To modify a temporary access window that is in the future and not yet active, simply run the "alter cell" command again with the new values.
To modify a temporary access window that is already in progress (for example, to extend the duration or to change the reason), run the "alter cell" command again with the updated duration and/or reason. The command must provide the exact start time of the existing temporary access window to modify. The (start time + duration) must be in the future.
To see what the current access level is, run the following command:
exacli> list cell detail
Look at the values for the
You can also run the following commands:
exacli> list cell attributes accessLevelPerm exacli> list cell attributes accessLevelTemp
A stateless alert is generated when the
accessLevelPerm attribute is modified.
A stateful alert is generated when the
accessLevelTemp window is created. An alert email is sent out when the
accessLevelTemp window is activated. The alert is cleared when the window expires.