Chapter 3 Managing User Accounts

This chapter describes essential decisions to make before creating regular users, and provides additional background for managing user accounts. The chapter assumes that the install team has set up a limited number of user accounts. These users can assume the roles that configure and administer the Trusted Solaris operating environment. See Trusted Solaris Installation and Configuration for details.

This chapter includes the following procedures:

• "To Modify Default User Label Attributes"

• "To Modify policy.conf Defaults"

• "To Set Up Startup Files for Users"

• "To Invoke .login or .profile During Login"

• "To Force dtterm to Launch New Shells as Login Shells "

• "To Customize Shell Initialization Files for Users"

• "To Enable a User to Track Others' Jobs on a System"

• "To Enable a User to Track All Others' Jobs"

Setup Before Creating User Accounts

The following decisions and setup affect what users can do in a Trusted Solaris environment and how easy it is for them to do it. Some decisions are the same as those you would make when installing a network of the Solaris software or other UNIX systems. However, there are decisions specific to the Trusted Solaris environment that affect site security and ease of use.

Decisions to Implement Before Creating Users

• Decide whether to change default user security attributes in the policy.conf(4) and the label_encodings(4) files. See "Managing Default User Security Attributes" for a description of the defaults.

• Decide which startup files, if any, should be copied or linked from each user's minimum-label home directory SLD to the user's higher SLDs. See "To Set Up Startup Files for Users" for the procedure.

• Decide whether to permit sourcing of shell initialization files and what content you want to provide. See "Managing Initialization Files".

• Decide whether to allow users to remotely log in from the command line. Users who are permitted to remotely log in from the command line require a rights profile that contains the appropriate authorization. The machines themselves must also be enabled for remote login. See "Managing Remote Logins" for a discussion of remote logins.

• Decide if users can access peripheral system devices, like the microphone, CD-ROM drive, and tape drive.

  If access is permitted to some users, decide if your site requires additional authorizations to satisfy site security. See "Authorizing Device Allocation" for the default list of device-related authorizations. "Adding New Authorizations" describes a finer-grained set of device authorizations, and "To Add an Authorization to the Environment" describes how to implement the new authorizations.

• Decide whether to control a device differently when it is allocated remotely or locally. See Table 12-2 for an example of handling remote and local device allocation differently. The example requires the Security Administrator to create new authorizations.

Decisions to Implement Before Users Log In

• Decide whether devices should be deallocated when the allocating user logs out or reboots the system. See "Configuring a Device" for more information.

• Decide whether to change the default security provisions in mail. See "Managing Trusted Solaris Mail Features" for mail setup that is most easily done before users log in and use mail.

• Decide whether to hide filenames whose label is higher than the label of the directory that contains the file. See "To Change Configurable Kernel Switch Settings" for how to change the switch that controls whether these upgraded file names are visible.

Managing Default User Security Attributes

Settings in the policy.conf(4) and the label_encodings(4) files together define default Trusted Solaris security attributes for user accounts. The values set explicitly in a user template override these values. Some of the values set in these files also apply to role accounts. The User Template default values are described in detail in "Adding or Modifying a User Account".

Label Encodings File Defaults

The label_encodings file defines the Minimum Label, Clearance, and Default Label View that are applied to a user account if the attributes are not explicitly set for the account. The values shown in the following table are those in the Trusted Solaris version of the label_encodings file. Typically, a site replaces the Trusted Solaris version during system configuration with a site version.

At some sites the names of administrative labels are considered to be classified information. The value EXTERNAL hides that classified information.

The user account's clearance and minimum label must be dominated by the highest label and must dominate the minimum clearance that are defined in the user ACCREDITATION RANGE section in the label_encodings(4) file. See Trusted Solaris Label Administration for more about labels.

The following algorithm determines which value the system uses:

1. If the administrator explicitly set a value in the Solaris Management Console when creating the user, use that value.

2. Otherwise, use the values for the "Default User ..." and "Default Label View" keywords in the label_encodings file.

3. If there is no specific value for the "Default User ..." and "Default Label View" keywords, use the Accreditation Range values.

policy.conf File Defaults

The following table shows the default settings in the policy.conf file.

So, users by default are authorized to view SMC data and to edit their own cron jobs; their system locks after 30 minutes of no activity; they can see the label that they are working in; they will not be able to log in if they fail to provide the correct password for three consecutive tries; they must type in a new password (possibilities will not be generated for them); and they can execute all commands and actions on the system without privilege.

