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.

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.

1. 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.

2. 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.

3. Disable ssh access for root and oracle.

   racli disable ssh

4. Disable root access for root, oracle, and raadmin.

   racli disable root_access

5. 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

6. Disable sys remote access.

   racli disable sys_remote_access

7. Validate the time service.

   Refer to Changing the CHRONY Servers.

8. 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.

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.

1. 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.

2. An issue arises with the Recovery Appliance.

3. The action plan from Oracle Support/Development includes tasks that require rasys to run.

4. 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.

5. User bob can monitor that status of his request.

   racli status request --request_id=bob.1

6. 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.

7. 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.

8. User bob performs the action plan from Oracle Support/Development, logging in as rasys with the password specified by bob in the command.

9. 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.

10. User bob can monitor that status of his request.

    racli status request --request_id=bob.2

11. 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.

12. 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