[Digital logo]
[HR]

OpenVMS System Manager's Manual


Previous | Contents

A user can also specify a date and time format by defining the LIB$DT_FORMAT logical. For example:

$ DEFINE LIB$DT_FORMAT LIB$DATE_FORMAT_002, LIB$TIME_FORMAT_006

5.11 Saving Your Customization

Once you have installed and customized your system, Digital recommends that you back up your system disk. To do so, follow the instructions in Section 10.17.

On VAX systems, back up the console volume (if applicable). If your computer has a console storage device, make a backup copy of your console volume in case your original becomes corrupted. The operating system provides a command procedure called CONSCOPY.COM (in the SYS$UPDATE directory), which copies your console volume to a blank one.

The procedure for backing up the console volume varies for different computers. For specific instructions on backing up the console volumes, see the upgrade and installation supplement for your VAX computer.


Chapter 6
Managing User Accounts

This chapter describes how to grant access to users on your system. It tells you how to add and maintain user accounts, and it describes the privileges that you can give and the resources that you can allocate to the users on your system. It also describes the system management features of the OpenVMS Mail utility (MAIL).

Information Provided in This Chapter

This chapter describes the following tasks:
Task Section
Managing system-supplied UAF Accounts Section 6.4
Preparing to add user accounts Section 6.5
Adding user accounts Section 6.6
Using command procedures for interactive accounts Section 6.7.1
Modifying a user account Section 6.7.2
Listing user accounts Section 6.7.3
Maintaining the user environment Section 6.7.4
Deleting a user account Section 6.7.5
Restricting the use of accounts Section 6.8
Using login procedures for restricted accounts Section 6.8.4
Setting up special accounts Section 6.9
Managing Mail Section 6.10
Managing system resources Section 6.11

This chapter explains the following concepts:
Concept Section
Understanding the user authorization file Section 6.1
Understanding the protection of authorization files Section 6.2
Understanding UAF login checks Section 6.3
Understanding system-supplied UAF accounts Section 6.4.1
Understanding account security Section 6.5.3
Understanding network proxy accounts Section 6.9.3
Understanding pages and pagelets Section 6.11.1

6.1 Understanding the User Authorization File

The system user authorization file (UAF), SYS$SYSTEM:SYSUAF.DAT, contains user account records. Each record consists of fields that provide information about the account's user name, login characteristics, login restrictions, and resource control attributes. You specify the account user name as a parameter to AUTHORIZE commands; the other fields are specified as qualifiers to AUTHORIZE commands.

The system uses the UAF to validate login requests and to set up processes for users who successfully log in. You create, examine, and modify UAF records with the Authorize utility (AUTHORIZE).

You can assign the following resource control attributes in the UAF record:

The following sections briefly discuss these resource control attributes.

6.1.1 Priority

A user's priority is the base process priority that the system uses to schedule computer time for the process associated with the user's account.

On VAX systems, priorities range in value from a low of 0 to a high of 31. 0 through 15 are timesharing priorities; 16 through 31 are real-time priorities.

On Alpha systems, priorities range in value from a low of 0 to a high of 63. 0 through 15 are timesharing priorities; 16 through 63 are real-time priorities.

The system schedules processes with real-time priorities strictly according to base priority---the executable real-time process with the highest base priority executes first. Processes with timesharing priorities are scheduled according to a slightly different principle, to promote equitable service to all users.

Leave the base priority at the default of 4 for timesharing accounts.

6.1.2 Limits and Quotas

Limits are set on system resources that can be reused; for example, the amount of memory that a process can use for I/O requests. Most limits restrict the use of physical memory. You set limits for processes associated with accounts through the appropriate UAF fields. You can change some of these limits later with DCL commands or by calling system services from programs.

A process passes on its resources to a subprocess (for example, when you create a subprocess with the SPAWN command) in one of several ways, depending on the resource type. Table 6-1 lists the different resource types.

