HP OpenVMS Guide to System Security: OpenVMS Version 8.4 > Chapter 7 Managing System Access

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 LDAP external authentication agent, Kerberos external authentication agent, PATHWORKS, and Advanced Server for OpenVMS authentication modules (providing NT-compatible authentication) are supported as external authenticators 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.

Before users can log in, the system administrator must enable external authentication by performing the following tasks:

These tasks are discussed in the following sections.

Install and configure the ACME login and ACME authentication agents

In order to authenticate users using external authentication for OpenVMS Version 8.3 and later, the system must have SYS$ACM-enabled external authentication. That is, the LOGINOUT.EXE and SETP0.EXE (SET PASSWORD) images must use the SYS$ACM system service for authentication.

The new LOGINOUT.EXE and SETP0.EXE (SET PASSWORD) images are provided with the ACMELOGIN PCSI kit. This ACMELOGIN PCSI kit has to be extracted from SYS$UPDATE:ACME_DEV_KITS.BCK and installed.

See the SYS$HELP:ACME_DEV_README.TXT for more details on installing the new LOGINOUT.EXE and SETP0.EXE (SET PASSWORD) images.

Also, see the “Authentication and Credentials Management Extensions (ACME) Subsystem” for more details on how external authentication works when SYS$ACM system service is used with DCL commands to operate on the ACME subsystem.

The default LOGINOUT.EXE and SETP0.EXE images provided with the operating system are the non-SYS$ACM versions, as provided with the previous versions of OpenVMS.

After installing the ACMELOGIN kit, install and configure the authentication agent, based on the type of authentication requirement.

To install and configure the authentication agent, follow the below steps.

For a list of generic commands and configuration steps that you can use during the configuration process, see the "ACME Subsystem Controls" section.

  • VMS authentication agent:

    The OpenVMS ACME agent that provides the standard OpenVMS authentication policy. The VMS ACME agent is always required for a complete operational environment, though there are other external authentication agents.

    No separate installation or configuration steps are required for this agent. However, if you start the ACME_SERVER process manually using SET SERVER ACME commands, you must configure the VMS ACME software in order to grant persona-based credentials. Use the following commands to start the ACME_SERVER and configure ACME agents:

    $ SET SERVER ACME/START/LOG

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

    $ SET SERVER ACME/ENABLE

  • LDAP external authentication agent:

    The LDAP external authentication agent authenticates a user and password against directory servers such as Active directory and Enterprise directory.

    For more information on how to install the LDAP external authenticator, see the SYS$HELP:ACMELDAP_STD_CONFIG_INSTALL.PDF or SYS$HELP:ACMELDAP_STD_CONFIG_INSTALL.TXT. PDF version includes images along with the procedure.

  • MSV1_0 external authentication agent:

    The MSV1_0 external authentication agent is the Advanced Server for the OpenVMS ACME agent that provides external authentication using the Microsoft NT LAN distributed authentication protocol. This agent is included in the installation of the Advanced Server for OpenVMS layered product.

    For more information about implementing external authentication, see the

    HP Advanced Server for OpenVMS Server Administrator's Guide.

    For information on installing the external authentication images, see the

    HP Advanced Server for OpenVMS Server Installation and Configuration Guide.

  • Kerberos external authentication agent:

    The Kerberos SIP kit is installed during the installation of OpenVMS. The Kerberos kit can also be downloaded and installed from the following website:

    http://h71000.www7.hp.com/openvms/products/kerberos/index.html.

    For more information on configuring Kerberos, see the section Configuring and Starting the Kerberos ACME Agent in the

    HP Open Source Security for OpenVMS, Volume 3: Kerberos guide.

Define external authentication logical names for non-SYS$ACM- enabled external authentication

For the non-SYS$ACME enabled authentication (OpenVMS Version 8.2–1 and earlier) external authentication is enabled at the system level by defining the SYS$SINGLE_SIGNON systemwide executive-mode logical name.

