Defining Role-Based Access for Users and Computers

By default, Verify Privilege Server Suite includes two roles—the listed role and the UNIX Login role—that are required for migration. This section discusses additional role-based controls you can define for better management of privileged access and authorized activity.

If you have well-defined access rules and command privileges in sudoers configuration files, you can import those definitions and use them as the basis for creating custom roles in Access Manager. For information about importing sudoers files and converting the imported definitions into roles, see the Administrator’s Guide for Linux and UNIX.

Addressing the Business Problem of Role-based Security

Privilege management and role-based access controls are approaches to the basic business problem of securing an enterprise’s key computer systems and sensitive data. Restricting access based on a user’s role or specific job requirements can require you to make some difficult decisions about who has access to what and why access is granted or denied. These decisions also have the potential to disrupt user activity or existing business processes. Therefore, you should do thorough planning to identify the roles to implement, who should have permission to execute privileged commands, and who should have restricted access.

Defining the appropriate rights for users in different roles often requires negotiation with different groups in the organization to achieve the right balance of security and functional capability. Before implementing a solution, you should have these conversations and set expectations about what will change in the user’s environment.

Creating a Root-Equivalent Role Definition

One of the first roles you should plan to create is an administrative role that is equivalent to specifying ALL:ALL in a sudoers file or giving users access to the root password on their computers. The purpose of this role definition is to allow selected users to execute privileged commands on a regular basis. The role definition allows them to execute commands without being given the root password or having privileges hard-coded in individual sudoers files on multiple computers.

Because this role definition enables system administrators to execute privileged commands without the root password, you can improve security for the organization and reduce the chance of an audit finding for access to the root password.

You can create this role definition in a parent zone or a child zone to control its scope. In most cases, you should only assign the role in a child zone or on an individual computers.

Define the Right for Running All Commands

Rights and roles are defined at the zone level and inherited down the zone hierarchy. If you define a right in the top-level zone, it is available in all child zones. If you define a right in a child zone, it can be used in that zone and any of its child zones. Similarly, you can define roles in the top-level parent or any child zone, depending on where you want to make the role available. In this example, the right to run all commands as the root user is defined in a top-level parent zone.

The following instructions illustrate how to define a right for running all commands using Access Manager. Examples of scripts that use the Access Module for Windows PowerShell, ADEdit, or the Verify Privilege Server Suite Windows API are available in other guides, the Verify Privilege Server Suite Software Developer’s Kit, or in community forums on the IBM Security website.

To define a right for running all commands as root:

Open Access Manager.
Expand Zones and select the top-level parent zone.
Expand Authorization > UNIX Right Definitions.
Select Commands, right-click, then click New Command.
On the General tab, type a name for this command right and, optionally, a description for this right, then define the right to run all commands like this:
- Type an asterisk (*) in the Command field to indicate all commands are allowed.
- Select Specific path and type an asterisk (*) in the field to indicate that any path is allowed.
Click the Restricted Shell tab and deselect the Can be used in a restricted role option if you want to prevent this command from being used in a role that uses a restricted shell environment.
Click the Run As tab to verify the command can be used by dzdo and is set to run as root by default.
Click OK to use the default environment variable settings and command attributes.

Alternatively, you can click the Environment and Attributes tabs if you want to view or set additional properties for this right definition.

Create a Role Definition for Running All Commands

After you have defined the right to allow a user to run any command with root privileges, you can create a role definition for that right. You must create a role definition somewhere in the zone hierarchy before you can assign users to the role.

To create a role definition with the right to run all commands as root:

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

For example, type a name such as root_equivalent and descriptive text such as Users with this role can run any command with root privileges.

Optionally, you can select Allow local accounts to be assigned to this role if you want to assign both Active Directory users and local users to the role. This option is only available when you first create a role definition. You can also click Available Times if you want to limit when the role is available for use. By default, roles are available at all times.

If you are using the UNIX Login role to grant access to computers in the zone and want to use the default auditing level of Audit if possible, you can click OK then skip to Step 8.
If you are not assigning the UNIX Login role to grant access to computers, click the System Rights tab and select the following options:
- Password login and non-password (SSO) login are allowed
- Non-password (SSO) login is allowed
- Login with non-Restricted Shell
  
  Note that you cannot set these system rights if you selected the option to allow local users to be assigned to this role.
If you don’t want to use the default auditing level, click the Audit tab.
- Select Audit not requested/required if you have the auditing service enabled but don’t want to audit user activity when this role is used.
- Select Audit if possible to audit user activity where you have the auditing service enabled.
- Select Audit required to always audit user activity. If the auditing service is not installed or not available, users in this role are not allowed to log on.
Select the new role definition, right-click, then click Add Right.
Select the right you defined for running all commands as root, then click OK.

Assign an Active Directory Group to the Role

