HP OpenVMS System Manager's Manual, Volume 1:... |
Managing User Accounts |
|
|
|
| |
Understanding the User Authorization File
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.
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 and I64 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.
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. Resource Type Limits lists the different resource types.
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 Managing System Resources for a full description of limits and quotas.
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.
System Privileges categorizes system privileges and includes a brief definition of the activity permitted with each privilege. See the HP OpenVMS Guide to System Security for a full description of privileges.
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.
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:
SYSUAF.DAT S:RWED, O:RWED, G, W
NETPROXY.DAT S:RWED, O:RWED, G, W NET$PROXY.DAT S, O, G, WThe primary proxy database that the system uses is the NET$PROXY.DAT file. NETPROXY.DAT is maintained:
| For use by DECnet for OpenVMS |
| For backward compatibility |
RIGHTSLIST.DAT S:RWED, O:RWED, G, W
The procedures for adding a user account are discussed in detail in Adding User Accounts. Because the UAF is the prime repository for storing information about user accounts, it is important to understand its components before you add accounts.
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
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. HP recommends that you limit nonbatch
access of the SYSTEM account by using access times and day types.
See
Setting Day Types and
Restricting Logins to Specific Times.
|
|
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 HP OpenVMS DCL Dictionary.) However, the system prohibits activities that violate the user's privilege allowance or exceed resource quotas.
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 HP 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 HP 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.
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 and I64 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 Creating Accounts on Alpha and I64 Systems.
System-Supplied UAF Accounts describes 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: Adding User Accounts gives
an example of how to use AUTHORIZE to add a user account.
Maintaining the User Environment explains how to create
and use additional default templates.
|
||
|
FIELD
|
Permits HP support representatives
to test a new system.
On VAX systems, the default Field Service account has the user name FIELD. On Alpha and I64 systems, you name Field Service accounts for specific HP 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.
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 the HP OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.)
|
||
|
SYSTEST_CLIG
|
Provides an appropriate environment for
running UETP in an OpenVMS Cluster environment. SYSTEST_CLIG accounts
have no passwords associated with them. (See the HP OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.)
|
Creating Accounts on Alpha and I64 Systems ![]()
On Alpha and I64 systems, you can use the SYS$MANAGER:CREATE_SPECIAL_ACCOUNTS.COM command
procedure to create SYSTEST, SYSTEST_CLIG, and multiple Field Service
accounts.
Creating Field Service Accounts (Alpha and I64 )
On Alpha and I64 systems, you can use CREATE_SPECIAL_ACCOUNTS.COM to create accounts for HP 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 HP Field Service account:
Note that the system does not display the password or password verification that you enter.$@CREATE_SPECIAL_ACCOUNTS.COMThis 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: * Re-enter for verification:$
Disabling Field Service Accounts (Alpha and I64) ![]()
You can use the Authorize utility (AUTHORIZE) to disable HP 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:
The login flag DISUSER disables the account and prevents anyone from logging in to the account.$RUN SYS$SYSTEM:AUTHORIZEUAF>MODIFY JOHN_JONES/FLAGS=DISUSER
Reenabling Field Service Accounts (Alpha and I64) ![]()
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
Creating SYSTEST and SYSTEST_CLIG Accounts (Alpha and I64)
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 and I64) 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:
Disabling SYSTEST_CLIG Accounts (Alpha and I64)UAF>MODIFY SYSTEST_CLIG/FLAGS=NODISUSER
To disable a SYSTEST_CLIG account again, use the /FLAGS=DISUSER command; for example:
UAF>MODIFY SYSTEST_CLIG/FLAGS=DISUSER
Maintaining System-Supplied Accounts (VAX
Only) ![]()
Immediately after installing a VAX system, make the following
changes in the UAF:
The login flag DISUSER disables the account and prevents anyone from logging in to the account.$RUN SYS$SYSTEM:AUTHORIZEUAF>MODIFY WOLF/FLAGS=DISUSER
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.UAF>MODIFY DEFAULT/DEVICE=DISK$USER/WSQUO=750
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>SET FORWARD WINSTON::WOLFMAIL>EXIT
| 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 Starting Up and Shutting Down the System for information about emergency startup procedures. |
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 perform the following
actions:
See Managing System Resources for a list of privileges, limits, and quotas that you can specify in the resource control and privileges fields of the UAF record.
$RUN SYS$SYSTEM:AUTHORIZEUAF>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-2000 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
Preparing to Add User Accounts ![]()
This section describes what to do before adding a user account.
Choosing an Account Type ![]()
How you set up a user account depends on the needs of the
individual user.
Account Types lists
the account types and their characteristics.
Performing Additional Tasks ![]()
When adding a user account, you must perform the following
steps:
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 Adding User Accounts.
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 HP OpenVMS System Management Utilities Reference Manual for more information about AUTHORIZE.
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 HP OpenVMS Guide to System Security for a detailed discussion of the user identification code.
| HP reserves UIC group 1 and groups 300-377. |
Adding a Disk Quota Entry 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:
$RUN SYS$SYSTEM:SYSMANSYSMAN>SET ENVIRONMENT/NODE=LARRYSYSMAN>DISKQUOTA ADD [014,JONES]/DEVICE=DISK$USER/PERMQUOTA=2000/OVERDRAFT=500SYSMAN>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 HP OpenVMS System Management Utilities Reference Manual.
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.
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:
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.$CREATE/DIRECTORY DISK$USER:[JONES]/OWNER_UIC=[014,1]
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.
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].
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.
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.
Setting Up a Project Account with ACL Identifiers 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 HP OpenVMS Guide to System Security and the HP 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.
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 HP OpenVMS Guide to System Security.
|
|
|