HP OpenVMS Systems Documentation
OpenVMS Guide to System Security
7.3.4 Password Protection Checklist
In addition to all the recommendations included in Section 3.8, observe the following guidelines to protect passwords:
The following actions reduce the potential of password detection or limit the extent of the damage if passwords are discovered or bypassed:
7.4 Enabling External Authentication
External authentication allows users to log in (or sign on) at the OpenVMS login prompt using their external user IDs and passwords. The PATHWORKS and Advanced Server for OpenVMS authentication modules are supported as external authenticators, providing NT-compatible authentication of OpenVMS users.
When successfully authenticated, the external user ID is mapped to the appropriate OpenVMS user name and the correct user profile is obtained.
By default, external authentication is disabled at both the system and user levels. However, when you invoke PATHWORKS or Advanced Server for OpenVMS, external authentication is automatically enabled, if the system administrator has defined logical names in SYSTARTUP_VMS.COM and marked user accounts in the SYSUAF, as described in the following paragraphs. No additional configuration is necessary on cluster members running the Advanced Server to enable the Advanced Server to participate in the external authentication process.
Before users can log in, the system administrator must enable external authentication by performing the following:
These tasks are discussed in the following sections.
At the user level, external authentication is enabled by a flag, EXTAUTH, in the SYSUAF record. When set, the EXTAUTH flag denotes that the user is to be externally authenticated. For example, in the Authorize utility, you would enter commands similar to the following:
(See the OpenVMS System Management Utilities Reference Manual: A--L for more information on the Authorize utility
EXTAUTH flag. See the OpenVMS System Services Reference Manual: GETUTC--Z for more information on the
UAI$V_EXTAUTH bit in the SYS$GETUAI and SYS$SETUAI system services
UAI$_FLAGS item code.)
Users can enter the /LOCAL_PASSWORD qualifier after their OpenVMS user name at the login prompt to inform OpenVMS to perform local authentication instead of external authentication. Users should specify their OpenVMS user name and password when using the /LOCAL_PASSWORD qualifier.
Because the use of the /LOCAL_PASSWORD qualifier is effectively overriding the security policy established by the system manager, it is only allowed under the following conditions:
See the OpenVMS Utility Routines Manual for more information on the /LOCAL_PASSWORD
qualifier to LOGINOUT.
A system manager can set an externally authenticated user's password by
using a utility provided by the external authenticator. In the case of
NT-compatible authentication, PATHWORKS and Advanced Server for OpenVMS
provide the ADMINISTRATOR SET PASSWORD command. Using this method, the
new password is propagated to the external authenticator immediately.
You can enter a case-sensitive user name at the OpenVMS username prompt if you enclose it in quotes. If you do not enclose the user name in quotes, LOGINOUT converts the user name to uppercase characters.
You can restore previous behavior on your OpenVMS system by setting the forced uppercase configuration bit (bit 3) in the SYS$SINGLE_SIGNON logical name. (See Table 7-5 for more information.)
OpenVMS and LAN Manager user names are not case-sensitive. Therefore, quotes are not necessary if you enter an OpenVMS user name or a LAN Manager user ID.
Valid characters for LAN Manager user IDs and passwords belong to the standard IBM extended (8-bit) ASCII character set. LOGINOUT and SET PASSWORD pass these strings to LAN Manager case preserved, although the external authentication service uppercases both strings according to this character set.
LAN Manager passwords can contain characters that are not valid in OpenVMS passwords. If a LAN Manager password contains a character that is invalid in an OpenVMS password, password synchronization is not performed and a message is issued.
OpenVMS passwords are limited to the 7-bit ASCII characters A-Z, 0-9,
_, and $.
To be externally authenticated, a user provides his or her external user ID and password at the OpenVMS login prompt. When performing user name mapping, OpenVMS first tries to locate a match in the SYSUAF and uses that name if it finds a match; otherwise, it queries the external authentication database for a matching user ID. When successfully authenticated, the LAN Manager user ID is mapped to the appropriate OpenVMS user name to obtain the correct user profile, and the login sequence is completed.
External authentication is supported for interactive logins (including DECwindows) and network logins where a proxy is used or a user ID/password is supplied.
If you have external authentication enabled on your system, target user names specified in DECnet proxies or Auto-Login (ALF) databases must exist in the SYSUAF. Externally-authenticated users who want to use DECnet proxies must have the same user name in the SYSUAF file and LAN Manager database.
When using DECnet proxies, it is important to maintain unique user names across OpenVMS and LAN Manager domains. If the same user name appears in the SYSUAF file and LAN Manager database identifying two different users, the use of this user name as a proxy is ambiguous. LOGINOUT treats the name as an OpenVMS user name for login purposes, even though the same name in LAN Manager may map to a different OpenVMS user name. This occurs because name-mapping rules specify that OpenVMS attempt to find a match in the SYSUAF before LAN Manager.
Externally authenticated users are considered to have a single password and are not subject to normal OpenVMS password policy (password expiration, password history, minimum and maximum password length restrictions), but are instead subject to any defined external authenticator policy. All other OpenVMS account restrictions remain in effect, such as disabled accounts, modal time restrictions, quotas, and so on.
Externally authenticated users are identified by having the EXTAUTH
flag set in their SYSUAF record. OpenVMS users whose accounts do not
have the EXTAUTH flag set are not affected by external authentication.
Although passwords are verified using the external authenticator database, OpenVMS attempts to keep the external and SYSUAF password fields synchronized.
Password synchronization is enabled by default.
Synchronization takes place at the completion of a successful externally authenticated login. If the external password is different than the password stored in the SYSUAF file, LOGINOUT updates the SYSUAF password field with the external password. (Synchronization may not be possible due to the different sets of valid characters allowed by OpenVMS and the external authenticator.)
If required, password synchronization can be selectively turned off.
(See Table 7-5 for more information on the SYS$SINGLE_SIGNON
logical name bits, which control the enabling and disabling of password
The SYS$SINGLE_SIGNON system-wide executive-mode logical name controls overall external authentication operation. The logical name is translated as a hexadecimal string and treated as a bit vector, with each bit controlling a separate component.
Table 7-5 contains the definitions of the SYS$SINGLE_SIGNON logical name bits, which are numbered from right to left (with the least significant bit first).
If SYS$SINGLE_SIGNON is undefined or equates to an invalid hexadecimal string, all bits are considered OFF.
The following example definition enables external authentication (bit 0). All other components take their default values.
The following example definition enables external authentication (bit 0), forces uppercase terminal input at the username prompt (bit 3), and disables password synchronization (bit 4).
7.5 Controlling the Login Process
This section describes many operating system features designed to
secure systems from unauthorized users.
This section describes how you can control the display of various
pieces of information that appear by default at login time, such as
announcement, welcome, last login, and new mail messages. So that you
can understand the effect of login restrictions, it also describes how
the operating system processes the login fields of the system user
authorization file (SYSUAF.DAT). In addition, this section describes
the use of the secure server and how to set up intrusion detection.
To provide an announcement message on your system, define the system logical name SYS$ANNOUNCE in the site-specific startup command procedure SYS$MANAGER:SYSTARTUP_VMS.COM. The OpenVMS System Manager's Manual describes how to do this. The announcement message appears at login.
The definition you provide here affects all users on the system.
Because this message may provide a clue to the identity of the
operating system, you may decide not to display it.
Similar to the announcement message, the welcome message is controlled through a system logical name, SYS$WELCOME. If you do not define SYS$WELCOME, a standard welcome message is provided for all users. This welcome message reveals the operating system and version number, as well as the node if SYS$NODE is defined.
To define another message for SYS$WELCOME, you can create a text file containing the message. To display the contents of this file, use the following line in SYSTARTUP_VMS.COM:
To disable the welcome message, place the following DCL command in SYS$MANAGER:SYSTARTUP_VMS.COM. This command prints a blank line in place of the standard welcome message.
If you prefer to selectively disable the message for individual users,
you can use the AUTHORIZE qualifier /FLAGS=DISWELCOME on individual UAF
By default, the system displays three messages that provide information
about the last logins and the number of failed login attempts (see
Section 3.4.3). You can selectively disable the appearance of these
Enter the AUTHORIZE qualifier /FLAGS=DISREPORT for specific users.
By default, the system tells users the number of new mail messages when they log in. You can prevent users from receiving this notice by specifying the AUTHORIZE qualifier /FLAGS=DISNEWMAIL.
The new mail announcement is primarily a user convenience, not a security issue. If a user with a restricted account cannot invoke the Mail utility (MAIL), then you might want to disable the new mail message at the same time you prohibit mail access. The following AUTHORIZE qualifier accomplishes both tasks:
Virtual terminals let users maintain more than one disconnected process at a time. Virtual terminals are also required by the secure server feature (see Section 7.5.4). You may want to restrict the use of virtual terminals. For example, if you are concerned about the amount of nonpaged pool, you may not want to enable this feature on a systemwide basis.
Virtual terminals can be disabled at the terminal, user, or system level:
You can also set the amount of time allowed for reconnection to less than the default of 15 minutes with the system parameter TTY_TIMEOUT. A process that remains disconnected for longer than the timeout value is automatically logged out by the system. Limiting the connection time tends to minimize the number of users who receive messages, but it also affects the usefulness of the connection feature.
For more information on setting up and reconnecting to virtual
terminals, refer to the OpenVMS System Manager's Manual.
You can assign accounts to particular terminals to enable an automatic login feature (see Section 7.2.6). This feature permits users to log in without specifying a user name. The operating system associates the user name with the terminal (or terminal server port) and maintains these assignments in the file SYS$SYSTEM:SYSALF.DAT, referred to as the automatic login file or the ALF file. Maintain this file with the following System Management utility (SYSMAN) commands:
The ALF file consists of one record for each terminal on which automatic logins are enabled. Each record consists of two fields: the device name or terminal server port name of the terminal, followed by the user name of an account. The device names must be unique within the file. However, the same user name can occur in any number of records; that is, one account can be automatically logged in to an unlimited number of terminals.