HP OpenVMS Systems

HP Advanced Server for OpenVMS
Server Administrator's Guide

By default, the Advanced Server can support up to 10 simultaneous external authentication logon requests (signons). You can modify this maximum to suit the server requirements, using the Configuration Manager. For more details, see Section 7.2.4.4, Specifying the Maximum Number of Concurrent Signons.

3.1.17.4 Synchronizing Passwords

The password of an externally authenticated OpenVMS user is automatically synchronized with the host mapped Advanced Server domain user, regardless of the role of the Advanced Server in the domain.

When a user changes the OpenVMS password using the OpenVMS command SET PASSWORD, and external authentication is set for the user, OpenVMS forwards the password change request to the Advanced Server. When the password change request is successfully processed, OpenVMS updates the OpenVMS user password. If Advanced Server is not running when the OpenVMS command SET PASSWORD is executed, the domain password is not changed.

When users change their passwords from their client workstations, or the server administrator changes a password with the ADMINISTER command SET PASSWORD, the Advanced Server processes the password change as usual. The OpenVMS password is synchronized when the user next logs in to OpenVMS. All password changes are synchronized. When an OpenVMS user no longer has the external authentication flag set, the password for the OpenVMS user account is the same as the one that was last set by Advanced Server.

When users change their password on the OpenVMS system or on their client computer, they should use the new password to log in to OpenVMS. If, for some reason, the Advanced Server software is down at the time of the OpenVMS login, users can use their old OpenVMS password to log in, but only if you have enabled overriding of external authentication. In this case, privileged users can enter the /LOCAL_PASSWORD qualifier after their OpenVMS user name at the login prompt, as explained in Section 3.1.17.6, Bypassing External Authentication When the Network Is Down. This causes OpenVMS to perform local authentication.

If you want to disable external authentication, then before starting the Advanced Server, define the SYS$SINGLE_SIGNON logical in SYSTARTUP_VMS.COM to a value of 0, as in the following example:

$ DEFINE/SYSTEM/EXECUTIVE SYS$SINGLE_SIGNON 0

For more information, refer to the HP OpenVMS Guide to System Security.

3.1.17.6 Bypassing External Authentication When the Network Is Down

External authentication cannot occur if a network connection is required and the network is down. However, as a temporary solution, privileged users can enter the /LOCAL_PASSWORD qualifier after the OpenVMS user name at the login prompt, to specify local authentication. Be sure to specify the OpenVMS user name and password when using the /LOCAL_PASSWORD qualifier.

Because using the /LOCAL_PASSWORD qualifier effectively overrides the security policy established by the system manager, it is allowed only when the user's account has SYSPRV as an authorized privilege. This allows the system manager to gain access to the system when the network is down.

When Bit 1 is set in the SYS$SINGLE_SIGNON logical name, nonprivileged users who are normally externally authenticated can log in locally (the /LOCAL_PASSWORD qualifier need not be specified).

For more information about the /LOCAL_PASSWORD qualifier for the login command line, refer to the HP OpenVMS Guide to System Security.

3.1.17.7 Logging On to Externally Authenticated Accounts

OpenVMS accepts the user name in one of the following formats for user accounts set for external authentication:

• ASusername (network user name)
• Domainname\ASusername
• ASusername@Domainname

The form of the user name string determines the order in which OpenVMS verifies the logon:

• If ASusername is used, this name is first interpreted as an OpenVMS user name. If the user name exists (in the OpenVMS System User Authorization File (SYSUAF)), and that user is not set for external authentication, the authentication is done as a standard OpenVMS login. Advanced Server authentication does not take place.
  If the user name does not exist in SYSUAF, the Advanced Server checks the domain accounts database (SAM) for the name and looks for an explicit host mapping to find the ASusername user's OpenVMS account. The server then verifies that the OpenVMS account is set for external authentication.
• If the domain name is included in the user name, OpenVMS activates external authentication of the user, using the name of the domain supplied:
  • If the domain name is the same as that of the local server, the local server will proceed to authenticate this request.
  • If the domain name is different from that of the local server, the software first checks whether the user name is mapped to the domain name explicitly. If so, the authentication request is forwarded to the specified domain for authentication. (For more information about host mapping, see Section 3.1.16.1, Implicit and Explicit Host Mapping.)
    If the user name is not mapped to the domain name explicitly, the local server software checks the server configuration parameter HostMapDomains in the OpenVMS Registry to verify whether the specified domain is in the list of those trusted domains that the server allows to externally authenticate Advanced Server users. If the domain is listed there, the authentication request is forwarded to the specified domain for authentication. If the domain is not listed there, the logon request is denied.

Because external authentication depends on host mapping information, it is important to set up user accounts and host mapping carefully. For example, if the same user name exists in the Advanced Server and OpenVMS, but they are not the same user, external authentication may not work as you expect.

In the following examples, you have Advanced Server running on OpenVMS node VMS1 in the domain SaleOffice, with network users Smith and J_Smith and OpenVMS users Smith and V_Smith:

