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:
For OpenVMS Version 8.3 and later:
For OpenVMS Version 8.2–1 and earlier:
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.
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:
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.
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:
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.
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.
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)
|
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) |
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)
|
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. |
|
| |
|
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.
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.
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:
LDAP authentication policy
External authentication
with Advanced Server for OpenVMS distributed authentication policy
Kerberos authentication 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.