The authorizations (AUTHS_GRANTED) and rights profiles (PROFS_GRANTED) that are defined in this file are in addition to any authorizations and profiles assigned to individual accounts. For the other fields, the following algorithm determines which value the system uses:

1. If the administrator explicitly set a value in the Solaris Management Console when creating the user, use that value.

2. Otherwise, use the value in the policy.conf file.

Managing Remote Logins

A remote login between two Trusted Solaris hosts is considered to be an extension of the current login session. An authorization is not required when:

• The user chooses the Remote Login option on the CDE login screen.

• The rlogin command does not prompt for a password.

  If an /etc/hosts.equiv or a .rhosts file in the user's home directory on the remote host lists either the username or the host from which the remote login is being attempted, no password is required. See the rhosts(4) and rlogin(1) man pages for more information.

For all other remote logins, including logins with the telnet(1) command, the Remote Login authorization is required.

See "To Create a Rights Profile" for how to create and see "To Assign an Authorization to a User" for how to assign a new profile to a user.

Managing Initialization Files

Administrators who are setting up shell initialization files must consider certain details that are either not as important in standard UNIX systems or do not apply. The differences exist because of the following aspects of the Trusted Solaris implementation:

• Home directories are multilevel directories (MLDs).

• A profile shell can be used to restrict an account's access to commands.

• The execution of the profile(4) file is restricted in the Trusted Solaris environment.

As in the Solaris environment, files in the skeleton directory are copied into the user's home directory. However, in the Trusted Solaris environment, a user has a home directory for every label that the user works in. So, files from the skeleton directory are copied to the user's first home directory single-label directory (SLD).

A user's first SLD is created by the administrator during account creation. The first SLD is at the label of the creating process, ADMIN_LOW. The following example shows a user's directory structure after first login, and then the user's home directory structure after working at different labels.

Example 3-1 User Home Directory Structure after First Login

/home/.MLD.janez/.SLD.0:      [ADMIN_LOW]
/home/.MLD.janez/.SLD.1:      [CONFIDENTIAL]

Example 3-2 User Home Directory Structure after Working at Different Labels

/home/.MLD.janez/.SLD.0:      [ADMIN_LOW]
/home/.MLD.janez/.SLD.1:      [CONFIDENTIAL]
/home/.MLD.janez/.SLD.2:      [TOP SECRET A B]
/home/.MLD.janez/.SLD.3:      [SECRET]
/home/.MLD.janez/.SLD.4:      [CONFIDENTIAL A B]
/home/.MLD.janez/.SLD.5:      [SECRET A B]
/home/.MLD.janez/.SLD.6:      [TOP SECRET]
/home/.MLD.janez/.SLD.7:      [UNCLASSIFIED]

To copy or link the startup files into other labeled home directories requires setup on the part of the Security Administrator role. See "To Set Up Startup Files for Users" for the procedure.

This section provides the background information needed to understand how startup files are administered in the Trusted Solaris environment. Also see the man pages for the csh(1), ksh(1), sh(1), and pfexec(1) commands.

A set of startup files is sourced by the window system as it comes up. The user's login shell determines which startup files are sourced, as shown in the following table.

Another set of startup files is read whenever a user brings up a shell in a terminal emulator, such as the cmdtool, shelltool, or dtterm (see "Controlling Which Startup Files Are Read When a Shell Comes Up").

Controlling the Sourcing of Startup Files

In the Trusted Solaris CDE window system, as in the standard CDE window system, accounts get an editable $HOME/.dtprofile file which controls whether the .login or .profile files are read by the desktop at login. See also the man pages for login(1) and profile(4). See "The Sourcing of Startup Files for the Profile Shell User" for the one exception to this behavior.

.dtprofile Files

In the Trusted Solaris environment, by default the .login or .profile files are not sourced by the window system. A .dtprofile file controls the sourcing. One of the following .dtprofile files is copied into each account's $HOME/.dtprofile:

• An /etc/dt/config/sys.dtprofile file that was created by the site's Security Administrator role, if the file exists, or

• The default /usr/dt/config/sys.dtprofile

The following figure illustrates how $HOME/.dtprofile is installed.

Figure 3-1 How $HOME/.dtprofile is Installed

