The following discussion is based on a cluster consisting of Compaq systems running Tru64 UNIX Version 5.0A and TruCluster Server Version 5.0A.
A TruCluster is a single security domain. Identification and authentication, access control lists (ACLs), and auditing are configured identically on each member by default, presenting a coherent interface to the user and the system administrator.
Because a single copy of the authentication files is shared among all
cluster members, each user account is valid on all cluster members and a user
can log in to the cluster alias without concern for which member accepts the
connection.
Identically configured ACL checking means consistent authorization
and file access control; a user has the same access rights from every member.
Cluster-wide audit settings ensure a uniform capture of cluster activity.
G.2 Enabling Security Features in a Cluster
The following sections describe how the enhanced security features are
enabled in a cluster.
G.2.1 Access Control Lists
The Security Configuration icon on the Custom Setup menu of the
secconfig
utility contains a checkbox that enables or disables access
control list support on all cluster members, under either base or enhanced
authentication.
ACL support determines the state (enabled or disabled) of
access checking and ACL inheritance.
Note that ACLs can be created, modified,
deleted and examined regardless of the state of ACL support.
The NFS file systems require the
proplistd
daemon
to support ACLs.
G.2.2 Audit
The Audit Configuration icon on the Custom Setup menu of the
auditconfig
utility configures audit options cluster-wide.
The kernel
build performed by cluster creation automatically includes support for audit.
Audit configuration occurs in two steps.
In the first, the parameters
for the audit daemon, such as the name and location of the audit log file,
are specified.
In the second, a set of events to audit, called the audit mask,
is selected.
The configuration utility ensures that the same parameters and
events are used on each cluster member.
To maintain a single point of administration,
the
auditconfig
utility stores this audit configuration
information in the
/etc/rc.config.common
file.
G.2.3 Authentication
Both base and enhanced authentication are supported in a cluster.
Base
security, which uses the standard UNIX
/etc/passwd
and
/etc/group
authentication files, is the default configuration.
Enhanced authentication, which moves passwords into an authentication database,
is configured using the Security Configuration icon on the Custom Setup menu
of the
secconfig
utility.
The ideal time to configure enhanced authentication for a cluster is
before loading the TruCluster Server license and subsets and creating the
cluster.
You must select the enhanced security subsets (OSFC2SECxxx and OSFXC2SECxxx)
during the installation.
Enhanced authentication options are enabled cluster-wide
in the Custom or Shadow Password mode.
(You can also enable ACL support from
this utility.)
G.2.4 Distributed Logins and NIS
A cluster provides a common authentication environment to enable secure, distributed, highly available logins. The cluster can additionally function as a NIS master, slave, or client. (Note that all cluster members should play the same role in a NIS environment.)
As a NIS master, the cluster supports the NIS distribution of both standard
user profiles from
/etc/ passwd
and the enhanced user
profiles available with enhanced security maintained in the protected password
database.
These enhanced user profiles can be distributed by NIS as the
prpasswd
map, in the same manner that
/etc/passwd
is distributed as the
passwd
map.
G.2.5 Configuring a NIS Master in a Cluster with Enhanced Security
To set up a cluster running enhanced security as a NIS master, perform the following procedure:
Set up enhanced security as previously discussed.
Load
/var/yp/src, including
passwd
with specified accounts, as discussed in the Tru64 UNIX
Network Administration
guide.
Set up the
prpasswd
map with one line
per entry using
convuser -Mc.
See the
convuser(8)
reference
page.
Set up NIS as described in the Tru64 UNIX
Network Administration
guide.
When running
nissetup, select the
-Ssecurity
option of
ypbind
to bind the member to an authorized list
of NIS servers and specify the cluster alias as one of these servers.
Modify the map maintenance scripts to support
prpasswd
maps as discussed in the Tru64 UNIX
Network Administration
guide.
Notes
In domains where one or more nodes are running enhanced security and that mix Tru64 UNIX Version 5.0A and higher and DIGITAL UNIX Version 4.x systems, a Tru64 UNIX Version 5.0A or higer system must be the master. If none of the nodes are running enhanced security, a Version 4.x system can be the master.
The
dxaccountsutility does not allow you to add a NIS account and change the user's security options at the same time. You must first create the account and then change the user's security options.The
useraddcommand fails unless the user's primary group is defined in the/var/yp/src/groupmap.
G.3 Authentication in a Cluster
Enabling enhanced security introduces a new daemon,
prpasswdd.
Two instances of the daemon, a parent and a child, execute on
each cluster member.
The parent is primarily responsible for starting or restarting
the child.
The child is responsible for writing changes to the authentication
database.
To eliminate lock contention in a cluster, only the daemon on the
cluster member serving the
/var
mount point actually
performs writes for all clients.
The other
prpasswdd
daemons
are in hot standby mode.
If the cluster member serving the mount point and
containing the active daemon fails, another member assumes both roles.
On a cluster acting as a NIS master with enhanced security, the
rpc.yppasswdd
daemon acts in the same fashion as the
prpasswdd
for the NIS
prpasswd
map.
G.4 Auditing in a Cluster
In a Version 5.0A cluster, no additional kernel rebuild is required to
enable auditing because the DEC_AUDIT kernel option and the
/dev/audit
special file are automatically included on all cluster members
in the initial cluster kernel build.
When auditing is enabled, an audit daemon (auditd)
runs on each member of the cluster.
Each audit daemon records event-specific
audit log entries in a private audit log file, named by default
/var/audit/auditlog.{membername}.nnn.
Each audit log entry includes the hos tname
of the member on which it occurred, facilitating a merged display of the entries
from multiple audit log files.
Figure G-1
illustrates how
audit data is gathered.
Figure G-1: Audit Data Flow in a Cluster
Each audit daemon writes its error or status messages to the local
/var/adm/syslog.dated/DATE/daemon.log
file, or optionally to a common audit console file.
The set of events to be audited, called the audit mask, is initially
generated using the
auditconfig
utility.
This utility specifies
a common audit mask that is created cluster-wide.
Initial start up of the
audit daemon uses information from the
/etc/rc.config.common
file.
Thus, the same
auditd
command line options and the
same audit mask are used for each member.
On a running cluster, the
auditd
commands may be
directed to every active daemon using the
auditd -cluster
option.
For instance,
auditd -cluster -w
displays the status
of each member.
Similarly, the
auditmask -cluster
option
can change or display the audit mask on every active member.
While it is possible to specify different audit daemon parameters or different audit masks for the audit daemons in a cluster, this can be confusing and is not recommended.
The
audit_tool
utility can merge audit log files
to present a cluster-wide view of events sorted by forward time progression.
Because host name information is recorded with each event, event origin can
easily be determined.
G.4.1 Cluster Command Examples
This section provides examples of audit commands as they would be executed
on a member system in a two member (haydn
and
handel), Version 5.0A cluster.
To get each member's
auditd
status, enter the following:
#auditd -cluster -wAudit data and msgs: -l) audit data destination = /var/audit/auditlog.handel.003 -c) audit console messages = syslog Network: -s) network audit server status (toggle) = off -t) connection timeout value (sec) = 4 Overflow control: -f) % free space before overflow condition = 10 -o) action to take on overflow = ignore cluster member haydn.zk3.dec.com auditd standard output: Audit data and msgs: -l) audit data destination = /var/audit/testauditlog.haydn.003 -c) audit console messages = syslog Network: -s) network audit server status (toggle) = off -t) connection timeout value (sec) = 4 Overflow control: -f) % free space before overflow condition = 10 -o) action to take on overflow = ignore
To get the each member system's audit mask status, enter the following:
#auditmask -cluster! Audited system calls: ! Audited trusted events: login fail ! Audstyle flags: exec_argp exec_envp login_uname obj_sel **** cluster member haydn.zk3.dec.com standard output: ****** ! Audited system calls: ! Audited trusted events: login fail ! Audstyle flags: exec_argp exec_envp login_uname obj_sel
To determine what log file names are the members currently logging to,
enter the following (entered from member
hayden):
#auditd -cluster -q/var/audit/auditlog.haydn.001 cluster member handel.zk3.dec.com auditd standard output: /var/audit/auditlog.handel.001
To explicitly flush all the cluster member's kernel
auditd
buffers to get the latest audit records, enter the following:
#auditd -cluster -d
To print the login event for both members to
stdout,
enter the following:
#audit_tool -e login auditlog.handel.001 auditlog.haydn.001ruid/euid: 0/0 pid: 525424 ppid: 525423 cttydev: (6,1) event: login login name: root devname: /dev/pts/1 ........... -- remote/secondary identification data -- hostname: mk.zk3.dec.com ........... char param: argv=login -h mk.zk3.dec.com -p char param: Failed authentication error: 13 ip address: 10.0.0.1 (haydn-mc0) timestamp: Mon May 3 15:54:18.19 1999 EDT ruid/euid: 0/0 pid: 525424 ppid: 525423 cttydev: (6,1) event: login login name: (nil) devname: /dev/pts/1 ........... -- remote/secondary identification data -- hostname: mk.zk3.dec.com ........... char param: argv=login -h mk.zk3.dec.com -p char param: Failed authentication error: 13 ip address: 10.0.0.1 (haydn-mc0) timestamp: Mon May 3 15:54:26.44 1999 EDT ruid/euid: 0/0 pid: 1049810 ppid: 1049809 cttydev: (6,2) event: login login name: root devname: /dev/pts/2 ........... -- remote/secondary identification data -- hostname: mk.zk3.dec.com ........... char param: argv=login -h mk.zk3.dec.com - char param: Failed authentication error: 13 ip address: 10.0.0.2 (handel-mc0) timestamp: Mon May 3 15:54:37.74 1999 EDT ruid/euid: 0/0 pid: 1049810 ppid: 1049809 cttydev: (6,2) event: login login name: (nil) devname: /dev/pts/2 ........... -- remote/secondary identification data -- hostname: mk.zk3.dec.com ........... char param: argv=login -h mk.zk3.dec.com -p char param: Failed authentication error: 13 ip address: 10.0.0.2 (handel-mc0) timestamp: Mon May 3 15:54:43.14 1999 EDT 4 records output 6 records processed#
The following restrictions apply to Tru64 UNIX Version 5.0A and TruCluster Server Version
5.0A when it is run on Tru64 UNIX Version 5.0A security.
G.5.1 Upgrades
Upgrading from base to enhanced authentication in an existing cluster
requires a full cluster reboot.
The upgrade copies user accounts from
/etc/passwd
into
/var/tcb/files/auth.db, removes
passwords from
/etc/passwd, and switches to a new security
library.
A new process authenticating a user name and password, such as a
telnet
session, uses the new library and access the new databases.
However, an existing process, such as a
dtlogin
session
or a locked CDE window, continues to use the original library.
Because this
library expects to access
/etc/passwd, from which passwords
have been removed, an existing process consistently encounters password verification
failures.
In particular, the console login window encounters this problem,
which can create the erroneous belief that the root account is disabled.
The
cluster reboot prevents this situation.
G.5.2 Terminal Logging
Under enhanced security, the system administrator can optionally enable
terminal logging.
When terminal logging is enabled, a terminal entry in the
security terminal database,
etc/auth/system/ttys.db,
is updated with log in information whenever a login occurs over it.
This logging
is controlled from an option in the
secconfig
utility,
or from the
d_skip_ttys_updates
field in the
/etc/auth/system/default
file.
This setting is ignored in cluster
members and terminal logging is not performed.