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 tasks:

Defining logical names in SYSTARTUP_VMS.COM
Marking user accounts in the System User Authorization File (SYSUAF)

These tasks are discussed in the following sections.

Defining External Authentication Logical Names

At the system level, external authentication is enabled by defining the SYS$SINGLE_SIGNON systemwide executive-mode logical name.




	NOTE: The SYS$SINGLE_SIGNON logical name is automatically defined to 1 (enabled) by PWRK$ACME_STARTUP.COM (the PATHWORKS and Advanced Server for OpenVMS startup procedure) if it has not yet been defined in SYSTARTUP_VMS.COM. If you want to disable external authentication or set the SYS$SINGLE_SIGNON logical name to another value, define SYS$SINGLE_SIGNON in SYSTARTUP_VMS.COM before PATHWORKS or Advanced Server for OpenVMS is started. You need to define the logical name PWRK$ACME_SERVER if you installed only the standalone Advanced Server external authentication images, and you have not installed the full Advanced Server. (Advanced Server installation gives the option of installing external authentication images only instead of the complete Advanced Server file and print server software. See the PATHWORKS (Advanced Server) or Advanced Server for OpenVMS Installation and Configuration Guide for more information. (See Table 7-5 “SYS$SINGLE_SIGNON Logical Name Bits” for more information on the SYS$SINGLE_SIGNON logical name bits.)

For example:

$ DEFINE/SYSTEM/EXECUTIVE SYS$SINGLE_SIGNON 3

Marking User Accounts in the SYSUAF

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:

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD username /FLAGS=([NO]EXTAUTH)
UAF> MODIFY username /FLAGS=([NO]EXTAUTH)

(See tSSL for OpenVMS he HP OpenVMS System Management Utilities Reference Manual: A-L for more information on the Authorize utility EXTAUTH flag. See the HP 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.)

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 HP OpenVMS Utility Routines Manual for more information on the /LOCAL_PASSWORD qualifier to LOGINOUT.

Impact on Layered Products and Applications

Certain layered products and applications that use an authentication mechanism based on the traditional SYSUAF-based user name and password (for example, software that calls $HASH_PASSWORD or $GETUAI/$SETUAI to alter, fetch, or verify OpenVMS passwords) will encounter problems in either of the following cases:

When external authentication is used in an environment where a given user's external user ID and OpenVMS user name are different
Where the user's SYSUAF password is different from the external user password

In such cases, the symptom is a user authentication failure from the layered product or application.

For externally authenticated users, the normal system authorization database (SYSUAF.DAT) is used to construct the OpenVMS process profile (UIC, privileges, quotas, and so on) and to apply specific login restrictions. However, there are two key differences between externally authenticated users and normal OpenVMS users. The following is true for externally authenticated users:

The password stored in the SYSUAF is not the password used to verify the user.
The user name stored in the SYSUAF and used to identify the OpenVMS process is not necessarily the same as the external user ID used to authenticate the user during login.

OpenVMS attempts to keep a user's SYSUAF and external user password synchronized to minimize these problems. An up-to-date copy of the user's external password is kept in the SYSUAF, but this is not the case if, for example, the external password contains characters that are invalid in OpenVMS, or if SYSUAF password synchronization is disabled by the system manager. (Password synchronization is enabled by default.)

If you enable external authentication, HP recommends you do the following to minimize incompatibility with layered products or applications that use traditional SYSUAF-based authentication:

Do not disable password synchronization.
Limit external user passwords to those characters from the OpenVMS valid password character set (A--Z, 0--9, underscore (_), and dollar sign ($)).
Assign users the same user name in both the external authentication service and OpenVMS.
Do not assign the same user name or user ID to more than one user.

The $GETUAI and $SETUAI system services do not support external passwords. These services operate only in passwords stored in the SYSUAF, and updates are not sent to the external authentication service. Sites using software that makes calls to these services to check passwords or updates should not enable external authentication. HP expects to provide a new programming interface to support external passwords in a future release.

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.

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 “SYS$SINGLE_SIGNON Logical Name Bits” 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 $.

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

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 “SYS$SINGLE_SIGNON Logical Name Bits” for more information on the SYS$SINGLE_SIGNON logical name bits, which control the enabling and disabling of password synchronization.)

Specifying the SYS$SINGLE_SIGNON Logical Name Bits

The SYS$SINGLE_SIGNON systemwide 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 “SYS$SINGLE_SIGNON Logical Name Bits” 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 HP.
	OFF	Reserved by HP.
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

HP DECnet-Plus Requirement

Users with the EXTAUTH bit set in their SYSUAF account record cannot use explicit access control strings with systems running DECnet-Plus unless their externally authenticated password is all uppercase characters.

For example, if you enter the following command:

$ DIRECTORY nodename “username password”::