As discussed in previous chapters, 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. If you are using the recommended deployment structure and naming conventions, you would create a new Active Directory group in the ou=User Roles, ou=Centrify organizational unit using the format ZoneName_Role_RoleName. For example, you would create an Active Directory group named sanfrancisco_role_rootequivalent. You can then assign the new role definition to that group.

To assign the role definition to an Active Directory group:

Open Access Manager.
Expand Zones and the individual parent or child zones required to select the zone name where you want to assign the role definition.
Expand Authorization.
Select Role Assignments, right-click, then click Assign Role.
Select the role definition you created for root-level access, such as root_equivalent, then click OK.
Click Add AD Account to search for and select the Active Directory security group you created for the role.
- 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.
Click OK to complete the assignment.
Add members to the Active Directory security group for the role definition using Active Directory Users and Computers, an internal script, or another tool.
Test the role assignment by checking whether the user you added to the Active Directory group can execute privileged commands using dzdo in place of sudo.

dzdo /usr/share/centrifydc/din/adflush

Details about commands that are executed with dzdo are logged to the secure syslog facility on the computer where they were executed.

Creating a Restricted Role for a Shared Service Account

The root-equivalent role definition provides centralized management for a limited number of administrators who have permission to execute all commands on selected computers. Another common reason for defining a role is to execute privileged commands associated with a service account. In many organizations, service account passwords are known by multiple users, making them a security risk. For example, all of the database administrators in the organization might know the password for an oracle service account, an account with permission to perform privileged database operations. Because the password is shared information, it presents a security risk and a potential audit finding that might have costly consequences.

Setting up a role definition for a service account involves creating a command right for switching to the service account user and defining a PAM access right for role.

Define the Right for Switching to a Service Account

The steps for defining a right for switching to the service account user are similar to defining the rights for the root-equivalent user, but the definition is more restrictive.

To define a right for switching to a service account:

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 for this command right and, optionally, a description for this right, then define the right to switch to the service account. For example, if the service account is oracle:
- Type su - oracle in the Command field.
- Verify the Standard user path is selected.
Click the Restricted Shell tab, under Can be used in a restricted role, select Specific user or uid, then type root.
Click the Run As tab, deselect Can be used by dzdo.

These settings specify that this right can only be used in a restricted shell environment and users can only run the commands that are explicitly allowed in the restricted role they are assigned. If this is the only right defined for a role, the only command users assigned to the role can run is su - oracle. For a role definition with this right to be effective, you would add command rights for the specific database operations users should be allowed to perform after switching to the oracle service account. For example, if the oracle service account is used to run a backup-all-dbs script, you would add a right to allow the execution of that script.
Click OK to use the default environment variable settings and command attributes.

Alternatively, you can click the Environment and Attributes tabs if you want to view or set additional properties for this right definition.

Define a PAM Access Right to Allow Logging On

The default UNIX Login role allows users to log on using a password or without a password in an unrestricted environment. If you are creating a role definition for a service account, you can use PAM access rights to control the specific PAM-enabled applications users can use to log on. To illustrate controlling how users log on, this example of a restricted role for the oracle service account only allows users to log on with ssh.

To define a PAM access right for a specific application:

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 PAM right.
Expand Authorization > UNIX Right Definitions.
Select PAM Access, right-click, then click Add PAM Access Right.
Type a name and, optionally, a description of the PAM application for which you are adding an access right.

For the Application field, type the platform-specific name for the PAM application as defined in the PAM configuration file or PAM directory. For example, type ssh or sshd. You can also use wildcards in this field to perform pattern matching for the application name.
Click OK to save the access right for this PAM-enabled application.

Create a Restricted Role Definition for the Service Account

After you have defined the rights that allow a user to log on using a PAM-enabled application and run the su - command for a service account, you can create a role definition for these rights. You must create a role definition somewhere in the zone hierarchy before you can assign users to the role.

To create a restricted role definition for switching to a shared service account:

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, then click OK.

For example, type a name such as oracle_service and descriptive text such as Users with this role can start a secure shell session and switch to oracle.

By default, this role is available at all times. You can click Available Times if you want to specify days of the week or select times of the day for making the role available.
Click the System Rights tab and select at least one option that allow users assigned to this role definition to log on, then click OK.

In this example, users open a secure shell to switch to the service account so you might select Non-password (SSO) login is allowed.

If a service account instead of a user account is used to log on, it might be mapped to a disabled Active Directory account. In this case, you might select the Account disabled in AD can be used by sudo, cron etc system right to ignore the disabled state and allow the service account to log on.
Select the new role definition, right-click, then click Add Right.
Select the rights you defined for running the switch user (su -) command and logging on with the PAM application ssh, then click OK.

Assign an Active Directory Group to the Role

As discussed in previous chapters, you should associate Verify Privilege Server Suite 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.

