OpenVMS Cluster Systems

Document revision date: 30 March 2001

OpenVMS Cluster Systems

Contents

Index

5.8 Files Relevant to OpenVMS Cluster Security

Table 5-3 describes the security-relevant portions of the files that must be common across all cluster members to ensure that a single security domain exists.

Notes:

Some of these files are created only on request and may not exist in all configurations.
A file can be absent on one node only if it is absent on all nodes.
As soon as a required file is created on one node, it must be created or commonly referenced on all remaining cluster nodes.

The following table describes designations for the files in Table 5-3.

Table Keyword Meaning

Required The file contains some data that must be kept common across all cluster members to ensure that a single security environment exists.

Recommended The file contains data that should be kept common at the discretion of the site security administrator or system manager. Nonetheless, Digital recommends that you synchronize the recommended files.

Table Keyword	Meaning
Required	The file contains some data that must be kept common across all cluster members to ensure that a single security environment exists.
Recommended	The file contains data that should be kept common at the discretion of the site security administrator or system manager. Nonetheless, Digital recommends that you synchronize the recommended files.

Table 5-3 Security Files
File Name Contains

VMS$AUDIT_SERVER.DAT
[recommended] Information related to security auditing. Among the information contained is the list of enabled security auditing events and the destination of the system security audit journal file. When more than one copy of this file exists, all copies should be updated after any SET AUDIT command.
OpenVMS Cluster system managers should ensure that the name assigned to the security audit journal file resolves to the following location:
SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL

Rule: If you need to relocate the audit journal file somewhere other than the system disk (or if you have multiple system disks), you should redirect the audit journal uniformly across all nodes in the cluster. Use the command SET AUDIT/JOURNAL=SECURITY/DESTINATION= file-name, specifying a file name that resolves to the same file throughout the cluster.
Changes are automatically made in the audit server database, SYS$MANAGER:VMS$AUDIT_SERVER.DAT. This database also identifies which events are enabled and how to monitor the audit system's use of resources, and restores audit system settings each time the system is rebooted.
Caution: Failure to synchronize multiple copies of this file properly may result in partitioned auditing domains.
Reference: For more information, see the OpenVMS Guide to System Security.

NETOBJECT.DAT
[required] The DECnet object database. Among the information contained in this file is the list of known DECnet server accounts and passwords. When more than one copy of this file exists, all copies must be updated after every use of the NCP commands SET OBJECT or DEFINE OBJECT.
Caution: Failure to synchronize multiple copies of this file properly may result in unexplained network login failures and unauthorized network access. For instructions on maintaining a single copy, refer to Section 5.10.1.
Reference: Refer to the DECnet--Plus documentation for equivalent NCL command information.

NETPROXY.DAT
and NET$PROXY.DAT
[required] The network proxy database. It is maintained by the OpenVMS Authorize utility. When more than one copy of this file exists, all copies must be updated after any UAF proxy command.
Note: The NET$PROXY.DAT and NETPROXY.DAT files are equivalent; NET$PROXY is for DECnet--Plus implementations and NETPROXY.DAT is for DECnet for OpenVMS implementations.
Caution: Failure to synchronize multiple copies of this file properly may result in unexplained network login failures and unauthorized network access. For instructions on maintaining a single copy, refer to Section 5.10.1.
Reference: Appendix B discusses how to consolidate several NETPROXY.DAT and RIGHTSLIST.DAT files.

TCPIP$PROXY.DAT This database provides OpenVMS identities for remote NFS clients and UNIX-style identifiers for local NFS client users; provides proxy accounts for remote processes. For more information about this file, see the Compaq TCP/IP Services for OpenVMS Management manual.

QMAN$MASTER.DAT
[required] The master queue manager database. This file contains the security information for all shared batch and print queues.
Rule: If two or more nodes are to participate in a shared queuing system, a single copy of this file must be maintained on a shared disk. For instructions on maintaining a single copy, refer to Section 5.10.1.

RIGHTSLIST.DAT
[required] The rights identifier database. It is maintained by the OpenVMS Authorize utility and by various rights identifier system services. When more than one copy of this file exists, all copies must be updated after any change to any identifier or holder records.
Caution: Failure to synchronize multiple copies of this file properly may result in unauthorized system access and unauthorized access to protected objects. For instructions on maintaining a single copy, refer to Section 5.10.1.
Reference: Appendix B discusses how to consolidate several NETPROXY.DAT and RIGHTSLIST.DAT files.

SYSALF.DAT
[required] The system Autologin facility database. It is maintained by the OpenVMS SYSMAN utility. When more than one copy of this file exists, all copies must be updated after any SYSMAN ALF command.
Note: This file may not exist in all configurations.
Caution: Failure to synchronize multiple copies of this file properly may result in unexplained login failures and unauthorized system access. For instructions on maintaining a single copy, refer to Section 5.10.1.