where nodename is a system running DECnet-Plus and username is an EXTAUTH account, DECnet-Plus converts the string supplied in the password to uppercase characters before it is passed to the external authentication agent (a PATHWORKS or NT domain controller).

There are two workarounds:

If you are using DECnet-Plus and you want to use explicit access control strings, define an uppercase NT password.
Set up a proxy account on your DECnet-Plus nodes so that you do not have to use explicit access control strings to perform functions.

DECnet-Plus and NET_CALLOUTS Parameter

To run DECnet-Plus for OpenVMS with external authentication enabled, set the system parameter NET_CALLOUTS to 255. This causes user verification and proxy lookups to be done in LOGINOUT rather than DECnet.

Failed Connection Attempts on POP Server

The Post Office Protocol (POP) server does not use external authentication to authenticate connection attempts on the OpenVMS system. This causes connection attempts to fail if either of the following conditions exist:

The external user ID is different from the OpenVMS user name.
The OpenVMS password is not synchronized with the external user password.

Authentication and Credentials Management Extensions (ACME) Subsystem

This section describes how to enable the SYS$ACM system service that provides external authentication capability to applications that need to authenticate a user on an OpenVMS system.

The Authentication and Credentials Management Extensions (ACME) subsystem provides authentication and persona-based credential services. Applications can use these services to interact with the user to perform one or more of the following functions:

User authentication
Password change
Persona creation and modification

ACME supports standard OpenVMS authentication and external authentication policies; therefore, applications utilize the same mechanisms as used by the system's LOGINOUT and SET PASSWORD components.

ACME Subsystem Overview

The ACME subsystem consists of the following components:

SYS$ACM system service
SYS$ACM is a context-driven system service. The service is designed so that applications adapt themselves transparently to various authentication dialogs without requiring changes to the application. Applications call SYS$ACM to perform functions such as authenticate-principal and change-password. Upon successful authentication, the service can return a complete security profile of the user in the form of a persona. For further information about SYS$ACM, refer to the HP OpenVMS System Services Reference Manual and the HP OpenVMS Programming Concepts Manual.
ACME_SERVER process
The ACME_SERVER process is a multithreaded server that supports one or more authentication policies. Each authentication policy is installed by configuring an ACME agent shareable image that "plugs in" to the ACME_SERVER process by way of a standard interface. The server manages the authentication sequence by calling each ACME agent in turn, according to a defined sequence of phases. ACME agents are also responsible for adhering to certain rules regarding how agents can interact during an authentication sequence.
ACME agents
ACME agents each define a single authentication policy that augments or replaces portions of the standard OpenVMS authentication policy. OpenVMS currently supports two ACME agents:
- VMS - an OpenVMS ACME agent that provides the standard OpenVMS authentication policy.
- MSV1_0 - an Advanced Server for OpenVMS ACME agent that provides external authentication using the Microsoft® NT LAN distributed authentication protocol. This agent comes with the installation of the Advanced Server for OpenVMS layered product.
DCL commands SET and SHOW SERVER ACME
You can configure and manage the ACME subsystem by using the SET and SHOW SERVER ACME commands.

ACME Agent Operational Environment

The ACME subsystem supports multiple ACME agents that can interact with each other to complete an authentication request. These interactions must occur in a controlled manner.

When a user authentication dialog is in process, one ACME agent is the controlling agent and the other agents operate in the background as secondary agents.

The controlling agent directs the user name and password prompts and is ultimately responsible for validating the user. The secondary agents can display messages, request additional passwords, issue credentials, or reject the authentication request, depending on how each agent is configured to interact with other agents.

ACME Agent Ordering

The ACME agent that becomes the controlling agent for a particular authentication request is determined in one of two ways:

The call to SYS$ACM targets the call to a particular ACME agent domain. A domain is the set of principal name/user name mappings and corresponding user credentials defined by an ACME agent.
The agent is the first to successfully map the user's principal name to a valid user name within its domain.

For this reason, the order in which ACME agents are configured is important. If the same principal name exists in two or more ACME agent domains and no ACME agent domain was specified in the SYS$ACM call, the first agent to map it successfully will control the authentication request. That might not be desirable if the principal name actually identified two different users. By default, the VMS ACME agent is configured first.

Authentication Policies

An authentication policy is defined by a particular combination of user identification, authentication, and authorization attributes. Policy attributes include:

Identification syntax
Includes simple user name and combination of domain/realm/principal name.
Authentication token mechanism
Token reuse filters
Includes password dictionary, password history, password legal character set, password minimum and maximum lengths, forced change schedule, and expiration.
Intrusion detection
Case sensitivity
Access restrictions
Includes time of day, day of week, and type of access.
User account controls
Includes account lock (disable) and account expiration.
Credential information
Includes user and group identifiers and privileges.

Two authentication policies are supported at present:

Standard OpenVMS policy
External authentication with Advanced Server for OpenVMS distributed authentication policy

OpenVMS Policy

