Updated: 11 December 1998

OpenVMS System Manager's Manual

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.

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

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 perform the following actions:

• Identify the user
• Define the user's work environment
• Control use of system resources

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.

See Section 6.11 for a list of privileges, limits, and quotas that you can specify in the resource control and privileges fields of the UAF record.

Example

$ RUN SYS$SYSTEM:AUTHORIZE UAF> SHOW WELCH

The following example shows a typical user record for a restricted user account. Callouts describe the fields.

Username: WELCH Owner: ROB WELCH (1) Account: INVOICE UIC: [21,51] ([INV,WELCH]) CLI: DCL Tables: DCLTABLES (2) Default: USER3:[WELCH] LGICMD: Login Flags: Diswelcome Disnewmail (3) Primary days: Mon Tue Wed Thu Fri Secondary days: Sat Sun Primary 000000000011111111112222 Secondary 000000000011111111112222 Day Hours 012345678901234567890123 Day Hours 012345678901234567890123 Network: ------ No access ------- ----- Full access ------ Batch: #########--------####### ---------#########------ Local: #########--------####### ---------#########------ Dialup: ----- Full access ------ ------ No access ------- Remote: ----- Full access ------ ------ No access ------- Expiration: (none) Pwdminimum: 6 Login Fails: 0 Pwdlifetime: 30 Pwdchange: 15-APR-1998 13:58 Last Login: (none) (interactive), (none) (non-interactive) Maxjobs: 0 Fillm: 20 Bytlm: 8192 (4) Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 10 JTquota: 1024 Prclm: 2 DIOlm: 10 WSdef: 150 Prio: 4 ASTlm: 10 WSquo: 256 Queprio: 4 TQElm: 10 WSextent: 512 CPU: (none) Enqlm: 100 Pgflquo: 10240 Authorized Privileges: TMPMBX NETMBX (5) Default Privileges: TMPMBX NETMBX Identifier (6) Value Attributes (7) PROJECT_X %X8001001E RESOURCE NODYNAMIC DOCU_PROC %X80010044 NORESOURCE NODYNAMIC

1. User identification fields contain information used by the system for accounting purposes and user identification.
2. Default fields contain the default specifications for the following elements:
   • Command language interpreter (CLI) is Compaq Command Language (DCL) by default.
   • Name of the command procedure to be executed automatically at login time. If the field is blank, the system uses the default CLI (DCL), and executes SYS$LOGIN:LOGIN.COM by default.
   • Command language interpreter tables (if blank, same as CLI field).
   • Device and directory names for default file access.
3. Login characteristics fields impose specific login restrictions that perform the following actions:
   • Inhibit certain login functions.
   • Control the days of the week when various types of logins are permitted.
   • Control the times of day when various types of logins are permitted.
4. Resource control fields control system resources by:
   • Limiting the use of system resources such as physical memory and CPU time.
   • Specifying the base priority used in scheduling the process that the system creates for the user.
5. Privileges fields specify the privileges that allow use of restricted and sensitive system functions.
6. Identifier fields list the ACL identifiers that the user holds and that are recorded in the rights database file.
7. Attributes fields list the characteristics specified when adding identifiers to the rights database or when granting identifiers to users.

This section describes what to do before adding a user account.

6.5.1 Choosing an Account Type

How you set up a user account depends on the needs of the individual user. Table 6-5 lists the account types and their characteristics.

Table 6-5 Account Types

Account Type	Characteristics
Interactive	This account has access to the system software. Work of a general nature, such as program development or text editing, is performed in this account. Usually, such an account is considered an individual account.
Limited Access	This account provides controlled login to the system and, in some cases, has only a subset of user software available. Limited-access accounts ensure that the system login command procedure (SYLOGIN.COM) and the process login command procedure (specified by the /LGICMD qualifier in the UAF), as well as any command procedures they call, are executed. (See the OpenVMS Guide to System Security for information about writing limited access account command procedures.) The two types of limited accounts are: restricted and captive. Restricted Used for network objects like Mail, for network proxy accounts, or for implementing user authentication systems like smart cards. Captive Limited by function; that is, only those who perform a particular function can use it (for example, an inventory system). Anyone whose job entails inventory control can access your system, but that person cannot access other subsystems or the base software. You might also use a captive account to run batch operations during unsupervised periods or to run applications programs with information you want to keep private.