In the default /usr/dt/config/sys.dtprofile, the DTSOURCEPROFILE variable that enables the sourcing of either file is commented out. Removing the # before the DTSOURCEPROFILE definition in any of the versions of the sys.dtprofile file causes the appropriate startup file to be read by the window system.

See the comments in the /etc/dt/config/sys.dtprofile file and "To Invoke .login or .profile During Login", if changing the default is consistent with your site's security policy.

If any modifications to a .login or .profile accidentally prevent the user from logging in, the user may use the Failsafe Session option on the CDE Login screen. Failsafe Session allows a login without reading any startup files.

The Sourcing of Startup Files for the Profile Shell User

The algorithm for reading .dtprofile files when an account has a profile shell as its login shell prevents an account from executing commands that are not permitted to the account.

When a user's login shell is specified as the pfsh, pfcsh, or pfksh, the window system does not consult an account's home directory. The window system uses either the default /usr/dt/config/sys.dtprofile or a version modified by the Security Administrator role in /etc/dt/config/sys.dtprofile.

Figure 3-2 How $HOME/.dtprofile is Bypassed for Profile Shell Users

Controlling Which Startup Files Are Read When a Shell Comes Up

As in the Solaris environment, shell initialization files are used to set search paths and other environment variables and to execute some useful commands and functions. The following table shows which startup files are read by default when each type of shell is launched.

The .profile or .login files are invoked only if the shell is also identified as the account's login shell. A shell that is invoked with a prefix of - (for example: - csh) is a login shell. This means, for example, that when a C shell is started using csh (without a - prefix), the .login file is not executed.

Forcing dtterm to Source $HOME/.login or .profile

By default, a shell started by dtterm is not launched as a login shell. Therefore, the $HOME/.login and $HOME/.profile files are not read. Any user or role can enable dtterm to launch a login shell. See "To Force dtterm to Launch New Shells as Login Shells " for the procedure.

The default .profile file for all roles contains a function to alias the adminvi(1M) command to vi(1), but the function does not take effect unless the Dtterm*LoginShell: true entry is made in the $HOME/.Xdefaults-hostname file. See "To Alias vi to adminvi".

Administering Skeleton Directories

The default skeleton path used by the Users tool in the Solaris Management Console is /etc/skel. By default, a set of initialization files for each of the shells are copied from the /etc/skel directory into a user account's $HOME directory and renamed. The directory /etc/skel/tsol exists for role initialization files. The following example shows the default contents of the directory.

Example 3-3 Contents of the Default /etc/skel Directory

trusted% cd /etc/skel
trusted% ls -R
local.cshrc local.login local.profile tsol/
tsol:
role.link_files role.profile

In the Trusted Solaris environment, files are automatically copied from the skeleton directory only into the SLD at the account's minimum label. Either the user or the administrator must create the files .copy_files and .link_files as described in "Using .copy_files and .link_files", to ensure that subsequently-created SLDs get copies of initialization files.

Accessing All Man Pages

To ensure that the man(1) command can find all of the man pages for the products that combine to make the Trusted Solaris product (Solaris software, CDE, and X windows), the MANPATH environment variable should include the directories: /usr/man, /usr/openwin/man, and /usr/dt/man See "To Set Up Startup Files for Users" for an example of adding the path to shell initialization files.

Using .copy_files and .link_files

The Trusted Solaris files .copy_files and .link_files are useful for multilevel accounts. The files help to automate the copying or linking of startup files into every SLD in an account's home directory MLD. Whenever a user creates a workspace at a new label, dtsession runs the updatehome(1M) command to read the contents of .copy_files and .link_files in the account's minimum label SLD, and copy or link every listed file into the new workspace.

The .copy_files file is useful when a user wants a slightly different startup file in different SLDs. Copying is desirable, for example, if users need to use different mail aliases when they are working at different labels. See "To Set Up Startup Files for Users" for an example.

The .link-files file is useful when a startup file should be identical at any label that it is invoked. For example, if there is one printer to handle labeled print jobs, that printer can be defined once in a startup file, like .cshrc. When the .cshrc file is listed in the file .link-files, .cshrc is linked to SLDs at other labels when those SLDs are created. See "To Set Up Startup Files for Users" for an example.

The following worksheet provides some examples of common files to copy or link.

Administering cron, at, and batch Jobs

