Trusted Solaris Administrator's Procedures

Chapter 4 Managing Users and Rights With SMC

This chapter describes how to add rights and users. It also points out system and security requirements when configuring users. This chapter includes the following tasks:

Before Setting Up User Accounts

If you are using a name service, you must have the following set up before creating accounts:

The home directory server must be mounted on the name service master.
The mail server must be mounted on the name service master.
The tsol_smc.tbx and tsol_name-service.tbx toolboxes must be edited with the name service master's name and address on the name service master. The install team set this up in "Edit SMC Toolbox Definition for the Name Service" in Trusted Solaris Installation and Configuration.

The following information is useful to have when you set up users in the SMC Users tool.

A list of the available rights profiles.

The "Rights Profile Descriptions" in Trusted Solaris Administration Overview lists the rights profiles that are delivered with the Trusted Solaris release. If additional rights profiles have been created at your site, see your own internal documentation for a description. See "To List All Rights" for how to list the rights profiles on your system and in your name service. The smprofile(1M) man page also provides examples.
A list of the available roles.

See "To List All Roles" for how to list the roles in your name service. The smrole(1M) command with the list option lists all the roles. If your site has added or modified roles, see your internal documentation for a description of the site's roles.
A list with the name of each person who needs an account, along with the responsibilities, roles, clearances and minimum labels assigned to each. You also need to determine who is going to be able to assume administrative roles.

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.

Adding or Modifying a Rights Profile

The Security Administrator role creates new rights profiles and modifies existing ones. A right or rights profile is a collection of actions and commands with security attributes, plus authorizations. A rights profile can be part of another rights profiles, or stand on its own.

The Rights tool in the SMC GUI displays the existing rights profiles. Each rights profile has a corresponding help file that displays in the GUI. The administrator should create a right's accompanying help file before creating the right itself. The GUI prompts for the name of the help file when the administrator creates the new right. See "To Create a Help File for a Rights Profile" and "To Create a Rights Profile".

Managing Users and Rights (Tasks)

To List All Rights

Once the SMC is initialized, users or roles can view one rights profile at a time in the Rights tool under Users in the SMC, or use the smprofile(1M) command described below to see a list of all profiles.

Assume the Security or System Administrator role.

To list the rights profiles in a name service domain, use the smprofile list command with the -D option to specify the name_service_type:/server_name/domain_name. Provide a password when prompted.

The following example lists the profiles that are defined in the NIS+ domain tropics.example.com whose NIS+ master server is toucan. The command is being executed on the tern system:

$ /usr/sadm/bin/smprofile list -D nisplus:/toucan/tropics.example.com -- 
Authenticating as user: janez

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password :: rolePassword
Loading Tool: usermgr.cli.profile.UserMgrProfCli from tern
Login to tern as user janez, role admin was successful.
Download of usermgr.cli.profile.UserMgrProfCli from tern was successful.
Profile name: All Actions Description: A complete set of actions 
              (no commands) without any privilege.
Profile name: All Authorizations Description: Grant all authorizations.
Profile name: All Commands Description: A complete set of commands 
              (but no actions) without any privilege.
Profile name: All Description: Execute all commands and actions.
...
Profile name: User Security Description: Manage passwords, clearances.
Profile name: Trusted Edit Description: Use the trusted_edit script
              when editing.

The following example lists the security attributes of the All profile.

$ /usr/sadm/bin/smprofile list \
-D nisplus:/toucan/tropics.example.com -- -l -n All
...
Profile name:   All
  Description:  Execute all commands and actions
  help:         RtAll.html
  Command:      *;*;*;*;*
     policy:    tsol
     type:      act
  Command:      *
     policy:    tsol
     type:      cmd

To Create a Help File for a Rights Profile

Assume the Security Administrator role and go to an ADMIN_LOW workspace.

Using the Admin Editor, open a new help file with an.html extension in the directory /usr/lib/help/profiles/locale/locale/.

For example, FilePriv.html.

In the help file, describe the rights profile you have added.

Follow the online help when creating the help file. For example:

<HTML>
<HEAD>
Copyright (c) 2001 by Sun Microsystems, Inc. All rights reserved. 
<!-- SCCS keyword #pragma ident   "%Z%%M% %I%     %E% SMI; TSOL 2.x" -->
<!-- FilePriv.html -->
</HEAD>
<BODY>
Allows a user to specify the allowed and forced privileges to be associated
with the execution of a program file. 
<P>
If the name of the file privileges rights profile is grayed, you are not 
allowed to add or remove it.
</BODY>
</HTML>

Save and quit the new help file.

Enter the name of the help file in the Help File Name: field when creating the right.

To Create a Rights Profile

Assume the Security Administrator role and go to an ADMIN_LOW workspace.

Create a help file for the new rights profile.

Use the procedure "To Create a Help File for a Rights Profile".

Bring up the SMC in the desired scope and click the Users tool. Supply a password when prompted.

Double-click the Rights tool.

To create a rights profile, select Add Right from the Action menu.

Use the online help when creating the new right.

Name the profile Custom rolename Role, and describe it.

For example, for a role whose username is auditadmin, you would create an empty Custom Auditadmin Role profile. In the profile's description you would enter:
Modify this rights profile to customize the Audit Administrator role

Select the action or command to add to the right.