Table 6-1 Resource Type Limits
Resource Type Description of Limit
Pooled A process and its subprocesses share the resource on a first-come, first-served basis until the limit is reached.
Nondeductible A subprocess receives the same limit on the resource as the creator receives. The creator's limit is not affected.
Deductible A subprocess receives a portion of the creator's resource. That portion is deducted from the creator's limit.
Systemwide A process and all created subprocesses with the same user name or account share the total limit on a first-come, first-served basis.

Normally, leave limits at their default values. For the default values for the system and user accounts, see the sample SYSTEM and DEFAULT user authorization file records supplied with the Authorize utility on your distribution kit. Also see Section 6.11 for a full description of limits and quotas.

6.1.3 Privileges

Privileges determine what functions users are authorized to perform on the system. System manager functions require privileges that are denied to most users. Because the SYSTEM account has full privileges by default, exercise caution in using it. For example, if you log in to the SYSTEM account, you can modify and delete any file regardless of its protection.

Table 6-2 categorizes system privileges and includes a brief definition of the activity permitted with each privilege. See the OpenVMS Guide to System Security for a full description of privileges.

Table 6-2 System Privileges
Category Privilege Activity Permitted
None None None requiring privileges
Normal NETMBX
TMPMBX
Create network connections
Create temporary mailbox
Group GROUP
GRPPRV
Control processes in the same group
Group access through system protection field
Devour ACNT
ALLSPOOL
BUGCHK
EXQUOTA
GRPNAM
PRMCEB
PRMGBL
PRMMBX
SHMEM
Disable accounting
Allocate spooled devices
Make machine check error log entries
Exceed disk quotas
Insert group logical names in the name table
Create/delete permanent common event flag clusters
Create permanent global sections
Create permanent mailboxes
Create/delete structures in shared memory
System ALTPRI
AUDIT
OPER
PSWAPM
SECURITY
SYSLCK
WORLD
Set base priority higher than allotment
Generate audit records
Perform operator functions
Change process swap mode
Control any process
Perform security-related functions
Lock systemwide resources
Objects DIAGNOSE
IMPORT
MOUNT
SYSGBL
VOLPRO
READALL
Diagnose devices
Mount a nonlabeled tape volume
Execute mount volume QIO
Create systemwide global sections
Override volume protection
Bypass existing restrictions to read an object
All BYPASS
CMEXEC
CMKRNL
DETACH
DOWNGRADE
LOG_IO
PFNMAP
PHY_IO
READALL
SETPRV
SHARE
SYSNAM
SYSPRV
UPGRADE
Disregard protection
Change to executive mode
Change to kernel mode
Create detached processes of arbitrary UIC
Write to a lower secrecy object or lower an object's classification
Issue logical I/O requests
Map to specific physical pages
Issue physical I/O requests
Possess read access to all system objects
Enable any privilege
Access devices allocated to other users
Insert system logical names in the name table
Access objects through system protection field
Write to a higher integrity object or raise an object's integrity level

Because certain images (such as SET.EXE) require access to the system UAF and are normally installed with the SYSPRV privilege, make sure you always grant system access to SYSUAF.DAT.

6.2 Understanding the Protection of Authorization Files

To display the protection codes for any file, use the DCL command DIRECTORY/PROTECTION.

Authorization files are created with the following default protections:

The procedures for adding a user account are discussed in detail in Section 6.6. Because the UAF is the prime repository for storing information about user accounts, it is important to understand its components before you add accounts.

6.3 Understanding UAF Login Checks

This section describes the system checks the login fields of the UAF when a user attempts to log in.

When a user activates a terminal (by turning it on and pressing Return if directly connected, by dialing in to a system and observing the remote connect protocol, or by connecting via a LAT), and that terminal is not allocated by a user process, the system prompts for a name and password. The user must enter a name and password combination that exists in a UAF record, or the system denies the user further access. If the name and password are accepted, the system performs the operations in Table 6-3.

Table 6-3 System Login Flow
Step Action Result
1. System examines the login flags. The system begins with DISUSER. If the DISUSER flag is set, the login attempt fails.