In the Trusted Solaris environment, the Job Scheduler tool in the Solaris Management Console manages jobs. This section describes the difference in managing cron(1M) and its associated commands in the Trusted Solaris environment. See the System Administration Guide, Volume 2 for basic cron information. For Trusted Solaris modifications see also the man pages for at(1), atq(1), atrm(1), cron(1M), and crontab(1).

In the default policy.conf(4) file, all users are assigned the Basic Solaris User profile. This profile includes the Edit Owned Jobs authorization. The authorization enables users to manage their own cron or at jobs.

The crontab file is generated by a user or role account using the crontab(1) command. The atjob file is generated by a user or role account using the at(1) or batch command. In the Trusted Solaris environment, the crontab, at, and batch commands must be in one of the account's rights profiles.

In the Trusted Solaris environment, the crontabs and atjobs spool directories are MLDs that hold job files at different labels. With MLDs as spool directories, one user can have multiple crontab files at different labels within the crontabs directory, and, similarly, one user can have multiple atjob files at different labels within the atjobs directory.

Running a Job with a Profile Shell

If a job requires that a profile shell execute the job, the Security Administrator role must ensure that all of the job's commands are also in a rights profile assigned to the invoking user.

cron jobs can be executed using a profile shell. Profile shells are documented on the pfexec(1) man page. A profile shell can execute a cron job if:

• The invoking account's login shell is the one of the profile shells or

• The $SHELL environment variable is set to/bin/[pfsh|pksh|pcsh]

  Otherwise, the cron program uses the default Bourne shell, sh(1), for cron jobs.

For at jobs there is a third case in which the profile shell is used. A user can use the at program with the -c (for csh), -k (for ksh), -s (for sh), option along with the -P (for profile shell) option to specify the shell which should run the job. Therefore, at jobs are executed in the profile shell if:

• The invoking account's login shell is one of the profile shells or

• The $SHELL environment variable is set to a profile shell or

• The at command is specified with the -P option

  If none of the previously described conditions apply, the at program uses:

• Any shell specified with either the -c, -k, or -s options or

• The default shell, sh

Running Privileged Commands in Scheduled Jobs

If a command in an at or cron job needs to run with privileges, either forced or inheritable privileges may be made available. Enabling a command to run with forced privileges, so that the privileges apply no matter who executes the command, is insecure practice. Therefore, the Security Administrator role typically does the following to make the privileges available by inheritance:

1. Specify the command and any privileges it needs in one of the invoking user's profiles using the Rights tool in the SMC.

2. Specify that the job is executed with a profile shell, as described in "Running a Job with a Profile Shell".

   For more information, see "Assigning Inheritable Privileges to a Command or Action".

   For a cron job example, see "To Write a Profile Shell Script".

How the UNIX Domain Socket is Used for Communications

The communication mechanism between crontab(1), at(1), atrm(1), and cron(1M) in the Trusted Solaris environment is a UNIX domain socket. See the man page for libt6(3NSL).

The cron(1M) command is modified to create and bind the UNIX domain socket at ADMIN_LOW to /etc/cron.d/CRON. The /etc/cron.d/CRON file is also used as a lock file to prevent more than one execution of the clock daemon.

After it creates the UNIX domain socket, the cron command is changed to run at ADMIN_HIGH. The /var/cron/log file is created by the clock daemon at ADMIN_HIGH. The clock daemon logs its internal messages in this log file.

An ancillary file is created in the crontabs MLD for each crontab file and in the atjobs MLD for each atjob file. Modification of a crontab or an atjob file also changes the ancillary file data. The ancillary file is named username.ad for a crontab file, and jobname.ad for an atjob file. The ancillary file contains information used by cron to set up a job.

Trusted Solaris software is delivered with the following /var/spool/cron/crontabs files:

• At the ADMIN_LOW label, pairs of crontab and ancillary files for root, uucp, adm, and sys.

• At the ADMIN_HIGH label, pairs of crontab and ancillary files for root and lp.

Permitting Users to Access Others' Jobs

The default Trusted Solaris security policy does not permit users to access jobs owned by other users. To enable certain users to access jobs belonging to other users, the Security Administrator role can edit system files, or assign to the user a network-wide authorization through the Scheduled Jobs tool in the Solaris Management Console.

Conditions for Access to Other's Jobs