SYSUAF.DAT
[required] The system user authorization file. It is maintained by the OpenVMS Authorize utility and is modifiable via the $SETUAI system service. When more than one copy of this file exists, you must ensure that the SYSUAF and associated $SETUAI item codes are synchronized for each user record. The following table shows the fields in SYSUAF and their associated $SETUAI item codes.

Internal Field Name $SETUAI Item Code

UAF$R_DEF_CLASS UAI$_DEF_CLASS

UAF$Q_DEF_PRIV UAI$_DEF_PRIV

UAF$B_DIALUP_ACCESS_P UAI$_DIALUP_ACCESS_P

UAF$B_DIALUP_ACCESS_S UAI$_DIALUP_ACCESS_S

UAF$B_ENCRYPT UAI$_ENCRYPT

UAF$B_ENCRYPT2 UAI$_ENCRYPT2

UAF$Q_EXPIRATION UAI$_EXPIRATION

UAF$L_FLAGS UAI$_FLAGS

UAF$B_LOCAL_ACCESS_P UAI$_LOCAL_ACCESS_P

UAF$B_LOCAL_ACCESS_S UAI$_LOCAL_ACCESS_S

UAF$B_NETWORK_ACCESS_P UAI$_NETWORK_ACCESS_P

UAF$B_NETWORK_ACCESS_S UAI$_NETWORK_ACCESS_S

UAF$B_PRIME_DAYS UAI$_PRIMEDAYS

UAF$Q_PRIV UAI$_PRIV

UAF$Q_PWD UAI$_PWD

UAF$Q_PWD2 UAI$_PWD2

UAF$Q_PWD_DATE UAI$_PWD_DATE

UAF$Q_PWD2_DATE UAI$_PWD2_DATE

UAF$B_PWD_LENGTH UAI$_PWD_LENGTH

UAF$Q_PWD_LIFETIME UAI$_PWD_LIFETIME

UAF$B_REMOTE_ACCESS_P UAI$_REMOTE_ACCESS_P

UAF$B_REMOTE_ACCESS_S UAI$_REMOTE_ACCESS_S

UAF$R_MAX_CLASS UAI$_MAX_CLASS

UAF$R_MIN_CLASS UAI$_MIN_CLASS

UAF$W_SALT UAI$_SALT

UAF$L_UIC Not applicable

Caution: Failure to synchronize multiple copies of the SYSUAF files properly may result in unexplained login failures and unauthorized system access. For instructions on maintaining a single copy, refer to Section 5.10.1.
Reference: Appendix B discusses creation and management of the various elements of an OpenVMS Cluster common SYSUAF.DAT authorization database.

SYSUAFALT.DAT
[required] The system alternate user authorization file. This file serves as a backup to SYSUAF.DAT and is enabled via the SYSUAFALT system parameter. When more than one copy of this file exists, all copies must be updated after any change to any authorization records in this file.
Note: This file may not exist in all configurations.
Caution: Failure to synchronize multiple copies of this file properly may result in unexplained login failures and unauthorized system access.

+VMS$OBJECTS.DAT
[required] On VAX systems, this file is located in SYS$COMMON:[SYSEXE] and contains the clusterwide object database. Among the information contained in this file are the security profiles for all clusterwide objects. When more than one copy of this file exists, all copies must be updated after any change to the security profile of a clusterwide object or after new clusterwide objects are created. Clusterwide objects include disks, tapes, and resource domains.
OpenVMS Cluster system managers should ensure that the security object database is present on each node in the OpenVMS Cluster by specifying a file name that resolves to the same file throughout the cluster, not to a file that is unique to each node.
The database is updated whenever characteristics are modified, and the information is distributed so that all nodes participating in the cluster share a common view of the objects. The security database is created and maintained by the audit server process.
Rule: If you relocate the database, be sure the logical name VMS$OBJECTS resolves to the same file for all nodes in a common-environment cluster. To reestablish the logical name after each system boot, define the logical in SYSECURITY.COM.
Caution: Failure to synchronize multiple copies of this file properly may result in unauthorized access to protected objects.

VMS$PASSWORD_HISTORY.DATA
[recommended] The system password history database. It is maintained by the system password change facility. When more than one copy of this file exists, all copies should be updated after any password change.
Caution: Failure to synchronize multiple copies of this file properly may result in a violation of the system password policy.

VMSMAIL_PROFILE.DATA
[recommended] The system mail database. This file is maintained by the OpenVMS Mail utility and contains mail profiles for all system users. Among the information contained in this file is the list of all mail forwarding addresses in use on the system. When more than one copy of this file exists, all copies should be updated after any changes to mail forwarding.
Caution: Failure to synchronize multiple copies of this file properly may result in unauthorized disclosure of information.

