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 user who is trusted with additional rights
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. You can also create roles. You can also combine the use of ARMOR roles with the roles that you create.
To use ARMOR roles, see Example 2, Using ARMOR Roles.
To create your own roles, you use the roleadd command. For a full list of the arguments to this command, see the roleadd(8) man page.
Caution - Do not configure a role with both the roleauth=user and auth_profiles=profiles keywords. The authentication will fail because the auth_profiles keyword authenticates against the current process owner's password (role), which is not the roleauth password (user). |
For example, the following commands create a local User Administrator role with a home directory and a pfbash login shell, and create a password for the role:
# roleadd -c "User Administrator role, local" \ -m -K profiles="User Security,User Management" accountadm 80 blocks # ls /export/home/accountadm local.bash_profile local.login local.profile # passwd accountadm Password: xxxxxxxx Confirm Password: xxxxxxxx
where:
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(8) 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:
57 auditadm
55 fsadm
58 pkgadm
53 secadm
56 svcadm
59 sysop
54 useradm
After verifying that the UIDs and names are not in use, the administrator installs the package.
# 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
The rights that are assigned to ARMOR roles cannot be modified. To create a different configuration of rights, see 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 adoe # usermod -R=fsadm,pkgadm bdoe # usermod -R=secadm,useradm cdoe # usermod -R=svcadm ddoe # usermod -R=svcadm edoe # usermod -R=sysop fdoe # usermod -R=sysop gdoeExample 3 Creating a Role for an Application Administrator
The administrator creates a role for the Oracle database administrator (DBA) to ensure that the administrator's login name is in the audit trail. Because the oracle account is a role, users must log in to their own account and then switch user to the oracle role. This site has three DBAs.
# usermod -K type=role oracle # usermod -R oracle adoe # usermod -R oracle bdoe # usermod -R oracle cdoeExample 4 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" accountadmExample 5 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 7, Adding a Role to a User.
Example 6 Creating and Assigning a Role to Administer Cryptographic ServicesIn 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" cryptomgt # passwd cryptomgt New Password: xxxxxxxx Confirm password: xxxxxxxx # usermod -u 1111 -R +cryptomgt
The user with UID 1111 logs in, then assumes the role and displays the assigned rights.
$ su - cryptomgt
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 Managing Encryption and Certificates in Oracle Solaris 11.4.
You use the useradd command to create a login. For a full list of the arguments to the useradd command, see the useradd(8) 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 accountadm role that you created in Creating a Login for a Trusted User.
# useradd -c "Trusted Assistant User Manager user" -m -R accountadm \
-s /usr/bin/pfbash jdoe
80 blocks
# ls /export/home/jdoe
local.bash_profile local.login local.profile
where:
Creates a home directory for the user.
Assigns the name of an existing role.
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.
For more examples, see Setting Up and Managing User Accounts (Task Map) in Managing User Accounts and User Environments in Oracle Solaris 11.4.
You use the usermod command to modify a user account. For a full list of the arguments to the usermod command, see the usermod(8) 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 and a profile shell as the user's login shell:
# usermod -s /usr/bin/pfbash -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 7 Adding a Role to a UserIn this example, the administrator ensures that two trusted users are necessary to create regular users. The roles were created in Example 5, Creating Roles for Separation of Duty.
# usermod -R +accountadm 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(8) 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 8 Adding a Rights Profile as the Role's First Rights ProfileFor example, prepend a rights profile to the accountadm role:
# rolemod -K profiles+="Device Management" accountadm # profiles accountadm accountadm: Device Management User Management User SecurityExample 9 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" \ -K profiles="Printer Management,VSCAN Management,All" prtmgtExample 10 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 16, Assigning Privileges Directly to a User.
# 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 accountadm role to use their own password when assuming any assigned role, including the accountadm role.
# rolemod -K roleauth=user accountadm
Caution - Do not configure a role with both the roleauth=user and auth_profiles=profiles keywords. The authentication will fail because the auth_profiles keyword authenticates against the current process owner's password (role), which is not the roleauth password (user). |
The auth_profiles keyword is not designed for roles, though you can use it with roles. This keyword is designed for reauthenticating with a user's credentials without requiring the use of a separate role account.
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 accountadm Enter accountadm'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 11 Changing the Password of a Role in a Specific RepositoryIn 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 accountadm
Users who are currently performing administrative tasks in the role are prevented from continuing. The profiles command shows the following output:
accountadm $ profiles Unable to get user name