Creating Additional Custom Roles and Role Assignments

The previous sections described common role definitions that organizations implement to begin the process of migrating and removing locally defined privileged accounts. For most organizations, locally defined 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 are 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 well prepared for the change and understand the business reasons for the change.