Note that setting this flag for powerful, infrequently used accounts (such as Field Service accounts) eliminates the risk of guessed passwords for those accounts.

2. System verifies primary or secondary day restrictions. After checking the current day type, the system determines whether hourly login restrictions are in effect (as defined by the /ACCESS, /DIALUP, /INTERACTIVE, /LOCAL, and /REMOTE qualifiers). If the current hour is restricted, the login fails immediately. Digital recommends that you limit nonbatch access of the SYSTEM account by using access times and day types. See Section 6.8.1 and Section 6.8.2.
3. System passes control to the command interpreter. The command interpreter is named in the user's UAF record; for example, DCL.
4. System checks whether SYS$LOGIN is defined. If SYS$LOGIN is defined, the logical name is translated (in the case of DCL, to SYS$MANAGER:SYLOGIN.COM) and that procedure executes.

If SYS$SYLOGIN is not defined, no system login is run.

If a command procedure is specified in the LGICMD field and that procedure exists, it executes. Otherwise, if the LGICMD field is blank, the user's command file (named LOGIN.COM if the CLI is DCL), which is located in the SYS$LOGIN directory, executes automatically (if it exists).

The system will not execute both a command procedure specified in the LGICMD field and a user's LOGIN file; if a procedure is specified in the LGICMD field, the system uses that procedure by default. You can, however, instruct the system to execute a user's LOGIN by calling it from within the procedure specified in LGICMD.

After a successful login, the command interpreter prompts for user input (DCL usually displays a dollar sign), and the user responds with commands acceptable to the command interpreter. (DCL accepts those commands documented in the OpenVMS DCL Dictionary.) However, the system prohibits activities that violate the user's privilege allowance or exceed resource quotas.

6.4 Managing System-Supplied UAF Accounts

Typically, you use the UAF supplied with the distribution kit. (You can, however, rename the UAF with the DCL command RENAME, and then create a new UAF with AUTHORIZE.) Allow access to this file only to those with SYSTEM privileges. See the AUTHORIZE section in the OpenVMS System Management Utilities Reference Manual for guidelines on protecting system files.

The UAF is accessed as a shared file. Updates to the UAF are made on a per-record basis, which eliminates the need for both a temporary UAF and a new version of the UAF after each AUTHORIZE session. Updates become effective as soon as you enter AUTHORIZE commands, not after the termination of AUTHORIZE. (For this reason, do not enter temporary values with the intent of fixing them later in the session.)

The Authorize utility (AUTHORIZE) provides a set of commands and qualifiers to assign values to any field in a UAF record. See the Authorize utility section in the OpenVMS System Management Utilities Reference Manual for complete information about UAF record fields and the commands and qualifiers used to assign attributes to these fields.

6.4.1 Understanding System-Supplied UAF Accounts

On VAX systems, the UAF on software distribution kits contains five accounts: DEFAULT, FIELD, SYSTEM, SYSTEST, and SYSTEST_CLIG.

On Alpha systems, DEFAULT and SYSTEM accounts are created for you. You can use SYS$MANAGER:CREATE_SPECIAL_ACCOUNTS.COM to create SYSTEST, SYSTEST_CLIG, and Field Service accounts, as explained in Section 6.4.2.

Table 6-4 describes system-supplied UAF accounts.

Table 6-4 System-Supplied UAF Accounts
UAF Record Description
DEFAULT Serves as a template for creating new user accounts. A new user account is assigned the values of the DEFAULT account except where you explicitly override those values. Thus, whenever you add a new account, you need only specify values for fields that you want to be different. You cannot rename or delete the DEFAULT account from the UAF.

The following AUTHORIZE command creates a new account having the same values as the DEFAULT account, except that the password, UIC, and default directory fields are changed:

UAF> ADD 
      MARCONI/PASSWORD=QLP6YT9A/UIC=[033,004]/DIRECTORY=[MARCONI]
      