VMS$PASSWORD_DICTIONARY.DATA
[recommended] The system password dictionary. The system password dictionary is a list of English language words and phrases that are not legal for use as account passwords. When more than one copy of this file exists, all copies should be updated after any site-specific additions.
Caution: Failure to synchronize multiple copies of this file properly may result in a violation of the system password policy.

VMS$PASSWORD_POLICY.EXE
[recommended] Any site-specific password filters. It is created and installed by the site-security administrator or system manager. When more than one copy of this file exists, all copies should be identical.
Caution: Failure to synchronize multiple copies of this file properly may result in a violation of the system password policy.
Note: System managers can create this file as an image to enforce their local password policy. This is an architecture-specific image file that cannot be shared between VAX and Alpha computers.

+VAX specific
++Alpha specific

5.9 Network Security

Network security should promote interoperability and uniform security approaches throughout networks. The following list shows three major areas of network security:

User authentication
OpenVMS Cluster membership management
Using a security audit log file

OpenVMS Cluster system managers should also ensure consistency in the use of DECnet software for intracluster communication.

5.9.1 Mechanisms

Depending on the level of network security required, you might also want to consider how other security mechanisms, such as protocol encryption and decryption, can promote additional security protection across the cluster.

Reference: See the OpenVMS Guide to System Security.

5.10 Coordinating System Files

Follow these guidelines to coordinate system files:

IF you are setting up... THEN follow the procedures in...

A common-environment OpenVMS Cluster that consists of newly installed systems OpenVMS System Manager's Manual to build these files. Because the files on new operating systems are empty except for the Digital-supplied accounts, very little coordination is necessary.

An OpenVMS Cluster that will combine one or more computers that have been running with computer-specific files Appendix B to create common copies of the files from the computer-specific files.

IF you are setting up...	THEN follow the procedures in...
A common-environment OpenVMS Cluster that consists of newly installed systems	OpenVMS System Manager's Manual to build these files. Because the files on new operating systems are empty except for the Digital-supplied accounts, very little coordination is necessary.
An OpenVMS Cluster that will combine one or more computers that have been running with computer-specific files	Appendix B to create common copies of the files from the computer-specific files.

5.10.1 Procedure

In a common-environment cluster with one common system disk, you use a common copy of each system file and place the files in the SYS$COMMON:[SYSEXE] directory on the common system disk or on a disk that is mounted by all cluster nodes. No further action is required.

To prepare a common user environment for an OpenVMS Cluster system that includes more than one common VAX system disk or more than one common Alpha system disk, you must coordinate the system files on those disks.

Rules: The following rules apply to the procedures described in Table 5-4:

Disks holding common resources must be mounted early in the system startup procedure, such as in the SYLOGICALS.COM procedure.
You must ensure that the disks are mounted with each OpenVMS Cluster reboot.

Table 5-4 Procedure for Coordinating Files
Step Action

1 Decide where to locate the SYSUAF.DAT and NETPROXY.DAT files. In a cluster with multiple system disks, system management is much easier if the common system files are located on a single disk that is not a system disk.

2 Copy SYS$SYSTEM:SYSUAF.DAT and SYS$SYSTEM:NETPROXY.DAT to a location other than the system disk.

3 Copy SYS$SYSTEM:RIGHTSLIST.DAT and SYS$SYSTEM:VMSMAIL_PROFILE.DATA to the same directory in which SYSUAF.DAT and NETPROXY.DAT reside.

4 Edit the file SYS$COMMON:[SYSMGR]SYLOGICALS.COM on each system disk and define logical names that specify the location of the cluster common files.
Example: If the files will be located on $1$DJA16, define logical names as follows:
$ DEFINE/SYSTEM/EXEC SYSUAF -
$1$DJA16:[VMS$COMMON.SYSEXE]SYSUAF.DAT
$ DEFINE/SYSTEM/EXEC NETPROXY -
$1$DJA16:[VMS$COMMON.SYSEXE]NETPROXY.DAT
$ DEFINE/SYSTEM/EXEC RIGHTSLIST -
$1$DJA16:[VMS$COMMON.SYSEXE]RIGHTSLIST.DAT
$ DEFINE/SYSTEM/EXEC VMSMAIL_PROFILE -
$1$DJA16:[VMS$COMMON.SYSEXE]VMSMAIL_PROFILE.DATA
$ DEFINE/SYSTEM/EXEC NETNODE_REMOTE -
$1$DJA16:[VMS$COMMON.SYSEXE]NETNODE_REMOTE.DAT
$ DEFINE/SYSTEM/EXEC NETNODE_UPDATE -
$1$DJA16:[VMS$COMMON.SYSMGR]NETNODE_UPDATE.COM
$ DEFINE/SYSTEM/EXEC QMAN$MASTER -
$1$DJA16:[VMS$COMMON.SYSEXE]

5 To ensure that the system disks are mounted correctly with each reboot, follow these steps:

