User Security on Recovery Appliance

Default User Accounts for Oracle Zero Data Loss Recovery Appliance

The following table lists the default users and passwords for the Oracle Zero Data Loss Recovery Appliance components. All default passwords should be changed after installation of the Recovery Appliance.

Table 11-1 Default Users and Passwords for Oracle Zero Data Loss Recovery Appliance

Component	User Name and Password
Compute servers	Operating system users: `root/welcome1` `oracle/We1come$` `dbmadmin/welcome` `dbmmonitor/welcome` `raext/(locked and blocked from SSH access)` `railm/(locked and blocked from SSH access)` `rasys/(locked and blocked from SSH access)` `rasec/(locked and blocked from SSH access)` Password for the GRUB boot loader: `sos1Exadata` Database users: Note: Only local connections are allowed for externally authenticated users. `SYS/We1come$` `SYSTEM/We1come$` `raext/(externally authenticated)` `ralim/(externally authenticated)` `rasec/(externally authenticated)` `rasys/change^Me2` OSB tape backup application users: `admin/welcome1` `oracle/welcome1` encryption key wallet/`welcome1`
Storage servers	`root/welcome1` `celladmin/welcome` `cellmonitor/welcome` `CELLDIAG` `CELLDIAG` is an Exadata storage software user, not an operating system user. The password of the `CELLDIAG` user is reset to a random password during the "Apply Security Fixes" step of Oracle Exadata Deployment Assistant. If this step is not run, then the default password is `Welcome12345`. Password for the GRUB boot loader: `sos1Exadata`
RoCE Network Fabric	`root/welcome1`
InfiniBand Network Fabric switches	`root/welcome1` `nm2user/changeme` `ilom-admin/ilom-admin` `ilom-operator/ilom-operator`
Ethernet switches	`admin/welcome1` Note: Secure the `enable mode` `password` and `secret` values for the `admin` user.
Power distribution units (PDUs)	`admin/welcome1` The password for the `admin` user is `adm1n` if you reset the PDU to factory default settings.
Compute server ILOMs	`root/welcome1` `MSUser` Management Server (MS) uses this account to manage ILOM and reset it if it detects a hang. Do not modify this account. This account is to be used by MS only. Each time MS starts up, it deletes the previous `MSUser` account and re-creates the account with a randomly generated password. The `MSUser` password is not persisted anywhere. If you need to change account passwords regularly, you can restart MS to change the password of the `MSUser` account.
Storage server ILOMs	`root/welcome1` `MSUser` See the description above for details about this user.
InfiniBand Network Fabric ILOMs	`ilom-admin/ilom-admin` `ilom-operator/ilom-operator` `root/welcome1`

Note:

After the Recovery Appliance has been deployed, the installation process disables all root SSH keys and expires all user passwords as a security measure for your system. If you do not want the SSH keys disabled or the passwords expired, advise the installation engineer before the deployment.

User Roles for the Recovery Appliance

The Recovery Appliance introduces roles for named user accounts and limits operations available to those roles to improve security and logging.

The Recovery Appliance has the following security roles that have changed or are new in software release 21.1, and provide more options to meet audit and security requirements.

The rasys account is the original administrator, root-level account formerly needed to perform operations on the Recovery Appliance. Named users db_user with roles and responsibilities replace the usage of rasys for day-to-day operations.

The rasys account is now an internal user account. It remains the owner of the RMAN catalog, the Recovery Appliance metadata schema, and all user-facing views. It is used during deployment, patch, and upgrade by Oracle Support. The usage of rasys is restricted and available only for approved tasks and for break-glass operations.
Note:
"Break glass" is any time where the API's do not allow access to the data needed. This might be:
- If we need to set a config parameter which is an underscore.
- If we need access to a trace file that is not accessible.
- If we need to run an internal API (dbms_ra_int.delete_backup_piece).
The db_user is a role for new named user who can perform limited operations depending on user types.
- admin: this db_user user type replaces the usage of rasys for configuration and day-to-day Recovery Appliance management operations. This account can manipulate the database and issue SQL Plus commands.
- vpc: this db_user user type is for Virtual Private Catalog (VPC) user activities on the Recovery Appliance. It is required to be in the wallet client side to allow access for backing up and restoring.
- monitor: this db_user user type is intended for OEM applications like Enterprise Manager and job functions that are read-only for monitoring incidents and the status of the Recovery Appliance.
The admin_user account is a role for new named users who manage the Recovery Appliance from an operation's perspective. It permits operating system level operations on the Recovery Appliance that previously required root access. However admin_user is not root.
The sys account is the super user for Oracle databases, and can change any schema in the database. Remote sys access is now disabled and can be selectively enabled for approved tasks and for break-glass operations.