An account invoking the at, atq, atrm, or crontab commands can look at, edit, or remove jobs belonging to another user only when the following conditions are met.

For the at, atq, or atrm commands, the following conditions must apply:

1. The specified username or the username of the specified job's owner is one of the special system account names listed in the at.admin file and condition 3 is true, or

2. The username of the specified at job's owner is the name of a role account and condition 3 is true.

3. The account has the Edit Owned Jobs authorization in a rights profile.

4. If neither condition 1 nor condition 2 is true, the invoking account must have the Manage All Jobs authorization in a rights profile.

For the crontab command, the following conditions must apply:

1. The specified username is one of the special system account names listed in the cron.admin file and condition 3 is true, or

2. The specified username is one of the role account names and condition 3 is true.

3. The invoking account has the Edit Owned Jobs authorization.

4. If neither of 1 or 2 is true, the invoking account must have the Manage All Jobs authorization in a rights profile.

Assigning the SMC to Normal User Accounts

The Basic Solaris User profile provides the authorizations to view most information in the Solaris Management Console (SMC) tools. The default /etc/security/policy.conf file ships with an entry that assigns the Basic Solaris User profile to all users.

If the administrator has removed the Basic Solaris User rights profile from the policy.conf(4) file or assigns this rights profile only to selected users, most users will not be able to view the SMC information.

By default, only administrative roles have the required authorizations in their rights profiles to modify information in the SMC. While a Security Administrator can assign one or more of the required authorizations to a user account, such assignment bypasses the trusted path.

Preparing for User Accounts (Tasks)

To Modify Default User Label Attributes

When these changes are made while the system is being configured on the name service master, the files can be copied to each client computer as it is configured.

1. Assume the Security Administrator role and go to an ADMIN_HIGH workspace.

2. Review the default user attribute settings in the /etc/security/tsol/label_encodings file as shown in Table 3-1.

3. Modify the user security attributes in the label_encodings file by using the Edit Label Encodings action from the System_Admin folder.

   The label_encodings file should be the same on all hosts.

4. Distribute a copy of the file to every Trusted Solaris host.

   Follow the procedure in "(Optional) Copy Network Files to the /etc Directory" in Trusted Solaris Installation and Configuration.

To Modify policy.conf Defaults

When these changes are on the name service master, every user and role that is created inherits these values.

1. Assume the Security Administrator role and go to an ADMIN_LOW workspace. If you are using a name service, do this on the name service master.

2. Review the default settings in the /etc/security/policy.conf file as shown in Table 3-2.

3. Modify the settings in the policy.conf file by opening it in the Admin Editor and saving the new settings.

To Set Up Startup Files for Users

Users can put a .copy_files or .link_files into their home directory MLD at the SLD that corresponds to the minimum sensitivity label or can modify the files in the minimum label SLD if the files are already there. This procedure is for the administrator role to automate the setup for a site.

1. Assume the System Administrator role and go to an ADMIN_LOW workspace. If you are using a name service, do this on the name service master.

2. Set appropriate defaults for users in shell initialization files.

   For example, set the MANPATH to enable the users to access all Trusted Solaris man pages, and the LPDEST and PRINTER environment variables to send print jobs to a labeled printer.

   In a startup .cshrc file for users:

   setenv MANPATH /usr/dt/man:/usr/openwin/man:/usr/man setenv PRINTER conf-label-gluten setenv LPDEST conf-label-gluten

   In a startup .ksh file for users:

   export MANPATH /usr/dt/man:/usr/openwin/man:/usr/man export PRINTER conf-label-gluten export LPDEST conf-label-gluten

3. Go to your directory of startup files for users.

   For example,

   $ cd ~/startfiles_Cusers

4. Copy the generic copies of startup files into a skeleton directory.

   The following example adds startup files for the mailer, the C shell, dtlogin, and dtterm.

   $ cp .cshrc .login .mailrc .Xdefaults .Xdefaults-hostname \ /etc/skelC

5. Open the Admin Editor from the System_Admin folder in the Application Manager and enter the pathname to the .copy_files file, /etc/skelX/.copy_files.

   In the example, the pathname is /etc/skelC/.copy_files.

6. Type into .copy_files, one file per line, the files to be copied into the user's home directory at all SLDs. Save and quit the file.

   Use Table 3-4 for ideas. For example,

   # .copy_files for regular users # Copy these files to all home directory SLDs .mailrc .netscape .soffice :wq

