Document revision date: 30 March 2001

## OpenVMS Cluster Systems

Previous | 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 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.

### 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]

### 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.

Previous | Next | Contents | Index

| privacy and legal statement |
4477PRO_008.HTML