HP OpenVMS Systems Documentation
OpenVMS Guide to System Security
6.7 Ongoing Tasks to Maintain a Secure System
|Time of day||/ACCESS||By default, a user has full access every day. By specifying an access time, you prevent access at all other times. Identify hours on primary days with the keyword PRIMARY; identify hours on secondary days with the keyword SECONDARY.|
|/DIALUP||Specifies hours of access permitted for dialup logins.|
|/LOCAL||Specifies hours of access for interactive logins from local terminals.|
|Days of week||/PRIMEDAYS||Defines the primary and secondary days of the week for logging in.|
|Mode of operation||/BATCH||Specifies the hours of access permitted for batch jobs.|
|/INTERACTIVE||Specifies the hours of access for interactive logins.|
|/NETWORK||Specifies the hours of access permitted for network batch jobs.|
|/REMOTE||Specifies hours during which access is permitted for interactive logins from network remote terminals (with the DCL command SET HOST).|
|Allocation of resources||/DEVICE||Specifies the name of the user's default device at login.|
|/DIRECTORY||Specifies the name of the user's default directory at login.|
|Validity of account||/EXPIRATION||Specifies the expiration date and time of the account.|
|/FLAGS=DISUSER||Disables the account so the user cannot log in.|
|External authentication||/FLAGS=EXTAUTH||Specifies that the user is externally authenticated.|
AUTHORIZE qualifiers let you restrict system use to certain days of the week and certain periods of the day. Restricting work times is useful to better balance the workload on your system. Restricting access to accounts is also an effective way of preventing unauthorized use of the system outside of normal working hours.
Define primary and secondary days of the week with the /PRIMEDAYS qualifier, or conform to the default where primary days are Monday through Friday and secondary days are Saturday and Sunday. For example, to modify the defaults for a user who works Tuesday through Saturday, you would specify the /PRIMEDAYS qualifier as follows:
Occasionally an operational change occurs that conflicts with the normal day assignments at your site, such as a holiday falling on a primary day. To override the normal day assignment, use the DCL command SET DAY, and specify the day-type interpretation you want for the current day. This requires OPER privilege. Note that this change applies to all logged-in users, as well as those who will log in during the day. If users who are currently logged in are unauthorized for the day-type once it changes, they are logged out of the system at the next hour. (The job controller enforces time restrictions on an hourly basis.)
Decide which types of login access should be restricted to certain hours. The login access qualifiers are: /LOCAL, /REMOTE, /DIALUP, /INTERACTIVE, /BATCH, and /NETWORK. However, if your site applies one set of primary and secondary hours for all types of logins, you can specify the /ACCESS qualifier, which applies to all modes of access.
The following example shows how to apply the /BATCH qualifier to a user's account to disable the user from running batch jobs during normal working hours:
This specification permits the user to run batch jobs only during the
hours of 6:00 p.m. through 8:59 a.m. on primary days but all day on
7.1.2 Restricting Modes of Operation
Use the AUTHORIZE qualifier /NONETWORK to prevent specific users from having network access, as shown in the following example:
UAF> ADD JSMITH /NONETWORK, ...
Any of the AUTHORIZE access mode qualifiers (/LOCAL, /REMOTE, /DIALUP,
/INTERACTIVE, /BATCH, or /NETWORK) can be negated in this manner to
restrict access to the system.
7.1.3 Restricting Account Duration
It is good practice to set an account expiration time that matches the maximum length of time you expect the user to require access. When the expiration time arrives, the system automatically prohibits access to the account. You must still remove the UAF record and delete the user's files.
Use of the /EXPIRATION qualifier also forces you to periodically review accounts and reauthorize only those that are necessary.
To set the account expiration time, use the AUTHORIZE qualifier /EXPIRATION in the user's UAF record. For example, the following qualifier specifies that the user's account will expire on the 30th of December 1995:
You may want to severely restrict the use of certain accounts. For
example, you may want to disable specific accounts used only
periodically, such as the SYSTEST and FIELD accounts, to limit possible
misuse of these accounts. Disable the accounts with the /FLAGS=DISUSER
qualifier. Temporarily enable the accounts with the /FLAGS=NODISUSER
qualifier when needed.
7.1.5 Restricting Disk Volumes
Identify the user's default device and directory in the UAF record with the AUTHORIZE qualifiers /DEVICE and /DIRECTORY. You can limit the number of blocks available to the user on that disk (and any other disk) through the disk quota feature of the System Management utility (SYSMAN), as described in the OpenVMS System Management Utilities Reference Manual: A--L.
The volume protection in place on other disks controls how much access
a user can obtain to the disks. The user's privileges, which can be
extended or limited through the AUTHORIZE qualifier /PRIVILEGES, also
influence the access available (see Section 8.7).
7.1.6 Marking Accounts for External Authentication
Mark a user's account in the UAF record with the AUTHORIZE qualifier /FLAGS=EXTAUTH to allow the user to be externally authenticated.
The type of system access a user holds largely depends on his or her
need for system resources and your site's security requirements. This
section describes the types of user accounts that are available on
OpenVMS systems and explains why one type of account may be preferable
to another. For a step-by-step description of adding user accounts,
refer to the OpenVMS System Manager's Manual.
7.2.1 Types of System Accounts
Both interactive and limited-access accounts can be privileged accounts, and can be externally authenticated, as Section 7.2.2 describes.
|If Users Need to...||Type of Account to Create|
|Perform work of a general nature, such as program development or text editing||Interactive|
|Perform routine computer tasks requiring limited activities||Captive|
|Run batch operations during unsupervised periods||Captive|
|Run applications programs with confidential information||Captive|
|Use network applications like MAIL||Restricted|
|Access resources on your system from a remote system (in a limited manner)||Captive or restricted|
|Use network proxy accounts||Restricted|
|Use authentication systems like smart cards||Restricted|
|Use accounts created as part of a layered product installation||Restricted|
|Perform privileged operations||Interactive, restricted, or captive|
|Access resources from a remote system without a password||Captive|
|Automatically log in to an application terminal||Captive or restricted|
|Log in at the OpenVMS login prompt using their external user IDs and passwords||Externally authenticated|
You may develop one or more templates that work for many of your users. However, do not oversimplify the process of account creation to the point that you simply apply a template. The danger in relying solely on templates is that you might overlook special considerations that apply to individual users, thereby forfeiting important controls that only you can exercise.
Examine templates regularly to be sure they are valid and reflect the
way you want your operations to proceed. Templates become obsolete
188.8.131.52 Interactive Account Example
Example 7-1 shows how to create an interactive user account with moderate restrictions, typical of an account at a commercial site where security is a concern and the average user has limited access. Notice the following:
|Example 7-1 Creating a Typical Interactive User Account|
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD RDOGWOOD /PASSWORD=TRALAYAM/UIC=[231,010] - (1) _UAF> /DEVICE=BOTANYDEV/DIRECTORY=[RDOGWOOD] - _UAF> /OWNER="Robert Dogwood"/ACCOUNT=BOTNYDPT - _UAF> /FLAGS=(GENPWD)/PWDMINIMUM=6 - (2) _UAF> /EXPIRATION=15-JUNE-1994/PWDLIFETIME=90- (3) _UAF> /PRIMEDAYS=(MON,TUES,WED,THURS,FRI,SAT,NOSUN) - (4) _UAF> /NOACCESS=(PRIMARY,23-6,SECONDARY)/NODIALUP (5) identifier for value:[000231,000010] added to RIGHTSLIST.DAT UAF>
Example 7-2 shows how to create an applications production account where the user is highly restricted. This account is designed to perform two functions: list the grades at State University, and produce mailings to each student's home.
In the example, any value not specified defaults to the value provided by the default record in SYSUAF.DAT.
Notice the following:
|Example 7-2 Creating a Limited-Access Account|
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD REPGRADES /DEVICE=ADMINDEV/DIRECTORY=[REPGRADES] - _UAF> /FLAGS=(CAPTIVE,DISWELCOME,DISNEWMAIL,DISMAIL,DEFCLI) - (1) _UAF> /PASSWORD=GROBWACH/UIC=[777,031] - (2) _UAF> /OWNER="Campus Admin"/ACCOUNT=ADMIN - _UAF> /LOCAL=(PRIMARY,8-17)/PRIMEDAYS=(MON,TUES,WED,THU, - (3) _UAF> FRI,NOSAT,NOSUN) - _UAF> /NONETWORK/NOREMOTE/NODIALUP - (4) _UAF> /LGICMD=GRADES (5) /CLITABLES=GRADES_TABLES - (6) . . . user record successfully added identifier for value:[000777,000031] added to RIGHTSLIST.DAT
Privileges determine the functions users are authorized to perform on the system. Any account with privileges beyond TMPMBX and NETMBX is considered privileged. Such an account can be interactive, restricted, or captive.
Because abuse of privileged accounts can result in serious losses, consider imposing special controls on accounts with the most powerful privileges as follows:
For all but the SYSTEM account, also add the following restrictions:
Naturally, you need to set controls on the SYSTEM account. The most secure practice is to disable it for all but batch access and perform system management through individual privileged user accounts, which provide accountability.
Because the safety of a captive account depends on the integrity of its command procedures, it is unadvisable to set up privileged captive accounts for untrusted users. However, there are some situations that require privilege, and it is safer to perform specific sensitive functions through captive privileged accounts than through general purpose privileged accounts. For example, users who perform backup operations require the READALL privilege. By making the account that performs backups captive, you can ensure that the procedures are carried out according to your system's backup policy.
See Section 7.2.4 for guidelines for setting up captive accounts.