 |
HP OpenVMS Cluster Systems
5.5.3 Combining Existing Procedures
To build startup procedures for an OpenVMS Cluster system in which
existing computers are to be combined, you should compare both the
computer-specific SYSTARTUP_VMS and the common startup command
procedures on each computer and make any adjustments required. For
example, you can compare the procedures from each computer and include
commands that define the same logical names in your common
SYSTARTUP_VMS command procedure.
After you have chosen which commands to make common, you can build the
common procedures on one of the OpenVMS Cluster computers.
5.5.4 Using Multiple Startup Procedures
To define a multiple-environment cluster, you set up computer-specific
versions of one or more system files. For example, if you want to give
users larger working set quotas on URANUS, you would create a
computer-specific version of SYSUAF.DAT and place that file in system's
root directory. That directory can be located in URANUS's root on a
common system disk or on an individual system disk that you have set up
on URANUS.
Follow these steps to build SYSTARTUP and SYLOGIN command files for a
multiple-environment OpenVMS Cluster:
| Step |
Action |
|
1
|
Include in SYSTARTUP_VMS.COM elements that you want to remain unique to
a computer, such as commands to define computer-specific logical names
and symbols.
|
|
2
|
Place these files in the SYS$SPECIFIC root on each computer.
|
Example: Consider a three-member cluster consisting of
computers JUPITR, SATURN, and PLUTO. The timesharing environments on
JUPITR and SATURN are the same. However, PLUTO runs applications for a
specific user group. In this cluster, you would create a common
SYSTARTUP_VMS command procedure for JUPITR and SATURN that defines
identical environments on these computers. But the command procedure
for PLUTO would be different; it would include commands to define
PLUTO's special application environment.
5.6 Providing OpenVMS Cluster System Security
The OpenVMS security subsystem ensures that all authorization
information and object security profiles are consistent across all
nodes in the cluster. The OpenVMS operating system does not support
multiple security domains because the operating system cannot enforce a
level of separation needed to support different security domains on
separate cluster members.
5.6.1 Security Checks
In an OpenVMS Cluster system, individual nodes use a common set of
authorizations to mediate access control that, in effect, ensures that
a security check results in the same answer from any node in the
cluster. The following list outlines how the OpenVMS operating system
provides a basic level of protection:
- Authorized users can have processes executing on any OpenVMS
Cluster member.
- A process, acting on behalf of an authorized individual, requests
access to a cluster object.
- A coordinating node determines the outcome by comparing its copy of
the common authorization database with the security profile for the
object being accessed.
The OpenVMS operating system provides the same strategy for the
protection of files and queues, and further incorporates all other
cluster-visible objects, such as devices, volumes, and lock resource
domains.
Starting with OpenVMS Version 7.3, the operating system provides
clusterwide intrusion detection, which extends protection against
attacks of all types throughout the cluster. The intrusion data and
information from each system is integrated to protect the cluster as a
whole. Prior to Version 7.3, each system was protected individually.
The SECURITY_POLICY system parameter controls whether a local or a
clusterwide intrusion database is maintained for each system. The
default setting is for a clusterwide database, which contains all
unauthorized attempts and the state of any intrusion events for all
cluster members that are using this setting. Cluster members using the
clusterwide intrusion database are made aware if a cluster member is
under attack or has any intrusion events recorded. Events recorded on
one system can cause another system in the cluster to take restrictive
action. (For example, the person attempting to log in is monitored more
closely and limited to a certain number of login retries within a
limited period of time. Once a person exceeds either the retry or time
limitation, he or she cannot log in.)
Actions of the cluster manager in setting up an OpenVMS Cluster system
can affect the security operations of the system. You can facilitate
OpenVMS Cluster security management using the suggestions discussed in
the following sections.
The easiest way to ensure a single security domain is to maintain a
single copy of each of the following files on one or more disks that
are accessible from anywhere in the OpenVMS Cluster system. When a
cluster is configured with multiple system disks, you can use system
logical names (as shown in Section 5.8) to ensure that only a single
copy of each file exists.
The OpenVMS security domain is controlled by the data in the following
files:
SYS$MANAGER:VMS$AUDIT_SERVER.DAT
SYS$SYSTEM:NETOBJECT.DAT
SYS$SYSTEM:NETPROXY.DAT
TCPIP$PROXY.DAT
SYS$SYSTEM:PE$IP_CONFIG.DAT
SYS$SYSTEM:QMAN$MASTER.DAT
SYS$SYSTEM:RIGHTSLIST.DAT
SYS$SYSTEM:SYSALF.DAT
SYS$SYSTEM:SYSUAF.DAT
SYS$SYSTEM:SYSUAFALT.DAT
SYS$SYSTEM:VMS$PASSWORD_HISTORY.DATA
SYS$SYSTEM:VMSMAIL_PROFILE.DATA
SYS$LIBRARY:VMS$PASSWORD_DICTIONARY.DATA
SYS$LIBRARY:VMS$PASSWORD_POLICY.EXE
Note: Using shared files is not the only way of
achieving a single security domain. You may need to use multiple copies
of one or more of these files on different nodes in a cluster. For
example, on Alpha nodes you may choose to deploy system-specific user
authorization files (SYSUAFs) to allow for different memory management
working-set quotas among different nodes. Such configurations are fully
supported as long as the security information available to each node in
the cluster is identical.
5.6.2 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, HP
recommends that you synchronize the recommended files.
|
Table 5-3 Security Files
| File Name |
Contains |
|
CLUSTER_AUTHORIZE.DAT
|
The cluster authorization file,
SYS$COMMON:[SYSEXE]CLUSTER_AUTHORIZE.DAT, contains the cluster group
number in a disorderly form and the cluster password. The
CLUSTER_AUTHORIZE.DAT file is accessible only to users with the SYSPRV
privilege.
|
PE$IP_CONFIG.DAT
[recommended]
|
For cluster over IP configurations, which are using IP unicast, the
remote node IP address should be present in the existing cluster
members file in the SYS$SYSTEM:PE$IP_CONFIG.DAT file. Remote nodes in a
different IP multicast domain can use the IP unicast messaging
technique to join the Cluster.
|
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 HP 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.8.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.DAT 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.8.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
HP 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.8.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.8.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.8.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.8.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$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 among different
architecture types.
|
5.7 Network Security
Network security must promote interoperability and uniform security
approaches throughout networks. The following list shows three major
areas of network security:
OpenVMS Cluster system managers must also ensure consistency in the use
of DECnet software for intracluster communication.
|