Section 6.6 gives an example of how to use AUTHORIZE to add a user account. Section 6.7.4 explains how to create and use additional default templates.

FIELD Permits Digital support representatives to test a new system.

+ On VAX systems, the default Field Service account has the user name FIELD.

++ On Alpha systems, you name Field Service accounts for specific Digital support representatives; for example, Mary_Smith or John_Jones.

SYSTEM Provides a means for you to log in with full privileges. You can modify the record for the system manager's account but you cannot rename it or delete it from the UAF.

Caution

Do not change the SYSTEM account UAF record fields for the default device, directory, and privileges. Installation of maintenance releases of the operating system and optional software products depends on certain values in these fields.

Note any hourly or daily restrictions that you have implemented on the SYSTEM account when performing upgrades from the SYSTEM account.

SYSTEST Provides an appropriate environment for running UETP, a User Environment Test Package, on standalone systems. (See Chapter 17.)
SYSTEST_CLIG Provides an appropriate environment for running UETP in an OpenVMS Cluster environment. SYSTEST_CLIG accounts have no passwords associated with them. (See Chapter 17.)


+VAX specific
++Alpha specific

6.4.2 Creating Accounts on Alpha Systems (Alpha Only)

On Alpha systems, you can use the SYS$MANAGER:CREATE_SPECIAL_ACCOUNTS.COM command procedure to create SYSTEST, SYSTEST_CLIG, and multiple Field Service accounts.

6.4.2.1 Creating Field Service Accounts (Alpha Only)

On Alpha systems, you can use CREATE_SPECIAL_ACCOUNTS.COM to create accounts for Digital support representatives. In creating these accounts, follow these guidelines:

The following example shows typical dialogue with CREATE_SPECIAL_ACCOUNTS.COM when it is used to create a Digital Field Service account:

$ @CREATE_SPECIAL_ACCOUNTS.COM 
 
    This procedure creates accounts. 
 
    Passwords may be needed for the following accounts: 
 
        SYSTEST, Field Service 
 
    Passwords must be a minimum of 8 characters in length.  All passwords 
    will be checked and verified.  Any passwords that can be guessed easily 
    will not be accepted. 
 
 
* Do you want to create an account for SYSTEST (Y/N): N [Return]
 
* Do you want to create an account for SYSTEST_CLIG (Y/N): N [Return]
 
* Do you want to create an account for Field Service (Y/N): Y [Return]
* Enter username for Field Service account: john_jones [Return]
* Enter password for JOHN_JONES: 
* Re-enter for verification: 
 
$ 

Note that the system does not display the password or password verification that you enter.

Disabling Field Service Accounts (Alpha Only)

You can use the Authorize utility (AUTHORIZE) to disable Digital support representative accounts when these accounts are not in use and enable them again when they are needed.

To disable an account, use the AUTHORIZE command in the following format:

MODIFY username/FLAGS=DISUSER 

For example:

$ RUN SYS$SYSTEM:AUTHORIZE
UAF> MODIFY JOHN_JONES/FLAGS=DISUSER

The login flag DISUSER disables the account and prevents anyone from logging in to the account.

Reenabling Field Service Accounts (Alpha Only)

To reenable an account when it is needed again, run AUTHORIZE and enter the command in the following format:

MODIFY username /FLAGS=NODISUSER 

For example:

UAF> MODIFY JOHN_JONES/FLAGS=NODISUSER

6.4.2.2 Creating SYSTEST and SYSTEST_CLIG Accounts (Alpha Only)

The following example shows typical dialogue with CREATE_SPECIAL_ACCOUNTS.COM when it is used to create SYSTEST and SYSTEST_CLIG accounts:

$ @CREATE_SPECIAL_ACCOUNTS.COM 
 
    This procedure creates accounts. 
 
    Passwords may be needed for the following accounts: 
 
        SYSTEST, Field Service 
 
    Passwords must be a minimum of 8 characters in length.  All passwords 
    will be checked and verified.  Any passwords that can be guessed easily 
    will not be accepted. 
 
 
