|
HP OpenVMS Systems Documentation |
|
OpenVMS Version 7.3 Release Notes
5.3 External AuthenticationThis section contains release notes pertaining to external authentication. External authentication is an optional feature introduced in OpenVMS Version 7.1 that enables OpenVMS systems to authenticate designated users using their external user IDs and passwords.
Starting with OpenVMS Version 7.2, if you are running DECwindows and
you want a DECwindows user to be externally authenticated, you must be
running DECwindows Version 1.2-4 or later and Advanced Server for
OpenVMS, and meet any requirements outlined in the Advanced Server for
OpenVMS Server Installation and Configuration Guide. See this
manual and the OpenVMS Guide to System Security for detailed information about using
external authentication.
V7.2
With the release of Compaq TCP/IP Services for OpenVMS Version 5.0, the
File Transfer Protocol (FTP) server uses external authentication to
authenticate connections on the OpenVMS system.
V7.2
Chapter 7 of the OpenVMS Guide to System Security describes the SYS$SINGLE_SIGNON and
SYS$ACME_MODULE logical names currently used for external
authentication. Note that in a future release, the current interface
for enabling and controlling external authentication will be replaced
by a DCL command interface.
V7.2 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:
5.3.4 SET PASSWORD Behavior Within a DECterm Terminal SessionV7.2 A DECterm terminal session does not have access to the external user name used for login and must prompt for one during SET PASSWORD operations. The external user name defaults to the process's OpenVMS user name. If the default is not appropriate (that is, if the external user name and mapped OpenVMS user name are different), you must enter the correct external user name. The following example shows a SET PASSWORD operation initiated by a user with the external user name JOHN_DOE. The mapped OpenVMS user name is JOHNDOE and is the default used by the SET PASSWORD operation. In this case, the default is incorrect and the actual external user name was specified by the user.
5.3.5 Compaq DECnet-Plus RequirementV7.2-1 Users with the EXTAUTH bit set in their SYSUAF account record cannot use explicit access control strings with systems running Compaq DECnet-Plus unless their externally authenticated password is all uppercase characters. For example, if you enter the following command:
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:
5.3.6 DECwindows Pause Screen Uses SYSUAF PasswordV7.1 The DECwindows pause screen unlock mechanism does not use the external authentication service for password validation. It continues to use the password in the SYSUAF file, even if you have external authentication enabled on your system.
Password synchronization is enabled by default. If you have disabled
password synchronization, be sure to keep the LAN Manager and SYSUAF
passwords synchronized manually.
V7.3
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.
V7.1 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) will encounter problems in either of the following cases:
In such cases, the problem symptom is a user authentication failure from the layered product or application. For externally authenticated users, the normal system authorization database (SYSUAF.DAT) is used to construct the OpenVMS process profile (UIC, privileges, quotas, and so on) and to apply specific login restrictions. However, there are two key differences between externally authenticated users and normal OpenVMS users. The following is true for externally authenticated users:
OpenVMS attempts to keep a user's SYSUAF and external user password synchronized to minimize these problems. An up-to-date copy of the user's external password is kept in the SYSUAF, but this is not the case if, for example, the external password contains characters that are invalid in OpenVMS, or if SYSUAF password synchronization is disabled by the system manager. (Password synchronization is enabled by default.) If you enable external authentication, Compaq recommends you do the following to minimize incompatibility with layered products or applications that use traditional SYSUAF-based authentication:
The $GETUAI and $SETUAI system services do not support external
passwords. These services operate only on 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 should not enable external authentication.
Compaq expects to provide a new programming interface to support
external passwords in a future release.
V7.1 Compaq recommends using external authentication on OpenVMS Cluster systems only if all systems are running OpenVMS Version 7.1 or later.
LOGINOUT on earlier version systems continues to enforce normal OpenVMS
password policy (password expiration, password history, and so on), on
all users, including externally authenticated users.
V7.1
Starting with Version 7.1, the presence of LOGINOUT (LGI) callouts
disables external authentication.
V7.1 In the LAN Manager domain, a user cannot log in once a password expires.
Users on personal computers (PCs) receive notification of impending
external user password expiration and can change passwords before they
expire. However, when a user logs in from an OpenVMS workstation using
external authentication, the login process cannot determine if the
external password is about to expire. Therefore, sites that enforce
password expiration, and whose user population does not primarily use
PCs, may elect not to use external authentication for workstation users.
V7.3 Prior to OpenVMS V7.3, when running EDIT/FDL, the calculated bucket sizes were always rounded up to the closest disk-cluster boundary, with a maximum bucket size of 63. This could cause problems when the disk-cluster size was large, but the "natural" bucket size for the file was small, because the bucket size was rounded up to a much larger value than required. Larger bucket sizes increase record and bucket lock contention, and can seriously impact performance.
OpenVMS V7.3 modifies the algorithms for calculating the recommended
bucket size to suggest a more reasonable size when the disk cluster is
large.
This section contains OpenVMS Galaxy release notes for OpenVMS Version
7.3 and notes from OpenVMS Versions 7.2-1H1, 7.2-1, and 7.2 that apply
to this release.
Fibre Channel support for OpenVMS Galaxy configurations is included in OpenVMS Alpha Version 7.3 and OpenVMS Alpha Version 7.2-1H1. For OpenVMS Alpha Version 7.2-1, Fibre Channel support for OpenVMS Galaxy configurations is available in Fibre Channel remedial kits, starting with V721_FIBRECHAN-V0200. For the most current information about OpenVMS Fibre Channel configurations, go to: 5.5.2 CPU Migration RestrictionThe release of the Compaq Analyze service tool that supports the new Compaq AlphaServer GS Series systems includes a Director process that sets hard affinity to a CPU. A CPU with processes hard affinitized to it cannot be reassigned from one Galaxy instance to another. This is a temporary restriction.
For more information about Compaq Analyze and its operation, contact
your Compaq support representative.
OpenVMS Version 7.2 introduced new security classes that are used in an OpenVMS Galaxy computing environment. The new security classes are not valid on non-Galaxy systems. If your OpenVMS Galaxy is configured in an existing OpenVMS Cluster, you must ensure that all the nodes in the cluster recognize the new security classes as described in this release note. This situation applies if all of the following conditions are met:
OpenVMS VAX and Alpha systems running OpenVMS Version 6.2 or Version 7.1 will crash if they encounter an unknown security class in the VMS$OBJECTS.DAT file. To allow VAX and Alpha systems running older versions of OpenVMS to cooperate with Version 7.2 Galaxy instances in the same OpenVMS Cluster environment, a SECURITY.EXE image is provided for each of these versions. The appropriate remedial kit from the following list must be installed on all system disks used by these systems. (Later versions of these remedial kits may be used if available.)
Before you create any galaxywide global sections, you must reboot all
cluster members sharing one of the updated system disks.
AlphaServer GS60/GS60E/GS140 configurations with more than a single I/O Port Module, KFTHA-AA or KFTIA-AA, might experience system crashes. When upgrading OpenVMS Galaxy and non-Galaxy AlphaServer 8200/8400 configurations with multiple I/O Port Modules to GS60/GS60E/GS140 systems, customers must install one minimum revision B02 KN7CG-AB EV6 CPU (E2063-DA/DB rev D01) module as described in Compaq Action Blitz # TD 2632.
For complete details about this restriction and its solution, refer to
Compaq Action Blitz # TD 2632.
In an OpenVMS Galaxy computing environment, MOP (Maintenance Operations
Protocol) Booting is only supported on Instance 0. This restriction
will be removed in a future release.
Permanent Restriction
Due to firmware addressing limitations on driver-adapter control data
structures, KFMSB and CIXCD adapters can only be used on hardware
partitions based at physical address (PA) = 0. In OpenVMS Galaxy
configurations, this restricts their use to Instance 0.
This section contains a release note pertaining to the local area
network (LAN) asynchronous transfer mode (ATM) software.
The DAPBA (155 Mb/s) and the DAPCA (622 Mb/s) are ATM adapters for PCI-bus systems that are supported by SYS$HWDRIVER4.EXE. Both adapters require a great deal of non-paged pool, and therefore, care should be taken when configuring them. For each DAPBA, Compaq recommends increasing the SYSGEN parameter NPAGEVIR by 3000000. For each DAPCA, Compaq recommends increasing NPAGEVIR by 6000000. To do this, add the ADD_NPAGEVIR parameter to MODPARAMS.DAT and then run AUTOGEN. For example, add the following command to MODPARAMS.DAT on a system with two DAPBAs and one DAPCA:
The following restrictions apply to the DAPBA and DAPCA adapters:
5.7 Lock Manager
This section contains notes pertaining to the lock manager.
V7.3
The OpenVMS Performance Management incorrectly refers to the LOCKMGR_CPU system parameter
in its discussion of the Dedicated CPU lock manager. The LOCKMGR_CPU
system parameter name has been changed to LCKMGR_CPUID.
V7.3 With OpenVMS Version 7.3, Compaq introduces an alternative locking mode that allows a CPU to be dedicated to the lock manager. The dedicated CPU lock manager can perform better than the traditional lock manager under heavy locking loads. The performance gains are a result of reducing SMP contention and obtaining the benefits of improved CPU cache utilization on the CPU dedicated to the lock manager.
Usage of the dedicated CPU lock manager is only of benefit to systems
with a large number of CPUs and heavy SMP contention due to the lock
manager. By default, a CPU will not be dedicated to the lock manager.
See the OpenVMS Version 7.3 New Features and Documentation Overview for information and details about enabling the
dedicated CPU lock manager.
V7.3 The OpenVMS Distributed Lock Manager has a feature called lock remastering. A lock remaster is the process of moving the lock mastership of a resource tree to another node in the cluster. The node that masters a lock tree can process local locking requests much faster because communication is not required with another node in the cluster. Having a lock tree reside on the node doing the most locking operations can improve overall system performance. Prior to OpenVMS Version 7.3, lock remastering resulted in all nodes sending one message per local lock to the new master. For a very large lock tree, it could require a substantial amount of time to perform the lock remastering operation. During the operation, all application locking to the lock tree is stalled. Starting with OpenVMS Version 7.3, sending lock data to the new master is done with very large transfers. This is a much more efficient process and results in moving a lock tree from 3 to 20 times faster. Only nodes running Version 7.3 or later can use large transfers for lock remastering. Remastering between OpenVMS Version 7.3 nodes and prior version nodes still requires sending a single message per lock.
If you currently use the PE1 system parameter to limit the size of lock
trees that can be remastered, Compaq recommends that you either try
increasing the value to allow large lock trees to move or try setting
the value to zero (0) to allow any size lock tree to move.
V7.2 To improve application scalability on OpenVMS Alpha systems, most of the lock manager data structures have been moved from nonpaged pool to S2 space. On many systems, the lock manager data structures accounted for a large percentage of nonpaged pool usage. Because of this change to nonpaged pool, Compaq recommends the following steps:
The SHOW MEMORY documentation in the OpenVMS DCL Dictionary: N--Z describes the memory
associated with the lock manager.
This section contains release notes pertaining to the Operator
Communication Manager (OPCOM).
V7.2 In OpenVMS Alpha Version 7.2 and later, OPCOM messages from the job controller and the queue manager now display SYSTEM as the user process. For example:
The examples in the OpenVMS System Manager's Manual do not currently reflect this change.
V7.3 Previously, if the OPC$OPA0_CLASSES or OPC$LOGFILE_CLASSES logicals contained an invalid class, it would cause OPCOM to signal the error and run down the process. This problem has been corrected in OpenVMS Version 7.3. The following two messages have been added to OPCOM:
If an invalid class name is specified in either of the logicals, the appropriate error message is displayed. These messages are displayed on the console at system startup and logged to the OPERATOR.LOG. The list of all operator classes is: CARDS
When you specify an invalid class, all classes are enabled. This change
causes the error messages listed to reach as many operators as possible.
V7.3 The algorithm formerly used by OPCOM when OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND were set to FALSE was found to be too restrictive. These logical names do not allow messages to flow into or out of the OPCOM process. When these logicals were used together in an OpenVMS Cluster, it was possible for OPCOM processes on different systems in the cluster to stop communicating. As a result, OPERATOR.LOG files would fill up with messages similar to the following:
To correct this problem, the algorithm has been relaxed to allow OPCOM processes in an OpenVMS Cluster to pass communication messages back and forth between one another. Compaq still recommends caution in the use of these logical names, which should be used only by individuals who truly understand the impact to the entire system if OPCOM messages are disabled in one or both directions.
|