7. Repeat for .link_files -- create the file and type into it the files to be linked from the user's minimum-label home directory SLD to higher SLDs. Save and quit the file.

   Use Table 3-4 for ideas. In Step 4 the administrator placed site copies in the /etc/skelC directory. For example,

   # .link_files for regular users with C shells # Link these files to all home directory SLDs .cshrc .login .Xdefaults .Xdefaults-hostname :wq

To Invoke .login or .profile During Login

This procedure changes the default for all users on the host where the change is made.

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

2. Use the File Manager or the command line to copy sys.dtprofile from /usr/dt/config to /etc/dt/config.

   Create the destination directory if it does not already exist.

   $ mkdir /etc/dt/config $ cd /usr/dt/config $ cp sys.dtprofile /etc/dt/config

3. Use the Admin Editor action in the System_Admin folder to open the sys.dtprofile file for editing.

   See "To Edit a Local File", if needed.

4. Remove the pound sign (#) before the DTSOURCEPROFILE variable assignment at the end of the file.

   After editing, the line should look like the following:

   DTSOURCEPROFILE=true

5. Save and close the file.

6. Distribute a copy of the file to every Trusted Solaris host that should have this change.

   Follow the procedure in "(Optional) Copy Network Files to the /etc Directory" in Trusted Solaris Installation and Configuration.

To Force dtterm to Launch New Shells as Login Shells

Do this procedure once for each home directory SLD at which the account works, or do it once in the home directory SLD at the account's minimum label, and then list the .Xdefaults-hostname in either .copy_files or .link_files, as described in "Using .copy_files and .link_files".

1. Go to your home directory.

2. Use a text editor to create or modify the .Xdefaults-hostname file.

3. Add the following entry.

   Dtterm*LoginShell: true

4. Write and quit the file.

5. Log out and log back in to put the change into effect.

To Customize Shell Initialization Files for Users

1. In the System Administrator role, follow the procedure to customize user initialization files in the section "Setting Up User Accounts Task Map" in System Administration Guide, Volume 1.

   The procedure tells you how to create three shell-specific skeleton directory names that are entered into the Skeleton path field when creating a user. The procedure also tells you to copy the local.login file to the skelC subdirectory, the local.profile file to the skelK subdirectory and the local.login file to the skelB subdirectory.

2. Create a skelP subdirectory for users whose default shell is a profile shell.

3. Create a .profile file and copy it into the skelP directory.

   See "Customizing a User's Work Environment" in System Administration Guide, Volume 1 for a discussion of what to include in initialization files.

4. When creating user accounts or user templates, enter the appropriate skelX pathname into the Skeleton path field.

To Enable a User to Track Others' Jobs on a System

A Security Administrator might want to set up a server, such as an audit administration server, so that the main user of the server can monitor all at jobs and cron jobs running on the system.

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

2. Open the Admin Editor from the System_Admin folder and type in the filename /etc/cron.d/cron.admin.

3. Add the user's username to the list.

   The user is now enabled to track others' cron jobs on this system.

4. Repeat for the file /etc/cron.d/at.admin, if the user is permitted to track other users' at jobs on this system.

5. Check that the user has the Basic Solaris User profile.

   The Basic Solaris User profile includes the Edit Owned Jobs authorization.

To Enable a User to Track All Others' Jobs

The ability to monitor the cron and at jobs of other users is typically restricted to a role. However, the Security Administrator can assign an authorizations to enable a user to monitor others' jobs.

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

2. Create a help file for the new right that you are about to create. Name it RtManageJobs.html, and provide it with text.

   For example,

   <HTML> <BODY> <p> This right allows users to manage other users' cronjobs and atjobs. The user can modify cronjobs and atjobs using the Jobs Scheduler. </BODY> </HTML>

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

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

4. Click the Users tool and supply a password when prompted.

5. Double-click the Rights tool, and create a Custom_Manage_Jobs rights profile that contains the Manage All Jobs authorization.

   The Manage All Jobs authorization allows the account to add, modify or delete any user's job and to modify cron policies in the Job Scheduler tool of the SMC.

   See "To Create a Rights Profile" for the steps. Substitute the names and help text for your new profile in the procedure.

6. Assign the right to the user by following the steps in "To Assign an Authorization to a User".