The OpenVMS policy is a rich, case-insensitive, password-based authentication policy that includes single-password or dual-password accounts, password expiration, password lock, password expiration, minimum password lengths, system-generated passwords, intrusion detection and evasion, password dictionary and history filters, modal access restrictions, account expiration, and account lock.

A user's credential information consists of the user's group and member identifier code (UIC), privileges, and rights identifiers. This information is stored in the system authorization (SYSUAF.DAT) and rights identifier (RIGHTSLIST.DAT) databases.

The system authorization database also contains information about how and when the user can access the system. These modal restrictions limit access based on time of day, day of week, and type of access (for example, dialup, remote, or batch).

OpenVMS credentials are stored in a persona. A persona is a protected, kernel-based data structure.

Advanced Server for OpenVMS Policy

The Advanced Server for OpenVMS MSV1_0 authentication policy is a distributed authentication policy based on Microsoft LAN Manager domain protocols. It supports password and challenge-response (NTLM) mechanisms. The policy supports case-sensitive passwords, password expiration, minimum time before password change, and account lock.

A user's credential information consists of the user's system identifiers (primary and secondary SIDs) and privileges.

Advanced Server for OpenVMS credentials are stored in an NT persona extension that is attached to a standard persona containing the OpenVMS credentials of the OpenVMS user name that has been mapped to the Microsoft user name by the Advanced Server database.

ACME Subsystem Controls

Operational control of the ACME subsystem is managed by the following:

DCL commands SET and SHOW SERVER ACME
Start, stop, and configure ACME_SERVER process and agents.
SYSUAF user flags
Select accounts that are eligible for standard and external authentication and password synchronization. The SYSUAF user flags are EXTAUTH, VMSAUTH, and DISPWDSYNCH.
SECURITY_POLICY bits system parameter
Controls certain ACME subsystem features on a systemwide basis.

SET and SHOW SERVER ACME Commands

These commands start, stop, and configure the ACME subsystem.

The ACME_SERVER process starts automatically upon system boot, with the VMS ACME agent configured.

To start or stop the server manually, use these commands:

$ SET SERVER ACME/START
$ SET SERVER ACME/EXIT [/ABORT]

To configure the VMS ACME agent, use the following command:

$ SET SERVER ACME/CONFIGURE=(NAME=VMS)

To configure the MSV1_0 ACME agent, run the SYS$STARTUP:NTA$STARTUP_NT_ACME command procedure or use the following command:

$ SET SERVER ACME/CONFIGURE=(NAME=MSV1_0,CRED=NT, FAC=PWRK)




	NOTE: To use the MSV1_0 ACME agent, the Advanced Server product must be installed and running.

Once the ACME agents are configured, enable them using the following command:

$ SET SERVER ACME/ENABLE[=NAME=agent]

Error information is written to the ACME subsystem log file, SYS$MANAGER:ACME$SERVER.LOG.

To view the state of the ACME subsystem, use the following command:

$ SHOW SERVER ACME [/FULL] [/AGENT=agent]

Problems can be diagnosed by turning on tracing:

$ SET SERVER ACME/TRACE=n

Refer to the HP OpenVMS DCL Dictionary for further information on these commands.

New SYSUAF Flags

These new flags can be manipulated by SYS$SETUAI, SYS$GETUAI, and the AUTHORIZE utility on VAX and Alpha systems. Only the ACME subsystem on Alpha recognizes these flags.

Flag	Description
VMSAUTH	The account can use standard (SYSUAF) authentication when the EXTAUTH flag would otherwise require external authentication. An application specifies the VMS domain of interpretation when calling SYS$ACM to request standard VMS authentication for a user account that normally uses external authentication.
DISPWDSYNCH	Do not synchronize the external password for this account. See the GUARD PASSWORD control bit in the SECURITY_POLICY system parameter for systemwide password synchronization control.

New System Parameter SECURITY_POLICY Bit Mask Values

The following new security policy bits control systemwide ACME subsystem operation on Alpha:

Guard Passwords
Set this bit to disable password synchronization among ACME agents on a systemwide basis. This is functionally equivalent to the SYS$SINGLE_SIGNON logical name bit mask value 4 for LOGINOUT.
The hexadecimal value is 200.
Allow NoAuthorization
Set this bit to allow privileged applications to successfully authenticate a user whose principal name maps to a SYSUAF record that is either expired or whose modal restrictions would otherwise prevent the account from being used. A SYSUAF record that is disabled or password-expired (in the case of traditional VMS authentication) cannot be bypassed in this manner. An application with SECURITY privilege specifies the SYS$ACM ACME$M_NOAUTHORIZE function modifier to override authorization checks.
The hexadecimal value is 400.
Ignore ExtAuth and VMSAuth SYSUAF flags
Set this bit to allow any record in the SYSUAF file to be mapped using external authentication.
The hexadecimal value is 800.