Creating a Role Definition With Specific Privileges

The previous examples of role definitions granted broad privileges. You can also use role definitions grant or deny very specific rights. For example, you might want to deny access to a specific set of commands for a specific group of administrators who otherwise have broad access rights or to strictly limit exactly what commands users can execute. Depending on the requirements of your organization, you might configure these types of role definitions to be used in a restricted or unrestricted shell.

The steps for creating a role definition with specific privileges are similar to the steps for creating the other roles. In this example, rights are defined to prevent the execution of specific commands and combined with a right to grant access to all commands not explicitly listed.

Define Command Rights to Prevent the Use of Commands

The steps for defining rights that deny access to specific commands are similar to the steps defining other rights, but require different syntax. In this example, you create a “blacklist” of commands users cannot execute.

To create the right to switch to the root user:

Open Access Manager.
Expand Zones and the individual parent or child zones required to select the zone name where you want to create the new command right.
Expand Authorization > UNIX Right Definitions.
Select Commands, right-click, then click New Command.
On the General tab, type a name, such as No password resets, for this command right and, optionally, a description for this right, then define the right:
- Type !passwd * in the Command field.
- Verify Standard user path is selected.
  
  An exclamation point (!) at the start of a command disallows matching commands. Command rights that start with the exclamation point take precedence over others that don’t.
Click the Restricted Shell tab and verify Can be used in a restricted role and User running the command are selected.

These options enable you to use this command right in combination with other rights in a role definition that requires a restricted shell environment.
Click the Run As tab and verify Can be used by dzdo and Any user are selected, then click OK.

In most cases, you can leave the default settings for the other properties. If you want to make changes, click the Environment and Attributes tabs before saving the new command.
Repeat Step 4 to Step 7 to create rights for the following specific commands:

!groupadd *
!useradd *
!groupdel *
!userdel *

Create a Restricted Shell Role Definition that Uses the Command Rights

After you have defined all of the command rights that disallow specific commands, you can create one or more role definitions to use those rights. For example, you might create one role definition to run in an unrestricted shell that requires users to invoke dzdo to execute privileged commands and another role definition that runs in a restricted shell but does not require users to execute privileged commands using dzdo. The second role might be useful if you have existing scripts that would have to be modified if invoking dzdo is required.

To create a role definition for specific command rights:

Open Access Manager.
Expand Zones and the individual parent or child zones required to select the zone name where you want to create the new role definition.
Expand Authorization.
Select Role Definitions, right-click, then click Add Role.
Type a name and description for the new role.

For example, type a name such as operators and descriptive text such as Users with this role can run privileged commands but not reset passwords, add or delete users and groups.
Click System Rights if you want this role definition to be used in a restricted shell environment as a replacement for the predefined UNIX Login role.

To use this role, a user must be assigned to a role definition that has at least one login system right, such as Password login and nonpassword (SSO) login are allowed or Nonpassword (SSO) login is allowed.
Click OK to save the role definition.
Select the new role definition, right-click, then click Add Right.
Select all of the command right that disallow specific operations, the command right that grants access to all remaining commands, and a PAM access right, then click OK.

For example, you might add the following previously-defined command rights to this role definition:

No password resets
No user adds
No group adds
No user deletes
No group deletes
Root like access (* for all commands not explicitly disallowed)
PAM ssh/login allowed

This role definition allows members of the operators role to execute any command within a restricted shell environment except those explicitly disallowed, including privileged commands, without invoking dzdo first. You can assign the role definition to the appropriate Active Directory users or groups like the previous role definitions.

Create an Unrestricted Shell Role Definition that Uses the Command Rights

The command rights were configured to allow execution in either a restricted shell environment or an unrestricted shell environment. In an unrestricted shell environment—for example, the default shell environment when users are assigned the UNIX Login role—commands that require administrative privileges must be executed by first invoking the dzdo command, which is similar to invoking commands with sudo.

You can control whether users are required to enter a password or another form of authentication when they execute privileged commands using dzdo by setting one of the Re-authenticate options on the Attributes tab when you create a command right. By default, no password is required. If you were adding a new command right that requires reauthentication, you would click the Attributes tab, then select Re-authenticate current user or Re-authenticate using target user’s password. For more information about these options, see Requiring re-authentication to run commands.

In most cases, the default of no password is appropriate because the user has been previous authenticated before invoking dzdo to execute a privileged command and the Reauthenticate using target user’s password option requires the user to know the privileged account password. For example, if select this option and the run-as user is root, the user must know the password for the root account.

The steps for creating the role definition that includes the previously-defined command right are the same for the unrestricted shell as for the restricted shell except that, at Step 6 in the topic Create a restricted role definition for the service account, in the System Rights tab you would also select the Login with non-Restricted Shell option if you are not using the UNIX Login role. You could add all of the same command rights to the role definition and grant the same privileges and exceptions.

The primary difference between the two role definitions would be how users execute their privileged commands.

In the restricted shell environment, users running the adflush command requiring administrative privileges:

dzsh $ adflush

In the unrestricted shell environment, users running the adflush command requiring administrative privileges:

[tulo@ajax]$ dzdo adflush