See the Trusted Solaris man pages for individual commands for the security attributes needed by the command or any of its options to succeed. For example, if the command requires privilege to accomplish a task, adding the privilege to the command enables it to execute with the specified inherited privileges when a user or role has been assigned this rights profile.

Click the Set Security Attributes button to enter the information requested in the help for the Ownership and Extended Attributes areas.

For example, by adding the name of an installation program to a rights profile, assigning to the program a real UID of 0, and then assigning the profile to a role, the Security Administrator can enable an installation program to succeed when run by a role that has another UID, such as the System Administrator role.

Add authorizations if needed.

A rights profile can contain commands only, actions only, authorizations only, or a combination of commands, actions, and authorizations.

Click OK to save the new rights profile.

To Modify a Rights Profile

Assume the Security Administrator role and go to an ADMIN_LOW workspace.

Bring up the SMC in the desired scope and click the Users tool. Supply a password when prompted.

Double-click the Rights tool, select the profile, then choose Properties from the Action menu.

Refer to the online help when modifying the right.

Click OK to save the rights profile.

To Create a User Template

Assume the System Administrator role and go to an ADMIN_LOW workspace.

Bring up the SMC Users tool. If you are using a name service, do this procedure on the name service master.

Supply a password when prompted.

Click the User Templates tool.

Choose Add User Template from the Action menu.

Decide on a Login Shell.

You can assign a profile shell to users by choosing other and then typing in the path to a profile shell: /bin/pfsh, /bin/pfcsh, or /bin/pfksh. While working in a profile shell, an account can execute only those commands that are in the account's set of profiles. See the pfexec(1) man page for descriptions of the profile shells.

The Bourne, Korn, and C shells allow the account to execute all available commands that do not need to inherit privilege. See the following man pages for more information about the listed shells: csh(1), ksh(1), bash(1), tsh(1), zsh(1).

Use the online help to guide you through the General, Group, Home Directory, Sharing, Password Options, and Mail tabs.

The following is a text example of a User Template.

Template Name: Desktop User
Template Description: Users with C-shells
General - Login shell = C Shell
        - Account is Always Available
Group   - Primary Group = staff
        - Secondary Groups = writers
Home Directory - Server = /net/egret.aviary
               - Path   = /net/egret/export/home
	                 Append User Names to path above
               - Skeleton directory = /etc/skel/Csh
               - Automatically mount
Home Directory Sharing
        - Group members have Read-only Access
        - All users have Read-only Access
Password Options - User must keep for 31 days
                 - Before change, alert user 5 days
                 - User must change within 5 days
                 - Expires if not used for 31 days
Mail Server    - /net/pigeon.aviary

Click OK when finished to save the template.

To Add a User Account

Assume the System Administrator role and go to an ADMIN_LOW workspace.

Bring up the SMC in the desired scope and click the Users tool. Supply a password when prompted.

Double-click User Accounts.

All configured users are displayed as icons labeled with their usernames.

Choose one of the following from the Action menu:
- Add User->With Wizard
- Add User->From Template
  
  To use the From Template option, you need to first create a template. See "To Create a User Template" for the procedure.
Depending on whether you use the Wizard or Template method, some fields will not be available.

Enter the user's name and ID.

User names and UIDs must be unique to ensure traceability of activities back to a single identified user. Therefore, each user name and UID should not be duplicated anywhere on the network, and should not be reused during the life of the system.

Enter a description.

The description will appear in the user's email From field. For example,
From: Bar Bar -- Useful Worker

Continue to create the user, referring to the online help when necessary.

Also see "Adding or Modifying a User Account" for guidance.

To Modify a User Account

The Security Administrator role follows this procedure to add user security attributes, such as passwords, to user accounts.

Assume the Security Administrator role and go to an ADMIN_LOW workspace.

Bring up the SMC in the desired scope and click the Users tool. Supply a password when prompted.

Double-click the User Accounts tool, highlight the username, then choose Properties from the Action menu.

Use the online help when modifying the user's properties.

Click OK when you have entered all the changes.

To Assign a Right to a User

The right must exist before assigning it. See "Managing Users and Rights (Tasks)" for creating a rights profile.

Assume the Security Administrator role and go to an ADMIN_LOW workspace.

Bring up the SMC in the desired scope and click the Users tool. Supply a password when prompted.

Double-click the User Accounts tool, highlight the username, then choose Properties from the Action menu.

Use the online help when modifying the user's security attributes.

Click the Rights tab.

Order the rights profiles appropriately. Move the new right above the All profile, and further up if necessary.

When the user invokes a command or action, the profile mechanism uses the first instance of the command or action, with its security attributes. So, if two rights profiles share a command, and both are assigned to one user or role, the command in the first profile is executed, with its attendant security attributes. The same command in the second profile is not seen by the profile mechanism.

Click OK when you have entered all the changes.

To Assign an Authorization to a User

Assume the Security Administrator role and go to an ADMIN_LOW workspace.

Launch the Solaris Management Console and choose the appropriate scope. If you are using a name service, choose the name service scope.

Click Users and supply a password when prompted.

Double-click the Rights tool to create a new right with the authorization, if necessary. Save the new right.

See "To Create a Help File for a Rights Profile" and "To Create a Rights Profile" for the steps.

Add the new rights profile to the user's rights by opening the User Accounts tool, selecting the user, and editing the user's properties.

Use the online help for guidance.