• You enable external authentication for both of the OpenVMS users and then specify the user host mapping as follows:

  $ ADMINISTER ADD HOSTMAP SMITH V_SMITH $ ADMINISTER ADD HOSTMAP J_SMITH SMITH

  
  When OpenVMS user Smith uses his network user name J_Smith and password to log on to VMS1, this logon will be successful, providing the password is correct.
  However, when OpenVMS user V_Smith uses her network user name Smith and password to log on to VMS1, this logon will fail because of the name space conflict between Advanced Server and OpenVMS.
  To log on, OpenVMS user V_Smith must specify her network user name, specifying the domain name (either Smith@SaleOffice or SaleOffice\Smith).
• You enable external authentication only for OpenVMS user V_Smith, specifying the following command:

  $ ADMINISTER ADD HOSTMAP SMITH V_SMITH

  
  When OpenVMS user V_Smith uses her network user name Smith to log on to VMS1, the logon will fail, because Smith will first be interpreted as an OpenVMS user name. Because the OpenVMS user name exists, and it is not enabled for external authentication, the OpenVMS authentication mechanism is used to verify the password.
  To log on, the OpenVMS user V_Smith must specify the domain name with her network user name (either Smith@SaleOffice or SaleOffice\Smith).

You can set up an OpenVMS account to be externally authenticated by a trusted domain in your network. To enable this feature, you must include the trusted domain name in the data field for the server configuration parameter HostMapDomains in the OpenVMS Registry. See Section 7.3, Managing Server Configuration Parameters Stored in the OpenVMS Registry.

For example, if your OpenVMS system is in the SaleOffice domain, and this domain trusts the Marketing domain, set up OpenVMS user Jones to be externally authenticated by the Marketing domain as follows:

1. Set the data field for the server configuration parameter HostMapDomains to include the trusted domain name, as follows:

   $ REGUTL :== $SYS$SYSTEM:PWRK$REGUTL $ REGUTL SET PARAM/CREATE VMSSERVER HOSTMAPDOMAINS Marketing

2. Ensure that a network user account with user name Jones exists in the Marketing Domain.
3. Enable external authentication for OpenVMS user account Jones.
4. To log on, the user must specify the user name in one of the following forms:

   Jones@Marketing Marketing\Jones

The local server's domain is the default domain for users when external authentication is established. If you want to change the default domain for users using external authentication, define the Advanced Server logical PWRK$ACME_DEFAULT_DOMAIN on the system as follows:

$ DEFINE/SYS/EXE PWRK$ACME_DEFAULT_DOMAIN domain_name

where domain_name is the name of the new default domain. After defining this logical, if a user does not specify a domain name at login, the system will use the specified default domain for external authentication.

3.1.17.11 Requirement for External Authentication Over DECnet-Plus

To allow users to be externally authenticated over DECnet-Plus for OpenVMS, set the system parameter NET_CALLOUTS to 255. This enables Advanced Server user ID mapping and authentication for network logins.

3.1.17.12 SYS$SINGLE_SIGNON logical explained

The sys$single_signon logical is used to configure the behavior of external authentication. It consists out of a number of bits that are represented by a decimal number. By adding these numbers we retrieve a decimal number the logical refers to.

Bit 0 switch external authentication on/off
Bit 1 enable the /local switch for all users regardless of the syspriv privilege
Bit 2 not used
Bit 3 enable forced uppercase
Bit 4 disable password sync

As an example, the 4 most commonly used settings are described:

$ DEFINE/SYS/EXE SYS$SINGLE_SIGNON "0"

External authentication is disabled, users with the EXTAUTH flag set can not logon to OpenVMS using the /local switch without having the syspriv privilege set.

$ DEFINE/SYS/EXE SYS$SINGLE_SIGNON "1"

This means external authentication is enabled, users with the EXTAUTH flag set can not logon to OpenVMS using the /local switch without having the syspriv privilege set.

$ DEFINE/SYS/EXE SYS$SINGLE_SIGNON "2"

This means external authentication is disabled, but users with the EXTAUTH flag set can logon to OpenVMS providing the /local switch (regardless of the syspriv privilege is set).

$ DEFINE/SYS/EXE SYS$SINGLE_SIGNON "3"

This means external authentication is switched on and users with the EXTAUTH flag set can also logon to OpenVMS providing the /local switch (regardless of the syspriv privilege is set).

3.1.17.13 Applications Using External Authentication

Applications that use system functions like $LOGINOUT or $SET_PASSWORD use External Authentication. Most applications that use OpenVMS cannot directly verify the user name and password details in the SYSUAF. However, these applications use normal calls to the LOGINOUT.EXE file to perform this task. However, some applications such as SYSMAN and MAIL, bypass this method. Earlier FTP from UCX was bypassing this method, but this problem is resolved in TCP/IP V5.1 release.

3.1.17.14 Data Structures Used in External Authentication

