Document revision date: 30 March 2001 | |
Previous | Contents | Index |
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
OpenVMS System Manager's Manual explains the procedure for setting up this type of
account. Section 7.2.1.1 provides an example.
7.2.4 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 Table 7-2 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.
Qualifier | Description |
---|---|
/CLI | Specifies the name of an alternate command language interpreter |
/COMMAND | Overrides the default login command procedure |
/NOCOMMAND | Disables execution of the default login command procedure |
/DISK | Requests an alternate default disk |
/TABLES | Specifies the name of an alternate CLI table |
You define a captive account with AUTHORIZE by including the following qualifier when creating the account:
/FLAGS=(CAPTIVE) |
A captive account also requires the qualifiers described in Table 7-3.
Qualifier | Action |
---|---|
/LGICMD | Identifies the captive account login command procedure and overrides the default login command procedure (LOGIN.COM in the user's default directory). |
/UIC |
Assigns a unique UIC group. Use the following form of the AUTHORIZE
command SHOW to verify the uniqueness of the UIC group:
SHOW [groupuic,*]
By keeping the account in a separate group, you can ensure that the captive account users can access only world-accessible files and files owned by the captive account. It ensures that the account is not a member of the system group (that is, has a group value less than or equal to 10 8, unless modified by the system parameter MAXSYSGROUP). |
/NOPASSWORD or
/FLAGS=LOCKPWD |
Sets up the password. With a captive account, either require no
password, or lock the password so that only the security administrator
can change it.
Locked passwords are generally preferable to open captive accounts (those with no password). If you assign a locked password, give that password to all users of the captive account. |
/PRCLM | Sets the subprocess limit to 0, thus preventing the user from spawning out of the account. (Verify that the system parameter PQL_MPRCLM---the minimum subprocess limit---is set to 0.) |
In addition to the required settings, you may want to specify additional characteristics for the account:
When writing captive command procedures for your site, be sure to observe the following guidelines:
READ/PROMPT="Enter date: " SYS$COMMAND DATE |
Example 7-3 and Example 7-4 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 |
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.
Define a restricted account with the Authorize utility by including the following qualifier when creating the account:
/FLAGS=(RESTRICTED) |
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 Section 7.2.4 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:
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 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.
Compaq 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:
MODIFY guest-account/LGICMD=SYS$MANAGER:filename.COM |
SET ON SET NOCONTROLY ON ERROR THEN LOGOUT/BRIEF |
DELETE/SYMBOL LOGOUT/GLOBAL |
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. Section 12.3.3 describes proxy
login accounts. Note that many recommendations are the same as those
for restricted accounts.
7.2.9 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 Section 7.4 for more information on external
authentication.
7.3 Using Passwords to Control System Access
A site needing average security protection always requires use of passwords. Sites with more security needs frequently impose a generated password scheme (see Section 7.3.2.4) and possibly system passwords as well.
This section describes password management.
7.3.1 Types of Passwords
With the exception of an automatic login account, all users must have at least one password to log in. Sites with moderate or high security requirements may impose additional passwords (see Table 3-2).
Externally authenticated users enter their external password at the OpenVMS password prompt. See Section 7.4 for more information.
This section explains how to assign passwords using DCL and AUTHORIZE
commands.
7.3.1.1 Primary Passwords
When you open an account for a new user with AUTHORIZE, you must give the user a user name and an initial password. When you assign temporary initial passwords, observe all guidelines recommended in Section 3.8. Avoid any obvious pattern when you assign passwords. You may want to use the automatic password generator.
To use the automatic password generator while using AUTHORIZE to open an account, add the /GENERATE_PASSWORD qualifier to either the ADD or the COPY command. The system responds by offering you a list of automatically generated password choices. Select one of these passwords, and continue setting up the account.
There are restrictions on using the /GENERATE_PASSWORD qualifier with the /PWDMINIMUM qualifier. Generated passwords have an absolute length of 12 characters (see Section 7.3.2.3). Whenever there is a conflict between the value of /PWDMINIMUM and a generated password, the operating system uses the lesser of the two values. |
Passwords you specify with AUTHORIZE are defined as expired by default. This forces the user to change the initial password when first logging in. See Section 7.3.2 for more information. Be sure to include information on the first login in your user training so that users know what to expect. If you do not want the password you define with AUTHORIZE to be pre-expired, add the qualifier /NOPWDEXPIRED when entering the password. This is necessary for accounts when users are not permitted to set their own password.
Pre-expired passwords are conspicuous in the UAF record listing. The entry for the date of the last password change carries the following notation:
(pre-expired) |
Section 3.2.1 introduces system passwords, which control access to particular terminals. System passwords are used to control access to terminals that might be targets for unauthorized use, as follows:
Execute the following steps to to implement system passwords:
UAF> MODIFY/SYSTEM_PASSWORD=password |
You need to establish a record in the SYSUAF database only the first time a system password is set up on the system. However, if no record is present,the SET PASSWORD/SYSTEM command returns the following error:
|
To enable the use of the system password for the remote class of logins (those accomplished through the DCL command SET HOST), set the appropriate bit in the default terminal characteristics parameter by using AUTOGEN. This is bit 19 (hexadecimal value 80000) in the parameter TTY_DEFCHAR2. Note that if you set this bit, you must invoke the DCL command SET TERMINAL/NOSYSPWD/PERMANENT to disable system passwords for each terminal where you do not want the feature. (As before, consider placing the SET TERMINAL commands you have tested in SYS$MANAGER:SYSTARTUP_VMS.COM.) Then follow the previously defined steps to set the system password.
When choosing a system password, follow the recommendations presented in Section 3.8. Choose a string of characters and digits, with a minimum length of 6, that is not a valid word. Although the system password is not subject to expiration, change the password frequently. Always change the system password as soon as a person who knows the password leaves the group. Share the system password only with those who need to know.
The system password is stored in a separate UAF record and cannot be displayed. The DCL command SET PASSWORD/SYSTEM (the normal means of setting and changing the system password) requires that you enter the old system password before changing it. Use the AUTHORIZE command MODIFY/SYSTEM_PASSWORD to change the system password without specifying the old password, as shown in the following command:
UAF> MODIFY/SYSTEM_PASSWORD=ABRACADABRA |
The primary function of the system password is to form a first line of defense for publicly accessible ports and to prevent potential intruders from learning the identity of the system. However, requiring system passwords can appear confusing when authorized users are unaware that they are required on certain terminals. To avoid false reports of defective terminals or systems, inform your users which terminals allocated for their use require system passwords.
Where system passwords are not applied to either control access through dialup lines or on publicly accessed lines, few people may know the system password. Operations are hampered if the personnel who know the password are unavailable, incapacitated, or forgetful. Solve this problem by invoking AUTHORIZE and entering the MODIFY/SYSTEM_PASSWORD command. SYSPRV privilege is required.
Previous | Next | Contents | Index |
privacy and legal statement | ||
6346PRO_014.HTML |