OpenVMS Guide to System Security

Updated: 11 December 1998

OpenVMS Guide to System Security

Contents

Index

7.4.1 Overriding External Authentication

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:

When the account being logged into has SYSPRV as an authorized privilege.
When bit 1 is set in the SYS$SINGLE_SIGNON logical name, nonprivileged users (who are normally externally authenticated) can request local authentication.

See the OpenVMS Utility Routines Manual for more information on the /LOCAL_PASSWORD qualifier to LOGINOUT.

7.4.2 Setting a New Password

If you are an externally authenticated user, the DCL command SET PASSWORD sends the password change request to the external authenticator and changes your password on your OpenVMS system.

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.

7.4.3 Case Sensitivity in Passwords and User Names

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

7.4.4 User Name Mapping and Password Verification

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

7.4.5 Password Synchronization

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

7.4.6 Specifying the SYS$SINGLE_SIGNON Logical Name Bits

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

Table 7-5 SYS$SINGLE_SIGNON Logical Name Bits
Bit Status Description

0 ON Enable external authentication. Users who are tagged in the SYSUAF file as externally authenticated use the external authenticator to log in.

OFF Disable external authentication. If local authentication is enabled (that is, bit 1 is ON), then the system attempts local authentication with the user's normal SYSUAF user name and password. If local authentication is disabled, login is not allowed for externally authenticated users.