If you are using the recommended deployment structure and naming conventions, you would create the Active Directory group in the ou=Service Accounts, ou=Centrify organizational unit using the format ZoneName_Service_RoleName. For example, create an Active Directory group named sanfrancisco_service_oracle. You can then assign the new role definition to that group.

To assign the role definition to an Active Directory group:

Open Access Manager.
Expand Zones and the individual parent or child zones required to select the zone name where you want to assign the role definition.
Expand Authorization.
Select Role Assignments, right-click, then click Assign Role.
Select the role definition you created for using secure shell and switching to the service account access, such as oracle_service, then click OK.
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.
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.

Creating a Role Definition for Temporary Root Access

Another common use case for role definitions occurs when you want to provide temporary access to privileged commands. For example, you might want to provide temporary rootlevel access to an application developer troubleshooting a problem on a production server or to a consultant you’ve hired for a specific period of time. These types of role definitions are often used as overrides on individual computers.

The steps for creating a role definition with temporary root access are similar to the steps for creating the other roles, except that you specify time constraints for the role. The time constraints might include specific hours of the day, days of the week, or a start and end time for a role assignment. The next sections summarize the steps for creating a role with temporary root-level access.

Define a Command that Allows Root Access

The steps for defining a right for switching to the root user are similar to defining the right to run commands for the root-equivalent user, but it is recommended that you create a separate right definition for this case.

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 emergency_access, for this command right and, optionally, a description for this right, then define the right to switch to the root user:
- Type the command for switching to the root user. For example, type su - root in the Command field.
- Verify Standard user path is selected.
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.

Create a Role Definition for Temporarily Running as Root

After you have defined the right to switch to the root user, you can create a role definition for that right.

To create a role definition with the right to run the emergency_access command:

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 emergency_access and descriptive text such as Users with this role can temporarily run commands with root privileges.
Click Available Times to specify days of the week or select times of the day for making the role definition available.

For example, you might want to allow access only on Friday, Saturday, and Sunday and deny access the rest of the week. After you have set the days and times for the role definition to be available, click OK.
Click OK to save the role definition.
Select the new role definition, right-click, then click Add Right.
Select the emergency_access command you defined for switching to the root user, then click OK.

To use this role, a user must be assigned to the UNIX Login role for the zone or a role definition that has, at a minimum, the following System Rights:
- Password login and non-password (SSO) login are allowed
- Login with non-Restricted Shell

Assign the Role as a Computer-level Override

In most cases, a role definition of this type is assigned to a specific computer rather than applied to all computers in a zone.

To make a role assignment on an individual computer:

Open Access Manager.
Expand Zones and the individual parent or child zones required to select the zone name that contains the computer for which you want to define a computer-level role assignment.
Expand Computers, then select the specific computer on which you want to make a role assignment.
Select Role Assignments, right-click, then click Assign Role.
Select the role definition you created for temporary root access, such as emergency_access, then click OK.
Click Add AD Account to search for and select the Active Directory user who should have temporary root access:
- Leave User as the object to find.
- Optionally, type all or part of the use name.
- Click Find Now.
  
  Select the user in the results, then click OK.
Deselect Start immediately and set a specific Start time for the role assignment.
Deselect Never expire and set a specific End time for the role assignment.
Click OK.

Verify the Role Assignment on the Computer

You can run dzinfo --roles or dzinfo username --roles to see if the emergency_access role is available based on the start time for the role definition and the local time of the Linux or UNIX computer.

At the specified start time for the role assignment on the local computer, the user you assigned to the emergency_access role can type the following command:

dzdo su - root

The user is not prompted to provide the password and becomes the root user on the local computer until the specified role assignment end time. The one caveat to be aware of is that the user would continue to have root access after the specified end time if the shell session remains open continuously. If a user is still logged on after the time period has expired, you should check whether the user still requires root-level access. If the session has remained open but the user should no longer have root access, kill the session and log the user off.

Creating a Role Definition With Specific Privileges

The previous examples of role definitions granted broad privileges. You can also use role definitions to 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 7to 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 UNIX 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 when they execute privileged commands using dzdo by setting the Authentication required 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 authentication, you would click the Attributes tab, select Authentication required then select one of these options:

User’s password if users are required to enter their own password before executing the command.
Run as target’s password if users are required to enter the password for the target account that is executing the command.

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 Run as target’s password option requires the user to know the privileged account password. For example, if the run-as user is root, the Run as target’s password authentication option requires the user to 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 of 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

Creating a Role Definition with Rescue Rights

The Rescue rights option allows you to control which users should be able to log on if problems with the authorization cache or auditing service are preventing all other users from logging on. For example, if you have a computer with sensitive information, such as credit card numbers or intellectual property, you might require auditing for all users in the role with access that computer. If the auditing service is stopped or removed on that computer, no one would be able to log on and use the computer until auditing is restored. If you create a role with the Rescue rights option selected, only the users assigned to that role are able to log on and continue working until the problem that caused the lockout is found and fixed.

