Assigning Appropriate Accounts to Users

Types of System Accounts

There are two major types of accounts:

Both interactive and limited-access accounts can be privileged accounts, and can be externally authenticated, as “Privileged Accounts” describes.

The following table shows the kind of account to create based on the task a user performs:

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

Interactive Account Example

“Creating a Typical Interactive User Account” 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.

Example 7-1 Creating a Typical Interactive User Account

$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD RDOWGOOD /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-2003/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>

Notice the following:

1. Only one password is required.

2. The password has a minimum length of 6 characters.

3. The user's password is valid for 90 days, a much longer lifetime than the manager's password shown in “Sample Security Administrator's Account”.

4. The user is allowed access during the week and on Saturdays.

5. During those six days, the user has access during a 15-hour period.

Limited-Account Example

“Creating a Limited-Access Account” 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.

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 /CLITABLES=GRADES_TABLES - [5] UAF> [vellip] user record successfully added identifier for value:[000777,000031] added to RIGHTSLIST.DAT

Notice the following:

1. Account users do not see the normal system welcome message. The account may not receive mail. It is restricted to running under control of its login command procedure and the default command interpreter (DCL).

2. The user who initiates the login must specify the password, GROBWACH. (Most likely only the security administrator will change the password.)

3. When the job is run through a local login, it is restricted to the hours of 8 a.m. through 5:59 p.m., Monday through Friday. (Notice that only batch and local logins are allowed, and batch mode does not have time restrictions.)

4. The job may not be run over dialup lines or as a remote job. The account also denies network access.

5. The process runs under the control of a special login command procedure (GRADES.COM), which presumably provides the operator with a menu of functions.

6. The process is restricted to the commands defined in the CLI table GRADES_TABLES.

Privileged Accounts

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.

Special-Purpose Privileged Captive Accounts

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 “Captive Accounts” for guidelines for setting up captive accounts.

Interactive Accounts

Interactive accounts are very common in environments with low to moderate security requirements. They are well suited to work of a general nature, such as program development or text editing. The HP OpenVMS System Manager's Manual explains the procedure for setting up this type of account. “Interactive Account Example” provides an example.

Captive Accounts

A captive account limits the activities of the user and, when properly administered, denies the user access to the DCL command level. You can set up the account to limit the user to running under the complete control of a specific program or the captive login command procedure.

The primary feature of the captive account is its login command procedure. This type of account ensures that the system login command procedure (SYLOGIN.COM) and the process login command procedure (specified by the /LGICMD qualifier in SYSUAF.DAT), as well as any command procedures they call, are executed. A user cannot specify any of the qualifiers shown in “Login Qualifiers Not Allowed by Captive Accounts” to modify the captive command procedures when logging in.

Once logged in to a captive account, a user cannot escape to the DCL command level through the Ctrl/Y sequence, the SPAWN command, or the INQUIRE command. Because the DISCTLY flag in the UAF record is turned on, any use of Ctrl/Y fails. If unhandled errors or attempted interrupts occur, a system error message is generated, and the session is logged out. Unless the SPAWN command carries the /TRUSTED qualifier, it is ineffective within a captive account. SPAWN is also disabled from MAIL and the DEC Text Processing Utility (DECTPU) (as a built-in procedure). The INQUIRE command is also disabled to prevent the possible execution of user-specified lexical functions.

Guidelines for Captive Command Procedures

When writing captive command procedures for your site, be sure to observe the following guidelines:

• Use the DCL command READ/PROMPT in command procedures. For example, to request the user to enter the date, enter the following command in the command procedure:

  READ/PROMPT="Enter date: " SYS$COMMAND DATE

• Avoid use of the INQUIRE command in a captive command procedure. It produces an error that, if unhandled by a previous ON declaration, results in deletion of the process.

