![Content starts here](http://welcome.hp-ww.com/img/s.gif) |
OpenVMS Cluster Systems
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.
|