Assign an Active Directory group to the role

You should associate Centrify role definitions with Active Directory security groups so that you can manage them using the processes and procedures you have for managing Active Directory group membership. For example, create an Active Directory group named sanfrancisco_role_oracle. You can then assign the new role definition to that group.

To assign the role definition to an Active Directory group:

  1. Open Access Manager.
  2. Expand Zones and the individual parent or child zones required to select the zone name where you want to assign the role definition.
  3. Expand Authorization.
  4. Select Role Assignments, right-click, then click Assign Role.
  5. Select the role definition you created for using secure shell and switching to the service account access, such as oracle_service, then click OK.

  6. Click Add AD Account to search for and select the Active Directory security group you created for the role definition.

    • Select Group as the object to find.
    • Optionally, type all or part of the group name.
    • Click Find Now.

    Select the group you created for the role in the results, then click OK.

  7. Click OK to complete the assignment.

Working in a restricted shell environment

When users who are assigned to this role want to open a secure shell session and switch to the oracle service account, they will be placed in a restricted shell environment. Within the restricted shell, they can only execute the commands you have added to the role definition until they exit the restricted shell session. In this example, the role definition only allows users to log on using ssh and execute one command, su - oracle. If those users are also assigned the UNIX Login role, they will have access to an unrestricted shell when they close the restricted shell session.

If you want users who access a shared service account to work exclusively within the restricted shell environment, you must remove the UNIX Login role assignment in the zone or on the computer where they should only have restricted shell access. Before removing the UNIX Login role assignment, however, you should consider the trade-off between improved operational security and audit compliance and reduced operational access. Depending on the rights you add to a role that runs in a restricted shell environment, the restricted shell can dramatically limit what users can do.

Testing access in a restricted shell

If you create a role definition for a shared service account that runs in a restricted shell environment, you should test it before migrating any users to it. You can use the dzinfo command with the --test option from a UNIX command prompt. For example, type dzinfo, the user name to test, the --test option, then the full path to the command to test:

dzinfo raejames --test “/usr/bin/su - oracle

You can also run the dzinfo command with the --roles option to see information about the rights defined for the current user or a specified user. For example, run the following command to check the roles and rights defined for the user raejames:

dzinfo raejames --roles

For more information about using this command, see the dzinfo man page.

What users see in a restricted shell environment

For users assigned to a role that runs in a restricted shell, logging on opens a dzsh shell. Within that shell users can only execute the commands you have explicitly defined for them. In this example scenario for a shared service account, typing su - oracle is the only allowed command. If the user types any other command, the shell reports that the command is not allowed.