6.5.2 Performing Additional Tasks

When adding a user account, you must perform the following steps:

1. Select a user name and password.
2. Select a user identification code (UIC).
3. Decide where the account's files will reside (which device and directory).
4. Use the System Management utility (SYSMAN) to add a disk quota entry for this UIC, if disk quotas are in effect. You can do this only after you have created the user's account with the Authorize utility.
5. Create a default directory on the appropriate volume, using the following DCL command format:

   CREATE/DIRECTORY directory-spec/OWNER_UIC=uic

6. Determine the security needs of the account (that is, the level of file protection, privileges, and access control).
7. Establish any login/logout command procedures.

These tasks are described in detail in the sections that follow. When you have completed the tasks for preparing to add a user account, you are ready to add the account by following one of the methods described in Section 6.6.

6.5.2.1 Selecting a User Name and Password

To determine a user name and password, use naming conventions that take into consideration the nature of the account. For example, some installations use the name of the person who will use the account.

Captive accounts, on the other hand, often use a name that describes the function of the account. Thus, an interactive or restricted account for Robert Jones might have a user name of JONES, while a captive account for an inventory system might be called INV103289, which gives some indication of the function of the account but is not easy to guess. Remember to assign unique user names.

For interactive accounts, it is best to let the person using the account control the password. Initially, provide a password that is not easy to guess. The user will be forced to change the password at first login. Only the person using the account should know the password. Encourage all users to set obscure passwords of at least eight characters and to change them frequently, or force the use of generated passwords with the /FLAGS=GENPWD and /GENERATE_PASSWORD qualifiers.

You can use the /PWDMINIMUM and /PWDLIFETIME qualifiers with the AUTHORIZE command ADD or MODIFY to enforce timely password modifications. The following table lists the qualifiers and specific action.

Qualifier	Action
/PWDMINIMUM	Specifies the minimum password length in characters (default is 6).
/PWDLIFETIME	Specifies a delta-time value. One week before that date, the system issues a warning message to the user. On that date, the password expires if it has not been changed.
/GENERATE_PASSWORD	Invokes a password generator to generate user passwords.
/FLAGS=GENPWD	Allows you to force use of the automatic password generator when a user changes a password. Consider using the password generator for privileged accounts or whenever a user has access to sensitive data.

For captive accounts, the degree of sensitivity of the data used by the account should determine the type of password. For example, the password for a payroll application should be obscure, while the password for a suggestions account might not even be required; it could be null (in which case users would not be prompted for the password).

Prohibit users from changing the passwords of captive accounts. To do this, specify /FLAGS=LOCKPWD when you create the captive account. Change the password whenever you feel it might be compromised (for example, if a person using the account moves to another job).

To change a user's password, use the following command format at the UAF> prompt:

MODIFY user-name/PASSWORD=new_password

See the OpenVMS System Management Utilities Reference Manual for more information about AUTHORIZE.

6.5.2.2 Assigning the User Identification Code

Assign each account a unique user identification code (UIC). A UIC has two formats: alphanumeric and numeric.

The alphanumeric UIC consists of a member name and, optionally, a group name separated by a comma and enclosed within brackets (for example, [DOCO,PRICE]). These identifiers might also appear as numeric characters consisting of a group identifier and a member identifier in octal (for example, [11,200]).

Assign accounts the same group number if their owners perform similar work, access the same files frequently, or use many of the same logical names. See the OpenVMS Guide to System Security for a detailed discussion of the user identification code.

Disk quotas limit the amount of disk space available to individual users on a particular volume. If disk quotas are in effect for a disk volume, run the System Management utility (SYSMAN) and use the DISKQUOTA command to add an entry for the new UIC as follows:

1. Invoke SYSMAN.
2. Define the management environment to be node LARRY.
3. Add a disk quota entry on the volume DISK$USER for UIC [014,JONES]. The entry has a permanent quota of 2000 blocks and an overdraft of 500 blocks.
4. Exit from the utility.

Example

$ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET ENVIRONMENT/NODE=LARRY SYSMAN> DISKQUOTA ADD [014,JONES]/DEVICE=DISK$USER/PERMQUOTA=2000/OVERDRAFT=500 SYSMAN> EXIT

The sum of the quota and overdraft values is the absolute maximum number of blocks allotted to the user, which in this example is 2500 blocks. For more information about SYSMAN and establishing disk quotas, see the OpenVMS System Management Utilities Reference Manual.

6.5.2.4 Setting the User Default Device for an Interactive Account

For each interactive account, create a top-level (default) directory (using the DCL command CREATE/DIRECTORY). In the directory place a login file, login file template, and/or logout file, as appropriate. The interactive user creates and maintains files and subdirectories in this directory. Make the owner of the directory the UIC for the new account. Usually, you also use the name of the account for the default directory.

Example

If you decided on an account name of JONES and a UIC of [014,1], you would enter the following DCL command to create a default directory for the account on the volume DISK$USER:

$ CREATE/DIRECTORY DISK$USER:[JONES]/OWNER_UIC=[014,1]

The volume on which the directory is established depends on which devices you reserve for interactive accounts and how much space is available on each.

The default file specification you provide the new account (when you run AUTHORIZE) should be the name of the device and the name of the top-level directory you used in the DCL command CREATE/DIRECTORY.

6.5.2.5 Setting the User Default Device for a Captive Account

For a captive account, whether you create a top-level directory depends on the nature of the user system. If people use files in a particular directory, make that directory the default directory specification. For example, if the inventory system uses the files DISK$DATA:[INV]STOCK1.DAT and DISK$DATA:[INV]STOCK2.DAT, make the default device specification DISK$DATA: and make the default directory specification [INV].

6.5.3 Understanding Account Security

The level of security that you establish for an account depends on the purpose of the account and whether it is shared with other users or groups. For an interactive user account, the default UIC-based protection is usually adequate.

Protecting Users' Files

The default protection for top-level directories is no world access. However, for new user directories, you might want to change the default to world execute access so that users will not have to change directory protection to allow other users read access to files in that directory.

Users can further protect their files and subdirectories on an individual basis with the DCL command SET SECURITY.

Using Access Control Lists (ACLs)

In some cases, such as project accounts, you might want to set up an additional level of protection by using access control lists (ACLs). ACL-based protection provides a more refined level of security in cases where different groups or members of overlapping groups share access to an account such as a project account. ACLs offer a way to grant or deny users access to any security-relevant object.

Section 6.9.2 describes how to set up a project account with ACL-based protection. For more information about how to set up and edit ACLs, see the OpenVMS Guide to System Security and the OpenVMS System Management Utilities Reference Manual.

Using AUTHORIZE to Maintain the Rights Database

The rights database (RIGHTSLIST.DAT) is a file that associates users of the system with access-controlling identifiers. When a user logs in, the system checks the rights database for the identifiers that the user holds. You use the Authorize utility (AUTHORIZE) to maintain the rights database by adding or deleting identifiers as needed.

By allowing a group of users to hold common identifiers, you can create a group protection scheme that is more intricate than that provided by the UIC-based protection.

Using Protected Subsystems

Protected subsystems provide conditional access to data. In a protected subsystem, an application protected by normal access controls serves as a gatekeeper to objects belonging to the subsystem. While users are running the application, their process rights list contains identifiers giving them access to objects owned by the subsystem. As soon as users exit from the application, these identifiers and, therefore, the users' access rights to objects are taken away. For more information, see the OpenVMS Guide to System Security.

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6017PRO_020.HTML