1 ON Enable local authentication. If bit 0 is off, the system automatically logs the user in using local authentication. (The system effectively ignores the EXTAUTH flag in the user's SYSUAF record.) If bit 0 is on but the external authentication server is not running, the user can request local authentication using the /LOCAL_PASSWORD qualifier.

OFF Disable local authentication. A user can force local authentication using the /LOCAL_PASSWORD qualifier. You must have SYSPRV privilege to use this qualifier when bit 1 is OFF.

2 ON Reserved by Compaq.

OFF Reserved by Compaq.

3 ON Enable forced uppercase terminal input during login; this is equivalent to the RMS ROP$V_CVT option for the login device. Setting this bit restores previous OpenVMS behavior but does not allow case-sensitive input of user name and password.

OFF Disable forced uppercase terminal input during login.

4 ON Disable local password synchronization. The system does not perform password synchronization from the external authenticator to the SYSUAF.

OFF Enable local password synchronization. During a successful login, the system attempts to synchronize the SYSUAF password with the external password (if they are different) by calculating the OpenVMS hash value of the external password used for logins and storing the hash value in the SYSUAF file.

31 ON Enable OPCOM debug messages, which are displayed when users log in or use the SET PASSWORD command. These messages can help diagnose potential problems with the configuration of external authentication.

OFF Disable OPCOM debug messages.

**Table 7-5 SYS$SINGLE_SIGNON Logical Name Bits**
Bit	Status	Description
0	ON	Enable external authentication. Users who are tagged in the SYSUAF file as externally authenticated use the external authenticator to log in.
	OFF	Disable external authentication. If local authentication is enabled (that is, bit 1 is ON), then the system attempts local authentication with the user's normal SYSUAF user name and password. If local authentication is disabled, login is not allowed for externally authenticated users.
1	ON	Enable local authentication. If bit 0 is off, the system automatically logs the user in using local authentication. (The system effectively ignores the EXTAUTH flag in the user's SYSUAF record.) If bit 0 is on but the external authentication server is not running, the user can request local authentication using the /LOCAL_PASSWORD qualifier.
	OFF	Disable local authentication. A user can force local authentication using the /LOCAL_PASSWORD qualifier. You must have SYSPRV privilege to use this qualifier when bit 1 is OFF.
2	ON	Reserved by Compaq.
	OFF	Reserved by Compaq.
3	ON	Enable forced uppercase terminal input during login; this is equivalent to the RMS ROP$V_CVT option for the login device. Setting this bit restores previous OpenVMS behavior but does not allow case-sensitive input of user name and password.
	OFF	Disable forced uppercase terminal input during login.
4	ON	Disable local password synchronization. The system does not perform password synchronization from the external authenticator to the SYSUAF.
	OFF	Enable local password synchronization. During a successful login, the system attempts to synchronize the SYSUAF password with the external password (if they are different) by calculating the OpenVMS hash value of the external password used for logins and storing the hash value in the SYSUAF file.
31	ON	Enable OPCOM debug messages, which are displayed when users log in or use the SET PASSWORD command. These messages can help diagnose potential problems with the configuration of external authentication.
	OFF	Disable OPCOM debug messages.

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.

$ DEFINE/SYSTEM/EXECUTIVE SYS$SINGLE_SIGNON 1

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

$ DEFINE/SYSTEM/EXECUTIVE SYS$SINGLE_SIGNON 19 !19 HEX

7.5 Controlling the Login Process

This section describes many operating system features designed to secure systems from unauthorized users.

7.5.1 Informational Display During Login

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.

7.5.1.1 Announcement Message

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.

7.5.1.2 Welcome Message

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:

$ DEFINE/SYSTEM SYS$WELCOME "@SYS$MANAGER:WELCOME.TXT"

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.

$ DEFINE/SYSTEM SYS$WELCOME " "

If you prefer to selectively disable the message for individual users, you can use the AUTHORIZE qualifier /FLAGS=DISWELCOME on individual UAF records.

7.5.1.3 Last Login Messages

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 three messages. Enter the AUTHORIZE qualifier /FLAGS=DISREPORT for specific users.

7.5.1.4 New Mail Announcements

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:

/FLAGS=(DISMAIL,DISNEWMAIL)

7.5.2 Limiting Disconnected Processes

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:

To prevent particular terminals from being used as virtual terminals, use the DCL command SET TERMINAL/PERMANENT/NODISCONNECT.
To prevent specific users from attaching to disconnected processes, set the AUTHORIZE qualifier /FLAGS=DISRECONNECT for those users. (An applications account used by multiple users is a good candidate for the DISRECONNECT flag to prevent the users from connecting to each other's processes.)
To disable virtual terminals on a systemwide basis, remove the DISCONNECT attribute from the system parameter TTY_DEFCHAR2.

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.

7.5.3 Providing Automatic Login

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:

Task Command Example

Adding terminal/user name association ALF ADD ALF ADD TTA5 RENOLDS

Adding terminal server/user name association ALF ADD/PORT "M34C3/LC-1-2" RENOLDS

Displaying records in ALF file ALF SHOW ALF SHOW TTA5
ALF SHOW /USERNAME=PONTRE

Removing terminal/user name association ALF REMOVE ALF REMOVE TTA3
ALF REMOVE /USERNAME=DOUGLAS

Task	Command	Example
Adding terminal/user name association	ALF ADD	ALF ADD TTA5 RENOLDS
Adding terminal server/user name association	ALF ADD/PORT	"M34C3/LC-1-2" RENOLDS
Displaying records in ALF file	ALF SHOW	ALF SHOW TTA5 ALF SHOW /USERNAME=PONTRE
Removing terminal/user name association	ALF REMOVE	ALF REMOVE TTA3 ALF REMOVE /USERNAME=DOUGLAS

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.

The ALF file is an indexed file that does not need to be purged, but it should be backed up after a modification.

7.5.4 Using the Secure Server

Section 3.8 describes password grabbers as a class of programs designed to steal passwords from unsuspecting users who log in to terminals left on. The operating system provides a secure terminal server that stops any currently executing process before the start of a login at that terminal.

Invoke the secure server separately for each terminal with the following DCL command:

SET TERMINAL/PERMANENT/SECURE/DISCONNECT term-id

The user must then press the Break key followed by the Return key to start a login. The login proceeds as usual.

If you apply the secure server to all terminals, you can make the login procedure consistent throughout the site by putting the SET TERMINAL commands in the site-specific startup command procedure. However, certain applications that may use the terminal as a communications line need to use the Break key for their own purposes, which would be incompatible with the secure terminal server.

The secure terminal server feature is also incompatible with autobaud handling. However, because autobaud handling is necessary only on modem terminals (switched and dialup terminals), the modem handling on such terminals performs the equivalent of secure server functions. For secure operation, set up the terminal characteristics as follows:

For local terminals (direct-wired), use the following SET TERMINAL qualifiers:
/NOMODEM/SECURE/DISCONNECT/NOAUTOBAUD/PERMANENT
For switched terminals (data-switch and dialup), use the following SET TERMINAL qualifiers:
/MODEM/AUTOBAUD/NOSECURE/DISCONNECT/PERMANENT

Specify the /DIALUP qualifier if the terminal port is accessible through a telephone line or the equivalent, regardless of the path (direct modem, data switch, terminal server, or public data network).

Always specify the /DISCONNECT qualifier to guard against password grabbers. To prevent disconnected jobs from filling up your system, set the system parameter TTY_TIMEOUT to a low timeout value, which determines when disconnected processes are deleted.

If you decide to apply the secure server to individual terminals, include directly wired terminals located in public areas or remote, unsecured areas. Terminals never used for local or dialup logins are not subject to this security problem. Terminals closely supervised during logins may also not require this measure.

7.5.5 Detecting Intruders

Occasionally people fail to log in correctly because they enter an expired password or make a typing error. But not all failures are benign: some occur because an unauthorized person is trying to log in through an expired account or with an unknown user name or is attempting to guess passwords on a valid account.

The operating system is sensitive to login failures. After one failure, it begins to monitor the terminal, terminal server connection, or network connection where the login is taking place. At first, the operating system records unsuccessful logins in an intrusion database. As failures continue, the operating system not only records failures but takes restrictive measures. The person attempting login is monitored more closely and limited to a certain number of login retries within a limited period of time. Once a person exceeds either the retry or time limitation, he or she cannot log in for a while, even with a valid user name and password. At a later point, the restriction eases, and login is allowed once again.

7.5.6 Understanding the Intrusion Database

The DCL command SHOW INTRUSION displays the contents of the intrusion database; Example 7-5 shows a sample display. The database captures the following types of information on login failures:

Field Description

Intrusion class Identifies the general source of failure:

Network: failure originating from a remote node, using a valid user name.
Terminal: failure originating from one terminal.
Term_User: failure originating from one terminal, using a valid user name.
Username: failure attempting to create a detached process.

Type Severity of login failure:

Suspect
Intruder

The system parameters for threshold count (LGI_BRK_LIM) and monitoring period (LGI_BRK_TMO) define when a suspect becomes an intruder.

Count Number of login failures associated with a particular source.

Expiration Date and time when a suspect's record is deleted or when an intruder is allowed another chance to log in. When an intruder's record reaches its expiration time, it becomes a suspect, and the failure count is reset to LGI_BRK_LIM. The expiration time is reset to the old expiration plus LGI_BRK_TMO.

Source Origin of the login failure:

Node and user name if Network class
Terminal if Terminal class
Terminal and user name if Term_User class
User name if Username class

Field	Description
Intrusion class	Identifies the general source of failure: Network: failure originating from a remote node, using a valid user name. Terminal: failure originating from one terminal. Term_User: failure originating from one terminal, using a valid user name. Username: failure attempting to create a detached process.
Type	Severity of login failure: Suspect Intruder The system parameters for threshold count (LGI_BRK_LIM) and monitoring period (LGI_BRK_TMO) define when a suspect becomes an intruder.
Count	Number of login failures associated with a particular source.
Expiration	Date and time when a suspect's record is deleted or when an intruder is allowed another chance to log in. When an intruder's record reaches its expiration time, it becomes a suspect, and the failure count is reset to LGI_BRK_LIM. The expiration time is reset to the old expiration plus LGI_BRK_TMO.
Source	Origin of the login failure: Node and user name if Network class Terminal if Terminal class Terminal and user name if Term_User class User name if Username class

Whenever the system detects an intruder, it sends an auditing message to the security operator terminal or the log file to alert you. Using the DCL command SHOW INTRUSION, you can display the source and type of intrusion. For example, Example 7-5 shows a problem with a user named MAPLE who is logging in over the network. The user has tried to log in 8 times. Because the user failed to log in within the monitoring period, the operating system suspended all logins from OMNI:.BOSTON.BIRCH::MAPLE. Table 7-6 gives a more detailed explanation of how the system decides to suspend logins.

Notice that many suspects appear in the display. Sometimes users forget their passwords or type them incorrectly. To remove an entry from the database, use the DCL command DELETE/INTRUSION_RECORD.

Example 7-5 Intrusion Database Display

$ SHOW INTRUSION

Intrusion Type Count Expiration Source NETWORK SUSPECT 1 2-Jan-1995 13:20:30.89 PCD025:: Intrusion Type Count Expiration Source NETWORK SUSPECT 5 2-Jan-1995 13:36:39.42 DENIM::SYSTEM NETWORK SUSPECT 2 2-Jan-1995 13:25:17.30 N1KDO::SYSTEM Intrusion Type Count Expiration Source NETWORK SUSPECT 2 2-Jan-1995 13:07:57.95 OMNI:.LOWELL.ASH::TESTER NETWORK INTRUDER 8 2-Jan-1995 11:06:50.51 OMNI:.BOSTON.BIRCH::MAPLE Intrusion Type Count Expiration Source NETWORK SUSPECT 2 2-Jan-1995 13:20:10.09 JETTE::TIPH NETWORK SUSPECT 1 2-Jan-1995 13:21:40.75 FTSR::TFREDERICK

Contents

Index

Legal

 
6346PRO_016.HTML