This section describes the commands that create and modify roles and users. To create or modify rights profiles, see How to Create a Rights Profile and How to Clone and Modify a System Rights Profile.
For information about roles, see Basics of User and Process Rights.
The main actions in creating and modifying roles and users are as follows:
Creating a role
Creating a trusted user
Modifying the rights of a role
Modifying the rights of a user
Enabling users to use their own password to assume a role
Changing a role password
Deleting a role
If you are going to use roles, you have several options. You can install the predefined roles from ARMOR and use them exclusively. Also, you can create roles and give them passwords. You can use ARMOR roles with the roles that you create.
To use ARMOR roles, see Example 3–1.
To create your own roles, you use the roleadd command. For a full list of the arguments to this command, see the roleadd (1M) man page.
# roleadd -c "User Administrator role, local" \ -m -K profiles="User Security,User Management" useradm 80 blocks # ls /export/home/useradm local.bash_profile local.login local.profile # passwd useradm Password: xxxxxxxx Confirm Password: xxxxxxxx
Describes the role.
Creates a home directory.
Assigns one or more rights profiles to the role. For the list of rights profiles, see Listing Rights Profiles.
The name of the role. For restrictions on acceptable strings, see the roleadd (1M) man page.
In this example, the security administrator installs roles that are defined by the ARMOR standard. The administrator first verifies that the role names do not conflict with any existing accounts, then installs the package, views the role definitions, and assigns the roles to trusted users.
First, the administrator ensures that the following UIDs and names do not exist in the naming service:
# pkg install system/security/armor
The package creates seven roles and local home directories in the /export/home directory.
To view the rights of each role, the administrator can list the profiles that are assigned to each role.
# profiles auditadm # profiles fsadm # profiles pkgadm # profiles secadm # profiles svcadm # profiles sysop # profiles useradm
These rights assignments cannot be modified. To create a different configuration of rights, you must create new roles, then create new rights profiles by following the steps in How to Clone and Modify a System Rights Profile.
Finally, the administrator assigns the roles to trusted users. The users' own passwords are used to authenticate to the role. Some users are assigned more than one role. Roles whose tasks are time-critical are assigned to more than one trusted user.
# usermod -R=auditadm adal # usermod -R=fsadm,pkgadm bdewey # usermod -R=secadm,useradm cfoure # usermod -R=svcadm ghamada # usermod -R=svcadm yjones # usermod -R=sysop hmurtha # usermod -R=sysop twongExample 3-2 Creating a User Administrator Role in the LDAP Repository
The administrator creates a User Administrator role in LDAP. The user provides a password when assuming the role, then does not need to supply a password for individual commands.
# roleadd -c "User Administrator role, LDAP" -m -S ldap \ -K profiles="User Security,User Management" useradmExample 3-3 Creating Roles for Separation of Duty
The administrator creates two roles. The usermgt role can create users, give them home directories, and perform other non-security tasks. The usersec role cannot create users, but can assign passwords and change other rights assignments. Neither role can set audit flags for users or roles, or change a role's password. The root role must perform those actions.
# roleadd -c "User Management role, LDAP" -s /usr/bin/pfksh \ -m -S ldap -K profiles="User Management" usermgt # roleadd -c "User Security role, LDAP" -s /usr/bin/pfksh \ -m -S ldap -K profiles="User Security" usersec
The administrator ensures that two people are necessary to create every regular user in Example 3–5.Example 3-4 Creating and Assigning a Role to Administer Cryptographic Services
In this example, the administrator on an LDAP network creates a role to administer the Cryptographic Framework, and assigns the role to UID 1111.
# roleadd -c "Cryptographic Services manager" \ -g 14 -m -u 104 -S ldap -K profiles="Crypto Management" cryptmgt # passwd cryptmgt New Password: xxxxxxxx Confirm password: xxxxxxxx # usermod -u 1111 -R +cryptmgt
The user with UID 1111 logs in, then assumes the role and displays the assigned rights.
% su - cryptmgt Password: xxxxxxxx # profiles -l Crypto Management /usr/bin/kmfcfg euid=0 /usr/sbin/cryptoadm euid=0 /usr/sfw/bin/CA.pl euid=0 /usr/sfw/bin/openssl euid=0 #
For information about the Cryptographic Framework, see Chapter 1, Cryptographic Framework, in Managing Encryption and Certificates in Oracle Solaris 11.2 . To administer the framework, see Administering the Cryptographic Framework in Managing Encryption and Certificates in Oracle Solaris 11.2 .
You use the useradd command to create a login. For a full list of the arguments to the useradd command, see the useradd (1M) man page. The rights-related arguments to the command are similar to the roleadd command, with the addition of the –R rolename option.
If you assign a role to a user, the user can use the role's rights after assuming the role. For example, the following command creates a trusted user who can assume the useradm role that you created in Creating a Login for a Trusted User.
# useradd -c "Trusted Assistant User Manager user" -m -R useradm jdoe 80 blocks # ls /export/home/jdoe local.bash_profile local.login local.profile
Determines the login shell for username. This shell can be a profile shell, such as pfbash. For reasons to assign a profile shell to a trusted user, see Usability Considerations When Assigning Rights. For a list of profile shells, see the pfexec (1) man page.
Assigns the name of an existing role.
You use the usermod command to modify a user account. For a full list of the arguments to the usermod command, see the usermod(1M) man page. The rights-related arguments to the command are similar to the useradd command.
If you assign a rights profile to a user, the user can use the rights after the user opens a profile shell. For example, assign a rights profile to a user:
# usermod -K profiles="User Management" kdoe
The changes are in effect at the user's next login. For users to learn how to use their assigned rights, refer them to Using Your Assigned Administrative Rights.Example 3-5 Adding a Role to a User
In this example, the administrator ensures that two trusted users are necessary to create regular users. The roles were created in Example 3–3.
# usermod -R +useradm jdoe # usermod -R +usersec mdoe
You use the rolemod command to modify a role account. For a full list of the arguments to the rolemod command, see the rolemod(1M) man page. The rights-related arguments to the command are similar to the roleadd command.
The values of key=value pairs, and the –A, –P, and –R options can be modified by a minus (–) or plus (–) sign. The – sign indicates to subtract the value from the currently assigned values. The – sign indicates to add the value to the currently assigned values. For rights profiles, the value is prepended to the current list of profiles. For the effects of being an earlier rights profile, see Order of Search for Assigned Rights.Example 3-6 Adding a Rights Profile as the Role's First Rights Profile
For example, prepend a rights profile to the useradm role:
# rolemod -K profiles+="Device Management" useradm # profiles useradm useradm: Device Management User Management User SecurityExample 3-7 Replacing a Local Role's Assigned Profiles
In this example, the security administrator modifies the prtmgt role to include the VSCAN Management rights profile after the Printer Management profile.
# rolemod -c "Handles printers and virus scanning" \ -P "Printer Management,VSCAN Management,All" prtmgtExample 3-8 Assigning Privileges Directly to a Role
In this example, the security administrator entrusts the realtime role with a very specific privilege that affects system time. To assign the privilege to a user, see Example 3–14.
# rolemod -K defaultpriv+='proc_clock_highres' realtime
The values for the defaultpriv keyword are in the list of privileges in the role's processes at all times.
To enable users to use their own password rather than a role password when assuming a role, modify the role.
The following command enables all users who are assigned the useradm role to use their own own password when assuming any assigned role, including the useradm role.
# rolemod -K roleauth=user useradm
Because a role can be assigned to many users, users who are assigned a role cannot change the role password. You must be in the root role to change a role password.
# passwd useradm Enter useradm's password: xxxxxxxx New: xxxxxxxx Confirm: xxxxxxxx
If you do not specify a repository, the password is changed in all repositories.
For more command options, see the passwd (1) man page.Example 3-9 Changing the Password of a Role in a Specific Repository
In the following example, the root role changes the password of the local devadmin role.
# passwd -r files devadmin New password: xxxxxxxx Confirm password: xxxxxxxx
In the following example, the root role changes the password of the devadmin role in the LDAP naming service.
# passwd -r ldap devadmin New password: xxxxxxxx Confirm password: xxxxxxxx
When you delete a role, the role immediately becomes unusable.
# roledel useradm
Users who are currently performing administrative tasks in the role are prevented from continuing. The profiles command shows the following output:
useradm # profiles Unable to get user name