RACLI Non-Root User

Allows a non-privileged user to execute RACLI commands.

The Recovery Appliance in release 21.1 has become more secure by limiting root access to the Recovery Appliance. It introduces the raadmin group, whose members can execute RACLI commands and thus perform system management that previously required root access.

This change aligns the Recovery Appliance with LDAP and Name Services Requests and improves auditing. At the same time, privileged remote access (root SSH) is removed for better security.

Most Recovery Appliance management tasks can be performed through non-privileged access to RACLI.

Creating an admin_user

Issue the following command from the compute server by providing an appropriate system user name for <user_name>.

racli add admin_user --user_name=<user_name>

This adds an admin user to the raadmin group. This admin user is created if it is not found in the passwd database. The logic prompts you to enter a user password.

racli list admin_user

Lists all of the users who are in the raadmin group and can execute RACLI commands.
racli alter admin_user --user_name=<user_name>

Changes the password for the provided <user_name>. The logic prompts you to enter a user password.
racli remove admin_user --user_name=<user_name>

Removes the provided <user_name> from the passwd database. The <user_name> has to be a member of the raadmin group.

Securing the Operations of the Recovery Appliance

The following steps harden the Recovery Appliance by reducing exposure to powerful users, like root and rasys and allowing improved auditing of maintenance actions. Although this procedure is optional for many installations and applications, establishing and using secure users is required for operations to be compliant with various regulatory mandates.

For purposes of example, the sample commands have three fictive users: bob, sue, and jim.

Create named users and assign them db_user with user type admin with administration rights.

The db_user user type admin replaces the usage of rasys for configuration and day-to-day Recovery Appliance management operations. This account can issue certain SQLPlus commands within its assigned privileges.
```
racli add db_user --user_type=admin --user_name=bob
racli add db_user --user_type=admin --user_name=sue
```
In this example, bob and sue are given --user_type=admin for administration rights.

Note:
The db_user user type admin has limits of privileges, and cannot be used as sysdba in SQLPlus.
Create ssh users for the Recovery Appliance.

The admin_user account is a role for new named users who manage the Recovery Appliance from an operation's perspective. It permits operating system level operations on the Recovery Appliance that previously required root access, however admin_user is not root.
```
racli add admin_user --user_name=bob
racli add admin_user --user_name=jim
racli add admin_user --user_name=sue
```
In this example, bob, sue and jim are given admin_user with administration rights.
Disable ssh access for root and oracle.
```
racli disable ssh
```
Disable root access for root, oracle, and raadmin.
```
racli disable root_access
```
Disable rasys access.

Note:
Make sure that you have the db_user user type admin accounts and admin_user accounts before disabling rasys access.
```
racli disable rasys_user
```
Disable sys remote access.
```
racli disable sys_remote_access
```
Validate the time service.

Refer to Changing the CHRONY Servers.
Validate that the Recovery Appliance is in compliance.
```
racli run check --check_name=check_ra_compliance
```
The above should return TRUE. The check_ra_compliance validates:
- ssh access for root and oracle is disabled on all nodes.
- rasys access is disabled.
- sys remote access is disabled.
- Time service is enabled.
- Two or more admin_users for the Recovery Appliance have been established.
- Two or more db_users who are admin have been established.
If any of the above items are not completed, check_ra_compliance fails, because one or more security gaps still exist on the Recovery Appliance.

At the completion of the above steps:

The initial set of administrative users have been configured.
An audit trail of actions by administrative users is now possible.
Various commands are restricted to users with the proper permissions.
Certain commands are restricted to quorum operations requiring approval of others to finally be run.

Quorum

This chapter describes how quorum works when compliance is in operation on the Oracle Zero Data Loss Recovery Appliance.

When compliance is in effect, certain RACLI commands are not just restricted to privileged users but also can be subject to a quorum operation that requires two approvals and no denials from the set of other privileged users. The two tests for validating quorum are:

Test 1: TRUE if there are backups under compliance, legal hold, or other keep control.
Test 2: TRUE if the compliance mode has been enabled.

