To create a new role, you can be superuser, or you can use the Primary Administrator role. In this procedure, the creator of the new role has assumed the role of Primary Administrator.
You have already created users who can assume a role at your site. If the users are not yet created, create them by following the instructions in Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
You have been assigned the Primary Administrator role by following the procedures in Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Start the Solaris Management Console.
# /usr/sbin/smc &
For login instructions, see How to Assume a Role in the Solaris Management Console.
Click the Administrative Roles icon.
Select Add Administrative Role from the Action menu.
Create a new role by filling in the fields in the series of dialog boxes.
All tools in the Solaris Management Console display information in the bottom section of the page or at the left side of a wizard panel. Choose Help at any time to find additional information about performing tasks in this interface.
After filling in the properties of the role, the last dialog box prompts you for a user for the role.
# svcadm restart system/name-service-cache
In this example, the new role can do system administration tasks that are not connected to security. The role is created by performing the preceding procedure with the following parameters:
Role name: sysadmin
Role full name: System Administrator
Role description: Performs non-security admin tasks
Rights profile: System Administrator
This rights profile is at the top of the list of profiles that are included in the role.
The Operator rights profile can manage printers and back up the system to offline media. You might want to assign the role to one user on each shift. To do so, you would select the role mailing list option in the Step 1: Enter a Role Name dialog box. The role is created by performing the preceding procedure with the following parameters:
Role name: operadm
Role full name: Operator
Role description: Backup operator
Rights profile: Operator
This rights profile must be at the top of the list of profiles that are included in the role.
By default, the only rights profile that contains security-related commands and rights is the Primary Administrator profile. If you want to create a role that is not as powerful as Primary Administrator, but can handle some security-related tasks, you must create the role.
In the following example, the role protects devices. The role is created by performing the preceding procedure with the following parameters:
Role full name: Device Security
Role description: Configures Devices
Rights profile: Device Security
In the following example, the role secures systems and hosts on the network. The role is created by performing the preceding procedure with the following parameters:
Role full name: Network Security
Role description: Handles IPsec, IKE, and SSH
Rights profile: Network Security
A number of rights profiles are of limited scope. In this example, the sole task of the role is to manage DHCP. The role is created by performing the preceding procedure with the following parameters:
Role name: dhcpmgt
Role full name: DHCP Management
Role description: Manages Dynamic Host Config Protocol
Rights profile: DHCP Management
In this example, a role is added to an existing user. The user's role assignment is modified by clicking the User Accounts icon in the Users tool in the Solaris Management Console, double-clicking the user, and following the online help to add a role to the user's capabilities.
Are the role's rights profiles listed in the GUI from most to least powerful?
For example, if the All rights profile is at the top of the list, then no commands are run with security attributes. A profile that contains commands with security attributes must precede the All rights profile in the list.
Do the commands in the role's rights profiles have the appropriate security attributes?
For example, when the policy is suser, some commands require uid=0 rather than euid=0.
Is the rights profile defined in the appropriate name service scope? Is the role operating in the name service scope where the rights profile is defined?
Has the name service cache, svc:/system/name-service-cache, been restarted?
The nscd daemon can have a lengthy time-to-live interval. By restarting the daemon, you update the name service with current data.