Adding or Modifying a User Account

The System Administrator role creates user accounts. The Security Administrator role sets up the security aspects of an account, for example, the account's password. The roles use the Solaris Management Console (SMC) 2.0, a GUI-based "umbrella application" that serves as the launching point for administrative tools. The User Accounts tool in the SMC provides two ways to create a user -- from scratch using a "wizard", or from a template that you create.

Using the Wizard requires no preparation. However, its defaults cannot be changed and may not be appropriate for your site. For example, the default login shell is the Bourne shell, and the home directory server is the local system.

Creating one or more User Templates enables you to set a reasonable set of defaults for all new user accounts. Once the template is created, its defaults are added to the default user security attributes that are defined outside the SMC. The template plus the security defaults can create users whose attributes suit your users' preferences and your site's security policy.

Properly configured system-wide settings and one or more user templates enable the System Administrator role alone to add users. The Security Administrator role then can assign user security attributes, such as a password and a role assignment, when the system is ready for users to log in. See "To Create a User Template" for the procedure to create a template.

The following table shows the default values provided by the Wizard, and additional fields that can be set in a template. Note that you must specify or change values in the Wizard for each user you create, whereas you specify a value in a Template once. The Template value is then applied to every user that is created with that template.

Table 4-1 Configurable User Attributes in a Wizard versus a Template

User Attribute	Wizard Value	Possible Template Value
Login Shell	Bourne	Bourne, Korn, C, profile, others
Account Availability	Always Available	Always Available, Locked, or Available until date
Primary Group	specify any existing group	specify any existing group
Additional Groups	none -- cannot be set	specify any existing group
Home Directory Path	specify path	specify path
Home Directory Server	specify server	specify server
Home Directory Sharing	-rwxr-x--x	specify permissions on home directory
Copy Initial Files From	/etc/skel	specify a skeleton directory
Automount server?	automounted	specify whether to automount
Mail Server	specify	specify

As shown in the above table, a template will simplify user creation if your site includes users whose default shell is not Bourne, whose account should expire or be locked, who should belong to several groups, whose home directory and mail server are not on the local system, or who has skeleton files in a directory other than /etc/skel.

If a shell-specific subdirectory has been created for each of the shells, you need to enter the correct skelX subdirectory name into the Skeleton path field in the Copy Initial File From: field in a template.

Security information must still be entered by the Security Administrator, as the following table shows. For information about the files that contain default values, see "Managing Default User Security Attributes".

Table 4-2 User Security Attributes Assigned after Creation

User Attribute	Source of Default Value
User Password	none -- must be assigned by Security Administrator
Rights	policy.conf file
Roles	none -- must be assigned by Security Administrator
Labels	label_encodings file
Visible Labels	policy.conf file
Account Usage	policy.conf file
Audit	none -- must be entered by Security Administrator

Assigning Passwords to Users

The Security Administrator role assigns passwords to users after the user has been created. The password can be generated (Choose from List) or created by the administrator. The Security Administrator also specifies whether the user can pick a new password, or must choose one from a generated list when changing passwords.

Unlike the Solaris environment, the Trusted Solaris environment requires users and roles to use the TP (Trusted Path) menu Change Password option to change their own passwords. They do not use the command line.

Users can be forced to change their passwords at regular intervals. The password aging options limit how long any intruder who is able to guess or steal a password could potentially access the system. Establishing a minimum length of time to elapse before change also prevents a user with a new password from reverting immediately to the old password.

---

Note -

The passwords for users who can assume roles should not be subject to any password aging restraints.

---

Assigning Rights to Users

The Security Administrator role assigns rights to users after the user has been created. The administrator may assign no rights profiles (by default users get the Basic Solaris User rights profile), one rights profile, or multiple rights profiles.

The order of profiles is important. When the user invokes a command or action, the profile mechanism uses the first instance of the command or action in the account's profile set, with whatever attributes have been defined for the command or action in the profile where it is found.

You can use the sorting order of profiles to your advantage. If you want a command to run with different privileges from those defined for it in an existing profile, create a new profile with the desired privilege assignments for the command and insert that new profile so that the profile mechanism finds the new one first.

---

Note -

Do not assign any role profiles to a normal user account. Doing so would introduce some measure of risk and a good deal of confusion. Many of the administrative role's commands and applications do not work outside of the administrative role workspace because they require the trusted path attribute.

---

Assigning Roles to Users

The Security Administrator role assigns roles to users after the user has been created. A user is not required to have a role. A single user can have one or more roles if having more than one role is consistent with your site's security policy.

Assigning Trusted Solaris Attributes to Users

The Security Administrator role assigns Trusted Solaris Attributes to users after the user is created. If the administrator has set up correct defaults, assigning Trusted Solaris attributes is needed only for users who are exceptions to the defaults.

Assigning Audit Classes to Users

The Security Administrator role can assign audit classes to users after the user account is created. These audit classes are exceptions to the audit classes set up in the /etc/security/audit_control file on the system. See Trusted Solaris Audit Administration for more about auditing.