If Test 1 or Test 2 are TRUE, quorum is required. If both tests are FALSE, quorum isn't required.

The quorum scenario given below assumes:

bob, sue, and jim are db_users of the system.
bob and sue are given db_user --user_type=admin for administration rights.
bob, sue and jim are given admin_user with administration rights.

The scenario below illustrates quorum operations.

Administrator bob is working. He uses his db_user --user_type=admin with his ssh_user account. He's been adding protected database and trouble shooting incidents.
An issue arises with the Recovery Appliance.
The action plan from Oracle Support/Development includes tasks that require rasys to run.
User bob issues the RACLI command to enable the rasys login for 6 hours.
```
racli enable rasys_user --expire=6
```
This returns a request identifier that is associated with the user and an increment, such as bob.1.
User bob can monitor that status of his request.
```
racli status request --request_id=bob.1
```
At least two users who are admin_user must approve the request. Users sue and jim use the request identifier and approve the request.
```
(sue) racli approve request --request_id=bob.1
(jim) racli approve request --request_id=bob.1
(bob) racli status request --request_id=bob.1
```
If one admin_user denies the request, then the operation (with that request identifier) will not be processed.
When the request is approved, user bob can proceed with his task of enabling rasys, but this time with the request identifier.
```
racli enable rasys_user --request_id=bob.1
```
This particular operation may prompt bob for the password to be used for rasys while rasys is enabled.
User bob performs the action plan from Oracle Support/Development, logging in as rasys with the password specified by bob in the command.
User bob disables rasys.
```
racli disable rasys_user
```
This returns a request identifier that is associated with the user and an increment, such as bob.2.
User bob can monitor that status of his request.
```
racli status request --request_id=bob.2
```
At least users who are admin_user must approve the request. Users sue and jim use the request identifier and approve the request.
```
(sue) racli approve request --request_id=bob.2
(jim) racli approve request --request_id=bob.2
(bob) racli status request --request_id=bob.2
```
If one admin_user denies the request, then the operation (with that request identifier) will not be processed.
When the request is approved, user bob can proceed with his task of disabling rasys, but this time with the request identifier.
```
racli disable rasys_user --request_id=bob.2
```

Default Password Requirements

Oracle Exadata Deployment Assistant (OEDA) implements a default password policy on Oracle Exadata Database Machine.

The last step of OEDA, "Secure Oracle Exadata Database Machine", implements the following password requirements:

Dictionary words are not valid or accepted.
Character classes for passwords are uppercase letters, lowercase letters, digits, and special characters.
Passwords must contain characters from all four character classes. Passwords using only one, two, or three character classes are not allowed.
The minimum length of a password is eight characters.
Pass-phrases are allowed. A pass-phrase should contain at least three words, be 16 to 40 characters in length, and contain different character classes.
A new password cannot be similar to old passwords. There must be at least eight characters in the new password that were not present in the old password.
A maximum of three consecutive characters of the same value can be used in a password.
A maximum of four consecutive characters of the same character class can be used in a password. For example, abcde1#6B cannot be used as a password because it uses five consecutive lower case letters.

Default Security Settings Implemented by OEDA

Oracle Exadata Deployment Assistant (OEDA) includes a step to implement default security settings on Recovery Appliance.

The last OEDA configuration step implements the following security settings:

The following password rules apply by default for all operating system users on the compute servers and storage servers:
- Non-root users must change their password during first login.
- The password complexity rules depend on the Oracle Linux version in use.
  
  For systems with Oracle Linux 7 or later:
  - The minimum password length is 8 characters,
  - The password must contain at least one digit, one uppercase character, one lowercase character, and one other character.
  - The password must not contain the same character consecutively more than 3 times.
  - The password must not contain more than 4 consecutive characters from the same class (digits, lowercase letters, uppercase letters, or other characters).
  - For password changes, the new password must contain a minimum of 8 character changes.
  For systems with Oracle Linux 6 or earlier, the minimum password length is 5 characters with no additional complexity requirements.
- The maximum password age is 60 days.
- The minimum amount of time between password changes is 1 day.
- Warning alerts are generated 7 days before password expiry.
- When changing a user password, the new password cannot match any of the 10 previous passwords.
An operating system user account is locked for 15 minutes after three failed login attempts within a 15-minute period.
For the root user, SSH equivalency is removed for all compute servers and storage servers.