• When user input is required, never execute it directly. First compare it to what is expected, and screen for illegal characters such as apostrophe ('), at sign (@), dollar sign ($), quotation mark ("), ampersand (&), or hyphen (-).

• Avoid any use of the construction "x, where x contains a string entered by the user. Never permit a restricted command procedure to attempt an evaluation of a symbol that the user enters. Use of lexical functions could break the command procedure.

• Avoid executing a line in a captive command procedure that contains the characters @TT:.

• Put Audit ACEs on the captive command procedure and its home directory to detect any modification of the file. See “Attaching a Security-Auditing ACE” for more information on Audit ACEs.

• If the captive account user is allowed to create or perform other operations on files, make certain that write access to the login command procedure and its directory is denied. (The user does need execute access.)

  If the function of the command procedure requires text preparation, you may need to give users access to a text editor. Use caution, however. Editors such as TECO or DECTPU can be dangerous because users can manipulate files and exit from the editor to the DCL interface. When designing this environment, remember that most text editors are capable of reading and writing files (within the access rights of the account). Provide an editor that gives users the tools they require but does not allow them to escape from the captive environment.

“Sample Captive Procedure for Privileged Accounts” and “Sample Captive Command Procedure for Unprivileged Accounts” provide sample command procedures for privileged and unprivileged accounts.

Example 7-3 Sample Captive Procedure for Privileged Accounts

$ if f$mode() .nes. "INTERACTIVE" then $logout $ term = f$logical("SYS$COMMAND") $ if f$locate("_T", term) .eq. 0 then $goto allow $ if f$locate("_OP",term) .ne. 0 then $logout $allow: $ set control=(y,t)

Example 7-4 Sample Captive Command Procedure for Unprivileged Accounts

$ deassign sys$input $ previous_sysinput == f$logical("SYS$INPUT") $ on error then goto next_command $ on control_y then goto next_command $ set control=(y,t) $ $next_command: $ on error then goto next_command $ on control_y then goto next_command $ $ if previous_sysinput .nes. f$logical("SYS$INPUT") then deassign sys$input $ read/end=next_command/prompt="$ " sys$command command $ command == f$edit(command,"UPCASE,TRIM,COMPRESS") $ if f$length(command) .eq. 0 then goto next_command $ $ delete = "delete"$ delete/symbol/local/all $ if f$locate("@",command) .ne. f$length(command) then goto illegal_command $ if f$locate("=",command) .ne. f$length(command) then goto illegal_command $ if f$locate("F$",command) .ne. f$length(command) then goto illegal_command $ verb = f$element(0," ",command) $ $ if verb .eqs. "LOGOUT" then goto do_logout $ if verb .eqs. "HELP" then goto do_help $ $ write sys$output "%CAPTIVE-W-IVVERB, unrecognized command \",verb,"\" $ goto next_command $ $illegal_command: $ write sys$output "%CAPTIVE-W-ILLEGAL, bad characters in command line" $ goto next_command $ $do_logout: $ logout $ goto next_command $ $do_help: $ define sys$input sys$command $ help $ goto next_command

Restricted Accounts

Certain limited-access accounts require a less restrictive environment than captive accounts. Accounts under which network objects run, for example, require temporary access to DCL. Such accounts must be set up as restricted accounts, not captive accounts. Restricted accounts are indistinguishable from regular accounts once the login sequence finishes. The purpose behind restricted accounts is to ensure a trusted login wherein SYLOGIN, LOGIN, and their descendants execute completely.

If the restricted flag is set, it is recommended that the LOGIN.COM is not user-writable or the user cannot modify it and bypass the login procedure. It is also expected that the LOGIN.COM has error checking and error handling in place using the various error controls such as the $ SET NOON or $ ON ERROR THEN LOGOUT.

	NOTE: The purpose of the RESTRICTED flag is to ensure that the user cannot bypass parts of the login procedures. It is not intended to invoke a mechanism by which login procedures containing bugs cause a logout.

Define a restricted account with the Authorize utility by including the following qualifier when creating the account:

This flag ensures that the account is noted as restricted. A restricted account provides the same features as those listed for a captive account in “Captive Accounts” except that restricted accounts allow the user access to the DCL command level following the execution of the system and process login command procedures.

Sometimes it is appropriate to allow the user to enter the Ctrl/Y key sequence after the command procedure starts. For example:

Automatic Login Accounts

To force individuals at specific terminals to log in to an application program, create a separate captive account for the application. Then set up automatic logins to the new account for the desired users using the System Management utility (SYSMAN).

Once you set up a terminal for automatic login, it can be used only for the designated account. This is most useful for applications terminals used by people who may be unfamiliar with computers.

The automatic login feature suppresses the user name prompt. All other login features (system password, primary and secondary passwords, and messages) function normally, if enabled.

Passwords are optional. If you want the account to be open to all users where the terminals are located, eliminate the password. When no password is required, the user has no data to enter at login. The operating system logs the terminal in automatically in response to the Break key or the Return key and immediately enters the application if the account is under the control of a captive login command procedure.

The automatic login file (ALF) lists the terminals and the users who are authorized to access the application account. However, automatic login accounts are potentially accessible from terminals and sources other than the terminals listed in the ALF file and, therefore, require protection, especially if they have no password. Use the following precautions:

Guest Accounts

Guest accounts are forms of captive or restricted accounts that allow multiple remote users access to resources on your system through a common account. For example, users across the network may need access to your system to report problems or to read corporate memos.

HP does not recommend the practice of setting up guest accounts. Guest accounts, however unprivileged, offer malicious users a chance to compromise your system security. Most needs for a guest account can be handled by special proxy login accounts, which should also be limited-access accounts.

If you still need a guest account, take the following steps to make the account secure:

Proxy Accounts

Generally, proxy login accounts should be set up as restricted accounts. Proxy login accounts permit remote users to access a local account without specifying a password. “Example of a Proxy Account” describes proxy login accounts. Note that many recommendations are the same as those for restricted accounts.

Externally Authenticated Accounts

Externally authenticated accounts are those that are marked with the EXTAUTH flag in the user's SYSUAF record. This enables these users to log in at the OpenVMS login prompt using their external user IDs and passwords. See “Enabling External Authentication” for more information on external authentication.