Users who are in a role granted access because they have rescue rights can still be audited through the system logging facility. However, their activity is not recorded in the audit store database if the auditing service is not available.

Creating Additional Custom Roles and Role Assignments

The previous sections described common roles that organizations implement to begin the process of migrating and removing locally defined privileged accounts. For most organizations, locallydefined accounts with privileged access present a security risk and are often identified as a compliance issue by auditors.

By creating role definitions similar to those described in this chapter, you can eliminate the need to share root and service account passwords while still providing privileged access to computers where it’s needed. These additional roles are not required, however. You can choose to create them or create a completely different set of role definitions to suit your organization. For example, you might decide to create custom roles specifically tailored to the needs of database administrators, backup operators, and web application developers. Similarly, you might decide to create separate role definitions that are customized with AIX command rights for AIX administrators that are different from the command rights defined for Solaris administrators.

As with the common role definitions, additional custom role definitions can be created in the top-level parent zone and available throughout the zone hierarchy or in any child zone. They can also span all the computers in a zone or be assigned specifically to individual computers.

If you plan to create your own custom role definitions and role assignments, keep the following key points in mind:

Rights associated with roles are cumulative. Users receive all of the rights in all of the roles they are assigned.
Users must be assigned at least one role that allows an interactive login or Kerberos authentication to have any access to any computers. For existing users, this is accomplished by assigning the default UNIX Login role during the migration to Active Directory.
Users must be given the Login with non-Restricted Shell system right to have access to a full shell. If they assigned in a role without this right, they can only execute the commands explicitly defined for their role.

For users who have previously had full shell access, this limitation can be frustrating, unexpected, and unworkable. Before placing or moving users into a restricted role, be sure those users and managers throughout the organization are well-informed and wellprepared for the change and understand the business reasons for the change.

Working with Computer Roles

In addition to the role definitions that confer specific rights when assigned to users and groups, Verify Privilege Server Suite provides a mechanism for linking a specific group of computers to a group of users with a specific role assignment. These computer-based access rules, called computer roles, identify computers that share a specific attribute that you define and a set of users with common access rights.

For example, you can define a computer role that identifies a set of computers as Oracle database servers linked to a set of users who have been assigned the oracle_dba role. You can then add and remove users from the Active Directory role group linked to the oracle_dba role to grant or remove the rights associated with the oracle_dba role. In this example, the computer role identifies computers that host Oracle databases and the set of users assigned the database administrator role.

The same set of computers might include computers with AIX and Solaris operating systems. You could then create separate computer roles that link the AIX computers to a group of AIX administrators and the Solaris computers to a group of Solaris administrators.

Planning to Use Computer Roles

Because computer roles provide you with a great deal of flexibility for defining access rights, you might want to do some planning before you create new computer roles. For example, before you create a computer role you must know the criteria you want to use to group computers into one or more Active Directory security groups. You must also identify the users who will have a common set of access rights based on the computer grouping.

At a high-level, defining a computer role requires the following:

Identify computer roles you want to define.

Decide on the attribute the computers in a particular group share. For example, you can use a computer role to identify computers in the web farm, that host specific applications, or serve a specific department.
Identify the users for the computer role and create Active Directory groups for them.

You might need multiple groups because different sets of users have different access requirements. For example, if you are creating a computer role for a set of Oracle servers, you might need separate Active Directory groups for database users, database administrators, and backup operators.
Identify the role definitions each set of users should be assigned.

You might need to create specific access rights and role definitions for different sets of users. For example, if you are creating access rights for database users, database administrators, and backup operators, the database users may be able to use the predefined UNIX Login role, while administrators need permission to run privileged commands, and backup operators might be assigned a limited set of commands in a restricted shell.

How Computer Roles Simplify the Management of Access Rights

Deciding how best to use computer roles requires some upfront planning and configuration that might not be part of your initial deployment plan. To make effective use of computer roles, you also need to plan for and prepare appropriate role definitions for different sets of users. However, computer roles provide a powerful and flexible option for managing access to Verify Privilege Server Suite-managed computers using your existing processes and procedures for managing Active Directory group membership.

For example, if you create a computer role group for Oracle servers and you deploy a new Oracle server, you simply add the computer account for the new server to the computer role group in Active Directory. If new database administrators join your organization, you simply add them to the Active Directory security group for Oracle database administrators. The computer role links the computer role group to the user role assignment and no additional updates are needed to accommodate organizational changes. If you need to modify the access rights, you can change the role definition and have the changes apply to all members of the group.

Because creating and managing computer roles is typically an ongoing administrative task after initial deployment, it is covered in the Administrator’s Guide for Linux and UNIX. <!--TODO: xref ->