Enabling External Authentication

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.

For SYS$ACM-enabled external authentication (OpenVMS Version 8.3 and later):

The SYSUAF flag /VMSAUTH denotes that the account can use standard (SYSUAF) authentication when the EXTAUTH flag requires external authentication. An application specifies the OpenVMS domain of interpretation when calling SYS$ACM to request standard OpenVMS authentication for a user account that normally uses external authentication.

For non-SYS$ACM-enabled external authentication (OpenVMS Version 8.2–1 and earlier):

As 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 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) encounter problems in either of the following cases:

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:

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:

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 must 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. For example, 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.

However, all user name entries in the SYSUAF file are stored in uppercase characters. A case insensitive search is performed in the SYSUAF file to locate the user record.

Valid characters for external user IDs and passwords belong to the standard IBM extended (8-bit) ASCII character set. LOGINOUT and SET PASSWORD pass these strings case preserved, although the external authentication service uppercases both strings according to this character set.

External passwords can contain characters that are not valid in OpenVMS passwords. If an external 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 external 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 external database.

When using DECnet proxies, it is important to maintain unique user names across OpenVMS and external domains. If the same user name appears in the SYSUAF file and external 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 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 first.

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

For SYS$ACM-enabled external authentication, if required, the password synchronization can be selectively turned off. See the “System Parameter SECURITY_POLICY Bit Mask Values” for more information on the SECURITY_POLICY system parameter, which controls the enabling and disabling of password synchronization.

For non-SYS$ACM-enabled external authentication, if required, password synchronization can be selectively turned off. (See the “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

For non-SYS$ACM-enabled external authentication (OpenVMS Version 8.2–1 and earlier), 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.

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

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:

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:

Authentication and Credentials Management Extensions (ACME) Subsystem

This section describes how the SYS$ACM system service provides external authentication capability to applications that have 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:

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 Controls

Operational control of the ACME subsystem includes the following:

• “Start, Stop, Restart, and Configure ACME_SERVER Process and ACME Agents”

  Methods and commands to start, stop, restart, and configure ACME_SERVER and ACME agents.

• “Other ACME Agent Commands”

  Commands to show ACME_SERVER status, set tracing levels, and the number of ACME_SERVER threads.

• “SYSUAF Flags”

  Select accounts that are eligible for standard and external authentication and password synchronization. The SYSUAF user flags are EXTAUTH, VMSAUTH, and DISPWDSYNCH.

• “System Parameter SECURITY_POLICY Bit Mask Values”

  Controls certain ACME subsystem features on a systemwide basis.

Start, Stop, Restart, and Configure ACME_SERVER Process and ACME Agents

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

Start or Restart ACME_SERVER with all required ACME agents configured by default

OpenVMS Version 8.3 and later uses a site specific startup procedure, SYS$MANAGER:ACME$START.COM. You can edit the SYS$MANAGER:ACME$START.COM to enable the configuration of the various ACME agents that are required and also the order in which the agents are started.

The SYS$MANAGER:ACME$START.COM is run as a result of one of the following conditions:

• SET SERVER ACME/START=AUTO command is issued.

• SET SERVER ACME/RESTART command is issued.

• Unexpected condition causes an automatic server restart.

If you enable agents other than VMS ACME agent, edit the SYSTARTUP_VMS.COM procedure also to include the following command after all the dependent ACME agents:

$ SET SERVER ACME/RESTART

This ensures that all the required ACME agents are started automatically upon system boot.

The executive-mode logical name ACME$START is used to locate this file.

ACME Agent Ordering

The ACME_SERVER can be configured to enable the agent in a specific order. When the user enters the username, at the user name prompt, the ACME agents are called in the order in which it is enabled. The first agent to successfully map the user's principal name to a valid user name within its domain, validates the user.

The ordering of the ACME agents is important if the same principal name exists in two or more ACME agent domains. The first agent to map it successfully controls the authentication request.

By default, however, it is recommended that the VMS ACME agent is configured first. For example, if the Kerberos authentication agent is configured on OpenVMS and the order of startup for OpenVMS and Kerberos ACME agent is such that the Kerberos agent is started first, only those accounts belonging to Kerberos can login.

If the startup order is changed, you can change it back to the default order by performing the following procedure:

Edit the SYS$MANAGER:ACME$START.COM (This file is available on OpenVMS Version 8.3 and later) to search for the section (near the end of the command procedure) where you can specify the desired agent ordering. Change the last line (beginning with AGENT_LIST) so that it appears in the procedure.

$! A specific agent ordering can be specified in AGENT_LIST. $! $! If the list is empty, the agents will be enabled in the order that $! they were configured. Some agent startup procedures may alter $! the agent order. You can override that ordering here. Consult the $! agent documentation you are using to ensure that the ordering you $! specify is supported by that agent. $! $! For example $! $! AGENT_LIST = "VMS,MSV1_0" $! $! will enable the VMS and MSV1_0 agents (and only those agents) in $! that order. $! $ AGENT_LIST = "VMS,ACME_KRB_DOI"

	NOTE: User applications can be developed to directly call SYS$ACM system service and direct it to specific ACME agent overriding the order.

Steps to manually configure the various ACME agents

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

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

On providing a manual SET SERVER ACME/START command, all the ACME agents including the VMS ACME agent have to be configured manually.

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

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

To configure the LDAP ACME agent, run the SYS$STARTUP:LDAPACME$STARTUP-STD.COM command procedure or use the following command:

$ SET SERVER ACME/CONF=(NAME=LDAP-STD,FACILITY=LDAPACME,CRED=LDAP)

	NOTE: To use the LDAP agent, ACMELDAP_STD kit must be installed and configured. For more information, see the Install and configure the ACME login and ACME authentication agents.

To configure the MSV1_0 ACME agent, run the SYS$STARTUP:NTA$STARTUP_NT_ACME.COM 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. For more information, see the Install and configure the ACME services and Authentication agents.

To configure the Kerberos ACME agent, run SYS$STARTUP: KRB$STARTUP_KERBEROS_ACME.COM command procedure or use the following command:

$ SET SERVER ACME/CONFIGURE=(NAME=ACME_KRB_DOI, - _$ FACILITY=KRB,CREDENTIAL=KRB)

	NOTE: To use the Kerberos agent, the Kerberos ACME agent must be installed and configured. For more information, see the Install and configure the ACME services and Authentication agents.

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

Other ACME Agent Commands

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

For more information on the commands, see the HP OpenVMS DCL Dictionary.

To configure the number of worker threads, use the following command:

SET SERVER ACME/CONFIG=THREAD_MAX

This command is ignored on Integrity servers because only one worker thread is active.

	NOTE: Do not increase the number of threads on Integrity servers. Increasing the number of threads on Integrity servers might lead to ACME_SERVER process crash and login failures.

SYSUAF Flags

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

Flag	Description
EXTAUTH	External authentication is enabled for the user, when this flag is set in the SYSUAF record.
VMSAUTH	When this flag is set, the user account can use standard (SYSUAF) authentication, even if the EXTAUTH flag is set for the user, which requires external authentication. An application specifies the OpenVMS domain of interpretation (DOI) when calling SYS$ACM to request standard OpenVMS authentication for a user account that normally uses 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, when this flag is set for the user in the SYSUAF file.
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.

System Parameter SECURITY_POLICY Bit Mask Values

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