During each user logon attempt, the user name and password details are requested by the LOGINOUT.EXE file. This data is passed on to the Advanced Server which checks in SYS$SYSTEM:SYSUAF.DAT if the user has external authentication enabled. If the user has external authentication enabled , then Advanced Server validates the user name and password details with the SAM database. The SAM consists of the following files having no filename extensions:

PWRK$LMDOMAINS:<DOMAIN NAME>
PWRK$LMDATAFILES:ACL., BUILTIN. AND LSA.

The <domain name> file contains the list of users and their logon details. The LSA file contains mapping information between the OpenVMS usernames and the Windows usernames. When the validation procedure is completed, the matching record of the SYSUAF is checked for process settings, identifiers, and the login directory.

3.2 Managing Advanced Server Groups

Groups are collections of user accounts and other groups. When you add a user to a group, the user has all the rights and permissions granted to the group. This provides an easy way to grant common capabilities to sets of users. (For additional information about planning Advanced Server groups, refer to the HP Advanced Server for OpenVMS Concepts and Planning Guide.)

You use groups to manage access to resources like directories, files, and printers. To do this, assign permissions to the resource, specifying the group names, and add the user accounts to the groups. To change the permissions for a group, add or remove the permissions on the resource for the group, rather than for each user. Or, if you need to give a user access to specific resources (for example, certain directories and files), add the user's account to the appropriate group rather than changing permissions on each individual resource. Maintaining permissions for a group is simpler than maintaining permissions for individual user accounts.

Every group is either a global group or a local group.

• Global groups can be used both in their own domain and in trusting domains. You can use global groups to grant rights and permissions to global users. By default, new groups are global groups. Global groups can be members of a local group.
• Local groups can be granted permissions and rights only for the servers in their domain. However, they can contain user accounts and global groups both from their domain and from trusted domains. Local groups let you create sets of users from both inside and outside the domain, to access resources in the domain where the local group is created. The use of local groups in permissions lists for files and shares can also help reduce disk space consumption, as noted in Section 4.1.3.6, Streamlining Security Information Storage and Lookups.

Table 3-3 summarizes how to organize local and global groups.

The Advanced Server creates several built-in groups automatically during installation. Each built-in group has a unique set of access rights. To give one such set of access rights to a user account, add the user to the appropriate group. By default, all users belong to the built-in group Domain Users.

Table 3-4 lists the built-in groups, with their group type (global or local), and their default members.

To set up a new user group, use the ADD GROUP command. To create a local group, include the /LOCAL qualifier on the command line. For example, to add the local group MUNCHKINS, enter the following command. Note that the description of the group is enclosed in quotation marks. If you do not specify the group type, the default is to add the group as a global group.

LANDOFOZ\\TINMAN> ADD GROUP MUNCHKINS/DESCRIPTION="Oz local group"/LOCAL
%PWRK-S-GROUPADD, group "MUNCHKINS" added to domain "LANDOFOZ"

LANDOFOZ\\TINMAN> SHOW GROUPS
Groups in domain "LANDOFOZ":
Group Name              Type          Description
---------------------   -----------   -------------------------------------
Account Operators       Local         Members can administer domain user and
                                      group accounts
Administrators          Local         Members can fully administer the domain
Backup Operators        Local         Members can bypass file security to back
                                      up files
DEVAS                   Global
DEVIS                   Global
Domain Admins           Global        Designated administrators of the domain
Domain Guests           Global        All domain guests
Domain Users            Global        All domain users
Guests                  Local         Users granted guest access to the domain
MONKEYS                 Global        Users in the Land of Oz
MUNCHKINS               Local         Oz local group
Print Operators         Local         Members can administer domain printers
Replicator              Local         Supports file replication in a domain
Server Operators        Local         Members can administer domain servers
Users                   Local         Ordinary users

   Total of 15 groups

LANDOFOZ\\TINMAN>

You can add users to groups in any of the following ways:

• When you use the ADD GROUP command, include the /MEMBERS qualifier.
• When you add a new user (using the ADD USER command), include the /MEMBER_OF_GROUPS qualifier. (See Section 3.1.6, Specifying Group Membership, for more information.)

Local groups can include users from domains other than the one currently being administered. To specify a user account from another domain, a trust relationship must be established that allows the domain being administered to trust the domain where the user account is defined.

To specify a user account or global group in a trusted domain, enter a domain-qualified name (domain-name\member-name), such as KANSAS\DOLE, where KANSAS is the name of the trusted domain, and DOLE is the user or group name defined in the trusted domain. If you omit a domain name, the user or group is assumed to be defined in the domain being administered.

3.2.3.1 Adding Members to a New Group

To add members to a new group, include the /MEMBERS qualifier on the ADD GROUP command. For example, to add a new group MUNCHKINS and specify the group members SCARECROW and STRAWMAN, enter the following command:

LANDOFOZ\\TINMAN> ADD GROUP MUNCHKINS/MEMBERS=(SCARECROW,STRAWMAN)
%PWRK-S-GROUPADD, group "MUNCHKINS" added to domain "LANDOFOZ"

LANDOFOZ\\TINMAN>