For more information, see the Differences between SYS$ACM and non-SYS$ACM external authentication section.

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 for cluster members running the Advanced Server to enable the Advanced Server to participate in the external authentication process.

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 have 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 only the external authentication images 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. (Also, see “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

Mark user accounts in the SYSUAF

Each externally authenticated user must have an entry in the SYSUAF file from which account information such as account restrictions and quotas are fetched during login.

The user name in the SYSUAF record can be the same or different from the user name entered at the user name prompt. It depends on user name mapping support provided by the authentication agent, which validates the user.

For example, Kerberos external authentication supports one to one mapping where the user name entered and the user name in the SYSUAF file must be same.

At the user level, external authentication is enabled by a flag, EXTAUTH, in the SYSUAF record for the user. When set, the EXTAUTH flag denotes that the user is to be externally authenticated. For example, in the Authorize utility, you can 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 the HP OpenVMS System Management Utilities Reference Manual: A-L for more information on the Authorize utility EXTAUTH flag. Also, 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.)

Differences between SYS$ACM and non-SYS$ACM external authentication

The LOGINOUT.EXE and SETP0.EXE (SET PASSWORD) images, provided with the ACMELOGIN kit (upon extracting SYS$UPDATE:ACME_DEV_KITS.BCK), utilize the SYS$ACM system service for user authentication and password changes. With these images installed, login and password change requests are sent to the SYS$ACM service and handled by the ACME_SERVER process’s authentication agents. The effect must be transparent to users, layered products and applications.

If your site uses external authentication provided by Advanced Server and you are using the SYS$ACM-enabled LOGINOUT.EXE and SETP0.EXE images, you must be aware of how SYS$ACM-enabled external authentication operates compared with releases prior to Version 8.2–1.

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

    • SYS$SINGLE_SIGNON logical name is used to enable/disable external authentication and debugging using OPCOM messages.

    • Internal hooks in LOGINOUT.EXE and SETP0.EXE enforce authentication and password changes using Advanced Server.

    • Microsoft NT LAN Manager is the only authentication option.

    • /LOCAL requires OPER privilege on the target OpenVMS account.

    • Users are not prompted for a new LAN Manager password when it expires.

    • LAN Manager last login information is not displayed.

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

    • External authentication is controlled by SET SERVER ACME commands.

    • SET SERVER ACME/TRACE writes diagnostic information to SYS$MANAGER:ACME$SERVER.LOG for debugging purposes.

    • LOGINOUT.EXE and SETP0.EXE utilize the SYS$ACM system service for authentication and password changes.

    • Other authentication options besides Microsoft NT LAN Manager are possible.

    • /LOCAL requires the VMSUATH flag on the target OpenVMS account.

    • Users are prompted for a new LAN Manager password when their current LAN Manager password has expired.

    • LAN Manager last login information is displayed during login.

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:

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

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

  • 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, see 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.

    The ACME_SERVER process must be restarted if the installed password policy is changed.

  • ACME agents or authentication agents

    ACME agents each define a single authentication policy that augments or replaces portions of the standard OpenVMS authentication policy. OpenVMS currently supports the following ACME/authentication agents:

    • VMS authentication agent

    • LDAP external authentication agent

    • MSV1_0 external authentication agent

    • Kerberos external authentication agent

    For more information on how to install and configure these authentication agents, see the Install and configure the ACME login and ACME authentication agents section.

  • 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 Subsystem Controls

Operational control of the ACME subsystem includes the following:

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.

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

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

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.

The following authentication policies are supported at present:

  • Standard OpenVMS policy

  • LDAP authentication policy

  • External authentication with Advanced Server for OpenVMS distributed authentication policy

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

LDAP authentication policy

The LDAP authentication policy is based on the Lightweight Directory Access Protocol. It supports validation against the user name and password located on the Directory Server, mapping the user to the OpenVMS user name in the SYSUAF file. For more information on LDAP, see the SYS$HELP:ACMELDAP_STD_CONFIG_INSTALL.PDF or SYS$HELP:ACMELDAP_STD_CONFIG_INSTALL.TXT .

The credentials, such as the user and group identifiers and privileges, use the standard OpenVMS policy.

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.

Kerberos authentication policy

The Kerberos authentication policy is based on the Kerberos protocol. It supports validation against the user name and password located on the Kerberos key distribution center database. The Kerberos principal name must be the same as the OpenVMS user name in SYSUAF.

The credentials, such as the user and group identifiers and privileges, use the standard OpenVMS policy.