skip book previous and next navigation links
go up to top of book: HP OpenVMS System Manager's Manual, Volume 1:... HP OpenVMS System Manager's Manual, Volume 1:...
go to beginning of chapter: Managing User Accounts Managing User Accounts
 
go to next page: Adding User AccountsAdding User Accounts
end of book navigation links

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.

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.

Table 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 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.

Table 2   System Privileges
Category Privilege Activity Permitted
None
None
Non requiring privileges
Normal
NETMBX
Create network connections

TPMBX
Create temporary mailboxes
Group
Group
Control processes in the same group

GRPPRV
Group access through system protection field
Devour
ACNT
Disable accounting

ALLSPOOL
Allocate spooled devices

BUGCHK
Make machine check error log entries

EXQUOTA
Exceed disk quotas

GRPNAM
Insert group logical names in the name table

PRMCEB
Create/delete permanent common event flag clusters

PRMGBL
Create/delete permanent global sections

PRMMBX
Create permanent mailboxes

SHMEM
Create/delete structures in shared memory
System
ALTPRI
Set base priority higher than allotment

AUDIT
Generate audit records

OPER
Perform operator functions

PSWAPM
Change process swap mode

SECURITY
Control any process

SYSLCK
Perform security-related functions

WORLD
Lock systemwide resources
Objects
DIAGNOSE
Diagnose devices

IMPORT
Mount a nonlabeled tape volume

MOUNT
Execure mount volume QIO

SYSGBL
Create systemwide global sections

VOLPRO
Override volume protection

READALL
Bypass existing restrictions to read an object
All
BYPASS
Disregard protection

CMEXEC
Change to executive mode

CMKRNL
Change to kernel mode

DETACH
Create detached processes of arbitrary UIC

DOWNGRADE
Write to a lower secrecy object or lower an object's classification

LOG_IO
Issue logical I/O requests

PFNMAP
Map to specific physical pages

PHY_IO
Issue physical I/O requests

READALL
Process read access to all system objects

SETPRV
Enable any privilege

SHARE
Access devices allocated to other users

SYSNAM
Insert system logical names in the name table

SYSPRV
Acces objects through system protection field

UPGRADE
Writer 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.

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 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.

Table 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. 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.

Table 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]
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.
CautionDo 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 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:

$ @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:
* Re-enter for verification:
$
Note that the system does not display the password or password verification that you enter.

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:

$ 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 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:

UAF> MODIFY SYSTEST_CLIG/FLAGS=NODISUSER
Disabling SYSTEST_CLIG Accounts (Alpha and I64)

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:

  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=DISUSERFor 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.

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 

CautionDo 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:

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 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.

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-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
  1. User identification fields contain information used by the system for accounting purposes and user identification.
  2. Default field contain the default specifications for the following elements:
  3. Login characteristics fields impose specific login restrictions that perform the following actions:
  4. Resource control fields control system resources by:
  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.

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.

Table 5   Account Types
Account Description
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 HP 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.

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 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.


NoteHP 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:

  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 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.

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.

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.

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.

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.

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 HP OpenVMS Guide to System Security.


 
go to next page: Adding User AccountsAdding User Accounts