Copy the SYS$EXAMPLES:CLU_MOUNT_DISK.COM file to the [VMS$COMMON.SYSMGR] directory, and edit it for your configuration.
Edit SYLOGICALS.COM and include commands to mount, with the appropriate volume label, the system disk containing the shared files.
Example: If the system disk is $1$DJA16, include the following command:

$ @SYS$SYSDEVICE:[VMS$COMMON.SYSMGR]CLU_MOUNT_DISK.COM $1$DJA16: volume-label

6 When you are ready to start the queuing system, be sure you have moved the queue and journal files to a cluster-available disk. Any cluster common disk is a good choice if the disk has sufficient space.
Enter the following command:
$ START/QUEUE/MANAGER $1$DJA16:[VMS$COMMON.SYSEXE]

**Table 5-4 Procedure for Coordinating Files**
Step	Action
1	Decide where to locate the SYSUAF.DAT and NETPROXY.DAT files. In a cluster with multiple system disks, system management is much easier if the common system files are located on a single disk that is not a system disk.
2	Copy SYS$SYSTEM:SYSUAF.DAT and SYS$SYSTEM:NETPROXY.DAT to a location other than the system disk.
3	Copy SYS$SYSTEM:RIGHTSLIST.DAT and SYS$SYSTEM:VMSMAIL_PROFILE.DATA to the same directory in which SYSUAF.DAT and NETPROXY.DAT reside.
4	Edit the file SYS$COMMON:[SYSMGR]SYLOGICALS.COM on each system disk and define logical names that specify the location of the cluster common files. Example: If the files will be located on $1$DJA16, define logical names as follows: $ DEFINE/SYSTEM/EXEC SYSUAF - $1$DJA16:[VMS$COMMON.SYSEXE]SYSUAF.DAT $ DEFINE/SYSTEM/EXEC NETPROXY - $1$DJA16:[VMS$COMMON.SYSEXE]NETPROXY.DAT $ DEFINE/SYSTEM/EXEC RIGHTSLIST - $1$DJA16:[VMS$COMMON.SYSEXE]RIGHTSLIST.DAT $ DEFINE/SYSTEM/EXEC VMSMAIL_PROFILE - $1$DJA16:[VMS$COMMON.SYSEXE]VMSMAIL_PROFILE.DATA $ DEFINE/SYSTEM/EXEC NETNODE_REMOTE - $1$DJA16:[VMS$COMMON.SYSEXE]NETNODE_REMOTE.DAT $ DEFINE/SYSTEM/EXEC NETNODE_UPDATE - $1$DJA16:[VMS$COMMON.SYSMGR]NETNODE_UPDATE.COM $ DEFINE/SYSTEM/EXEC QMAN$MASTER - $1$DJA16:[VMS$COMMON.SYSEXE]
5	To ensure that the system disks are mounted correctly with each reboot, follow these steps: Copy the SYS$EXAMPLES:CLU_MOUNT_DISK.COM file to the [VMS$COMMON.SYSMGR] directory, and edit it for your configuration. Edit SYLOGICALS.COM and include commands to mount, with the appropriate volume label, the system disk containing the shared files. Example: If the system disk is $1$DJA16, include the following command: $ @SYS$SYSDEVICE:[VMS$COMMON.SYSMGR]CLU_MOUNT_DISK.COM $1$DJA16: volume-label
6	When you are ready to start the queuing system, be sure you have moved the queue and journal files to a cluster-available disk. Any cluster common disk is a good choice if the disk has sufficient space. Enter the following command: $ START/QUEUE/MANAGER $1$DJA16:[VMS$COMMON.SYSEXE]

5.10.2 Network Database Files

In OpenVMS Cluster systems on the LAN and in mixed-interconnect clusters, you must also coordinate the SYS$MANAGER:NETNODE_UPDATE.COM file, which is a file that contains all essential network configuration data for satellites. NETNODE_UPDATE.COM is updated each time you add or remove a satellite or change its Ethernet or FDDI hardware address. This file is discussed more thoroughly in Section 10.4.2.

In OpenVMS Cluster systems configured with DECnet for OpenVMS software, you must also coordinate NETNODE_REMOTE.DAT, which is the remote node network database.

5.11 System Time on the Cluster

When a computer joins the cluster, the cluster attempts to set the joining computer's system time to the current time on the cluster. Although it is likely that the system time will be similar on each cluster computer, there is no assurance that the time will be set. Also, no attempt is made to ensure that the system times remain similar throughout the cluster. (For example, there is no protection against different computers having different clock rates.)

An OpenVMS Cluster system spanning multiple time zones must use a single, clusterwide common time on all nodes. Use of a common time ensures timestamp consistency (for example, between applications, file-system instances) across the OpenVMS Cluster members.

Contents

Index

privacy and legal statement

4477PRO_008.HTML