* Do you want to create an account for SYSTEST (Y/N): Y 
* Enter password for SYSTEST: 
* Re-enter for verification: 
 
* Do you want to create an account for SYSTEST_CLIG (Y/N): Y 
 
    The SYSTEST_CLIG account will be disabled.  You must reenable 
    it (/FLAGS=NODISUSER) before running UETP but do not assign a password. 
 
* Do you want to create an account for FIELD_SERVICE (Y/N): N 
 
$ 

Enabling SYSTEST_CLIG Accounts (Alpha Only)

Although you create a SYSTEST_CLIG account using CREATE_SPECIAL_ACCOUNTS.COM, the account is disabled. Enable the account using the /FLAGS=NODISUSER command; for example:

UAF> MODIFY SYSTEST_CLIG/FLAGS=NODISUSER

Disabling SYSTEST_CLIG Accounts (Alpha Only)

To disable a SYSTEST_CLIG account again, use the /FLAGS=DISUSER command; for example:

UAF> MODIFY SYSTEST_CLIG/FLAGS=DISUSER 
 
 

6.4.3 Maintaining System-Supplied Accounts (VAX Only)

Immediately after installing a VAX system, make the following changes in the UAF:

  1. Disable the FIELD and SYSTEST accounts. Also disable any infrequently used accounts.
    To disable an account, use the AUTHORIZE command in the following format:
    MODIFY username/FLAGS=DISUSER 
    

    For example:
    $ RUN SYS$SYSTEM:AUTHORIZE
    UAF> MODIFY WOLF/FLAGS=DISUSER
    

    The login flag DISUSER disables the account and prevents anyone from logging in to the account.
    To enable the account when it is needed, run AUTHORIZE and enter the command in the following format:
    MODIFY username /FLAGS=NODISUSER 
    
  2. Optionally, change fields in the DEFAULT account. For example:
    UAF> MODIFY DEFAULT/DEVICE=DISK$USER/WSQUO=750
    

    In this example, the default device is set to the name most commonly used for user accounts that will be added. Likewise, the working set value is set to a value appropriate for most users on the system.

6.4.4 Using the SYSTEM Account

Use the SYSTEM account only for system functions such as performing backups and installing maintenance updates. The SYSTEM account has full privileges enabled by default, so exercise caution when you use it. For example, because you have BYPASS privilege, the system allows you to delete any file, no matter what its protection. If you enter an incorrect name or spurious asterisk, you might destroy files that you or other users need to keep. Consider using an account with fewer privileges for daily system management activities.

If you decide not to use the SYSTEM account for daily system management activities, you can still receive mail from the SYSTEM account. To do this, log in to the SYSTEM account, invoke Mail, and use the SET FORWARD command in the following format to forward the mail to another account:

SET FORWARD node::username 

For example:

$ MAIL
MAIL> SET FORWARD WINSTON::WOLF
MAIL> EXIT 

Caution

Do not use DISUSER for user name SYSTEM if SYSTARTUP_VMS.COM submits batch jobs. Disable all access except Batch in these cases.

Also, be careful not to disable all of your privileged system accounts. If you inadvertently do so, you can recover by setting the system parameter UAFALTERNATE during a conversational boot operation. See Chapter 4 for information on emergency startup procedures.


6.4.5 Using AUTHORIZE to Maintain UAF Accounts

Using the Authorize (AUTHORIZE) utility, you create and maintain UAF accounts by assigning values to various fields within each account record. The values you assign do the following:

How to Perform This Task

  1. Set your default to the directory that contains the SYSUAF.DAT file, typically, SYS$SYSTEM.
  2. Gain access to a specific user record by running AUTHORIZE.
  3. Enter the SHOW command (see example) to display a specific user record.
  4. Enter AUTHORIZE commands such as ADD and MODIFY to create or change the information in the fields of the UAF record.


Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]

[HR]

  6017P014.HTM
  OSSG Documentation
  22-NOV-1996 14:21:36.42

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal