|
 HP OpenVMS Guide to System Security |
 Security for the System Administrator |
| Managing System Access |
|
|
| |
Enabling External Authentication
When successfully authenticated, the external user ID is mappedto the appropriate OpenVMS user name and the correct user profileis obtained.
By default, external authentication is disabled at both thesystem and user levels. However, when you invoke PATHWORKS or AdvancedServer for OpenVMS, external authentication is automatically enabled,if the system administrator has defined logical names in SYSTARTUP_VMS.COMand marked user accounts in the SYSUAF, as described in the followingparagraphs. No additional configuration is necessary on cluster membersrunning the Advanced Server to enable the Advanced Server to participatein the external authentication process.
Before users can log in, the system administrator must enableexternal authentication by performing the following tasks:
These tasks are discussed in the following sections.
Defining External Authentication Logical Names
At thesystem level, external authentication is enabled by defining theSYS$SINGLE_SIGNON systemwide executive-mode logical name.
 | The SYS$SINGLE_SIGNON logical name is automaticallydefined to 1 (enabled) by PWRK$ACME_STARTUP.COM (the PATHWORKS andAdvanced Server for OpenVMS startup procedure) if it has not yetbeen defined in SYSTARTUP_VMS.COM. If you want to disable externalauthentication or set the SYS$SINGLE_SIGNON logical name to another value,define SYS$SINGLE_SIGNON in SYSTARTUP_VMS.COM before PATHWORKSor Advanced Server for OpenVMS is started. You need to define the logical name PWRK$ACME_SERVER if youinstalled only the standalone Advanced Server external authenticationimages, and you have not installed the full Advanced Server. (AdvancedServer installation gives the option of installing external authenticationimages only instead of the complete Advanced Server file and printserver software. See the PATHWORKS (Advanced Server) or AdvancedServer for OpenVMS Installation and Configuration Guide formore information. (See SYS$SINGLE_SIGNON Logical Name Bits formore information on the SYS$SINGLE_SIGNON logical name bits.) |
Marking User Accounts in the SYSUAF$DEFINE/SYSTEM/EXECUTIVE SYS$SINGLE_SIGNON 3
At the user level, external authentication is enabled by aflag, EXTAUTH, in the SYSUAF record. When set, the EXTAUTH flagdenotes that the user is to be externally authenticated. For example,in the Authorize utility, you would enter commands similar to thefollowing:
(See tSSL for OpenVMS he HP OpenVMS System ManagementUtilities Reference Manual: A-L for more informationon the Authorize utility EXTAUTH flag. See the HP OpenVMSSystem Services Reference Manual: GETUTC-Z formore information on the UAI$V_EXTAUTH bit in the SYS$GETUAI and SYS$SETUAIsystem services UAI$_FLAGS item code.)$SET DEFAULT SYS$SYSTEM$RUN AUTHORIZEUAF>ADD username /FLAGS=([NO]EXTAUTH)UAF>MODIFY username /FLAGS=([NO]EXTAUTH)
Overriding External Authentication
Users can enter the /LOCAL_PASSWORD qualifier after theirOpenVMS user name at the login prompt to inform OpenVMS to performlocal authentication instead of external authentication. Users shouldspecify their OpenVMS user name and password when using the /LOCAL_PASSWORDqualifier.
Because the use of the /LOCAL_PASSWORD qualifier is effectivelyoverriding the security policy established by the system manager,it is only allowed under the following conditions:
See the HP OpenVMS Utility Routines Manual formore information on the /LOCAL_PASSWORD qualifier to LOGINOUT.
Impact on Layered Products and Applications
Certain layered products and applications that use an authenticationmechanism based on the traditional SYSUAF-based user name and password(for example, software that calls $HASH_PASSWORD or $GETUAI/$SETUAIto alter, fetch, or verify OpenVMS passwords) will encounter problemsin either of the following cases:
In such cases, the symptom is a user authentication failurefrom the layered product or application.
For externally authenticated users, the normal system authorizationdatabase (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 authenticatedusers and normal OpenVMS users. The following is true for externallyauthenticated users:
OpenVMS attempts to keep a user's SYSUAF and external userpassword synchronized to minimize these problems. An up-to-datecopy of the user's external password is kept in the SYSUAF, butthis is not the case if, for example, the external password containscharacters that are invalid in OpenVMS, or if SYSUAF password synchronizationis disabled by the system manager. (Password synchronization isenabled by default.)
If you enable external authentication, HP recommends you dothe following to minimize incompatibility with layered productsor applications that use traditional SYSUAF-based authentication:
The $GETUAI and $SETUAI system services do not support externalpasswords. These services operate only in passwords stored in theSYSUAF, and updates are not sent to the external authenticationservice. Sites using software that makes calls to these servicesto check passwords or updates should not enable external authentication.HP expects to provide a new programming interface to support externalpasswords in a future release.
Setting a New Password
If you are an externally authenticated user, the DCL commandSET PASSWORD sends the password change request to the external authenticatorand changes your password on your OpenVMS system.
A system manager can set an externally authenticated user'spassword by using a utility provided by the external authenticator.In the case of NT-compatible authentication, PATHWORKS and AdvancedServer for OpenVMS provide the ADMINISTRATOR SET PASSWORD command.Using this method, the new password is propagated to the externalauthenticator immediately.
Case Sensitivity in Passwords and User Names
You can enter a case-sensitive user name at the OpenVMS usernameprompt if you enclose it in quotes. If you do not enclose the username in quotes, LOGINOUT converts the user name to uppercase characters.
You can restore previous behavior on your OpenVMS system bysetting the forced uppercase configuration bit (bit 3) in the SYS$SINGLE_SIGNONlogical name. (See SYS$SINGLE_SIGNON Logical Name Bits formore information.)
OpenVMS and LAN Manager user names are not case-sensitive.Therefore, quotes are not necessary if you enter an OpenVMS username or a LAN Manager user ID.
Valid characters for LAN Manager user IDs and passwords belongto the standard IBM extended (8-bit) ASCII character set. LOGINOUTand SET PASSWORD pass these strings to LAN Manager case preserved, althoughthe external authentication service uppercases both strings accordingto this character set.
LAN Manager passwords can contain characters that are notvalid in OpenVMS passwords. If a LAN Manager password contains acharacter that is invalid in an OpenVMS password, password synchronization isnot performed and a message is issued.
OpenVMS passwords are limited to the 7-bit ASCII charactersA-Z, 0-9, _, and $.
UserName Mapping and Password Verification
To be externally authenticated, a user provides his or herexternal user ID and password at the OpenVMS login prompt. Whenperforming user name mapping, OpenVMS first tries to locate a matchin the SYSUAF and uses that name if it finds a match; otherwise,it queries the external authentication database for a matching userID. When successfully authenticated, the LAN Manager user ID ismapped to the appropriate OpenVMS user name to obtain the correctuser profile, and the login sequence is completed.
External authentication is supported for interactive logins(including DECwindows) and network logins where a proxy is usedor 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 userswho want to use DECnet proxies must have the same user name in theSYSUAF file and LAN Manager database.
When using DECnet proxies, it is important to maintain unique usernames across OpenVMS and LAN Manager domains. If the same user nameappears in the SYSUAF file and LAN Manager database identifyingtwo different users, the use of this user name as a proxy is ambiguous.LOGINOUT treats the name as an OpenVMS user name for login purposes,even though the same name in LAN Manager may map to a differentOpenVMS user name. This occurs because name-mapping rules specifythat OpenVMS attempt to find a match in the SYSUAF before LAN Manager.
Externally authenticated users are considered to have a singlepassword and are not subject to normal OpenVMS password policy (passwordexpiration, 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 asdisabled accounts, modal time restrictions, quotas, and so on.
Externally authenticated users are identified by having theEXTAUTH flag set in their SYSUAF record. OpenVMS users whose accountsdo not have the EXTAUTH flag set are not affected by external authentication.
Password Synchronization
Although passwords are verified using the external authenticatordatabase, OpenVMS attempts to keep the external and SYSUAF passwordfields synchronized.
Password synchronization is enabled by default.
Synchronization takes place at the completion of a successfulexternally authenticated login. If the external password is differentthan the password stored in the SYSUAF file, LOGINOUT updates theSYSUAF password field with the external password. (Synchronizationmay not be possible due to the different sets of valid charactersallowed by OpenVMS and the external authenticator.)
If required, password synchronization can be selectively turnedoff. (See SYS$SINGLE_SIGNON Logical Name Bits for moreinformation on the SYS$SINGLE_SIGNON logical name bits, which controlthe enabling and disabling of password synchronization.)
Specifying the SYS$SINGLE_SIGNON LogicalName Bits
The SYS$SINGLE_SIGNON systemwide executive-mode logical namecontrols overall external authentication operation. The logicalname is translated as a hexadecimal string and treated as a bitvector, with each bit controlling a separate component.
SYS$SINGLE_SIGNON Logical Name Bits contains thedefinitions of the SYS$SINGLE_SIGNON logical name bits, which arenumbered from right to left (with the least significant bit first).
If SYS$SINGLE_SIGNON is undefined or equates to an invalidhexadecimal string, all bits are considered OFF.
The following example definition enables external authentication(bit 0). All other components take their default values.
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 1
HP DECnet-Plus Requirement$DEFINE/SYSTEM/EXECUTIVE SYS$SINGLE_SIGNON 19 !19 HEX
Users with the EXTAUTH bit set in their SYSUAF account recordcannot use explicit access control strings with systems runningDECnet-Plus unless their externally authenticated password is alluppercase characters.
For example, if you enter the following command:
where nodename is a system running DECnet-Plusand username is an EXTAUTH account, DECnet-Plus convertsthe string supplied in the password to uppercasecharacters before it is passed to the external authentication agent(a PATHWORKS or NT domain controller).$DIRECTORY nodename "username password"::
There are two workarounds:
DECnet-Plus and NET_CALLOUTS Parameter
To run DECnet-Plus for OpenVMS with external authenticationenabled, set the system parameter NET_CALLOUTS to 255. This causesuser verification and proxy lookups to be done in LOGINOUT rather thanDECnet.
Failed Connection Attempts on POP Server
The Post Office Protocol (POP) server does not use externalauthentication to authenticate connection attempts on the OpenVMSsystem. This causes connection attempts to fail if either of thefollowing conditions exist:
Authentication and Credentials ManagementExtensions (ACME) Subsystem
This section describes how to enable the SYS$ACM system servicethat provides external authentication capability to applicationsthat need to authenticate a user on an OpenVMS system.
The Authentication and Credentials Management Extensions (ACME)subsystem provides authentication and persona-based credential services.Applications can use these services to interact with the user to performone or more of the following functions:
ACME supports standard OpenVMS authentication and externalauthentication policies; therefore, applications utilize the samemechanisms as used by the system's LOGINOUT and SET PASSWORD components.
ACME SubsystemOverview
The ACME subsystem consists of the following components:
 | VMS - an OpenVMS ACME agentthat provides the standard OpenVMS authentication policy. |
ACME AgentOperational Environment The ACME subsystem supports multiple ACME agents that can interactwith each other to complete an authentication request. These interactionsmust occur in a controlled manner.
When a user authentication dialog is in process, one ACMEagent is the controlling agent and the other agents operate in thebackground as secondary agents.
The controlling agent directs the user name and password promptsand is ultimately responsible for validating the user. The secondaryagents can display messages, request additional passwords, issue credentials,or reject the authentication request, depending on how each agentis configured to interact with other agents.
ACME AgentOrdering The ACME agent that becomes the controlling agent for a particular authenticationrequest is determined in one of two ways:
For this reason, the order in which ACME agents are configuredis important. If the same principal name exists in two or more ACMEagent domains and no ACME agent domain was specified in the SYS$ACMcall, the first agent to map it successfully will control the authenticationrequest. That might not be desirable if the principal name actuallyidentified two different users. By default, the VMS ACME agent isconfigured first.
AuthenticationPolicies
An authentication policy is defined by a particular combinationof user identification, authentication, and authorization attributes.Policy attributes include:
Two authentication policies are supported at present:
OpenVMSPolicy The OpenVMS policy is a rich, case-insensitive, password-basedauthentication policy that includes single-password or dual-passwordaccounts, password expiration, password lock, password expiration,minimum password lengths, system-generated passwords, intrusiondetection 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 groupand 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 informationabout how and when the user can access the system. These modal restrictionslimit 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 isa protected, kernel-based data structure.
AdvancedServer for OpenVMS Policy The Advanced Server for OpenVMS MSV1_0 authentication policyis a distributed authentication policy based on Microsoft LAN Managerdomain protocols. It supports password and challenge-response (NTLM)mechanisms. The policy supports case-sensitive passwords, passwordexpiration, minimum time before password change, and account lock.
A user's credential information consists of the user's systemidentifiers (primary and secondary SIDs) and privileges.
Advanced Server for OpenVMS credentials are stored in an NTpersona extension that is attached to a standard persona containingthe OpenVMS credentials of the OpenVMS user name that has been mappedto the Microsoft user name by the Advanced Server database.
ACME SubsystemControls
Operational control of the ACME subsystem is managed by thefollowing:
SET andSHOW SERVER ACME Commands These commands start, stop, and configure the ACME subsystem.
The ACME_SERVER process starts automatically upon system boot,with the VMS ACME agent configured.
To start or stop the server manually, use these commands:
$ SET SERVER ACME/START$ SET SERVER ACME/EXIT [/ABORT]To configure the VMS ACME agent, use the following command:
$ SET SERVER ACME/CONFIGURE=(NAME=VMS)To configure the MSV1_0 ACME agent, run the SYS$STARTUP:NTA$STARTUP_NT_ACMEcommand procedure or use the following command:
$ SET SERVER ACME/CONFIGURE=(NAME=MSV1_0,CRED=NT, FAC=PWRK)
| To use the MSV1_0 ACME agent, the Advanced Server productmust be installed and running. |
$ SET SERVER ACME/ENABLE[=NAME=agent]Error information is written to the ACME subsystem log file,SYS$MANAGER:ACME$SERVER.LOG.
To view the state of the ACME subsystem, use the followingcommand:
$ SHOW SERVER ACME [/FULL] [/AGENT=agent]Problems can be diagnosed by turning on tracing:
$ SET SERVER ACME/TRACE=nRefer to the HP OpenVMS DCL Dictionary forfurther information on these commands.
New SYSUAFFlags These new flags can be manipulated by SYS$SETUAI, SYS$GETUAI,and the AUTHORIZE utility on VAX and Alpha systems. Only the ACMEsubsystem on Alpha recognizes these flags.
| Flag | Description |
|---|---|
| VMSAUTH | The account can use standard (SYSUAF)authentication when the EXTAUTH flag would otherwise require externalauthentication. An application specifies the VMS domain of interpretationwhen calling SYS$ACM to request standard VMS authentication fora user account that normally uses external authentication. |
| DISPWDSYNCH | Do not synchronize the external password forthis account. See the GUARD PASSWORD control bit in the SECURITY_POLICYsystem parameter for systemwide password synchronization control. |
New SystemParameter SECURITY_POLICY Bit Mask Values The following new security policy bits control systemwideACME subsystem operation on Alpha:
|
|
