![]() ![]() ![]() |
Chapter 17: Managing Cluster Security
This chapter describes how to configure security options to protect your HACMP cluster. The chapter includes the following sections:
Overview
You can protect access to your HACMP cluster by setting up security for cluster communications between nodes. HACMP provides security for connections between nodes, with higher levels of security for inter-node communications provided through Kerberos (on SP node only) or through virtual private networks. In addition, you can configure authentication and encryption of the messages sent between nodes.
Configuring Cluster Security
HACMP secures communications between cluster nodes for HACMP operations by providing:
Connection authentication for each new connection request Connection authentication can be configured to work in conjunction with virtual private networks (VPNs).
(Optional) Message authentication (Optional) Message encryption Messages are encrypted on the sending node and decrypted on the receiving node, using a common, shared (symmetric) key.
A Cluster Communications daemon (clcomd) runs on each HACMP node to transparently manage inter-node communications for HACMP. This daemon consolidates communication mechanisms in HACMP and decreases management traffic on the network. This communication infrastructure requires only one common communication path, rather than multiple TCP connections, between each pair of nodes.
The Cluster Communications daemon logs information about all attempted connections (those accepted and those rejected) to clcomd.log. For more information about clcomd.log, see Chapter 10: Monitoring an HACMP Cluster.
Although most components communicate through the Cluster Communications daemon, the following HACMP components use a different mechanism for inter-node communications:
Component Communication Method Cluster Manager RSCT Heartbeat messaging RSCT Cluster Information Program (Clinfo) SNMP
Configuring Connection Authentication
HACMP provides two modes for connection authentication:
Standard. Standard security mode checks source IP address and port values against an access list and uses the principle of least-privileged, that is, only the minimum set of access privileges, to perform a specified task for remote command execution. Standard security is the default security mode. See the section Standard Security Mode. Kerberos. Kerberos security mode provides the features in standard security and uses Kerberos security. Kerberos security is available only for the SP. See the section Kerberos Security Mode. For added security, you can use VPN tunnels between cluster nodes. In this case, traffic for IP interfaces/addresses configured in HACMP is sent through VPN tunnels. See the section Setting Up Cluster Communications over a VPN.
Standard Security Mode
In standard security mode, HACMP authenticates requests for incoming connections by checking the following:
Source IP address Port number User privilege Remote command execution for commands in /usr/es/sbin/cluster uses the principle of least privileged. This ensures that no arbitrary command can run on a remote node with root privilege. A select set of HACMP commands are considered trusted and allowed to run as root; all other commands run as user nobody.
Since HACMP 5.1, the dependency on rsh and the ~/.rhosts file to configure host access has been eliminated. Although this file is optional, some commands external to HACMP—for example user-defined event scripts and user programs—may still require an ~/.rhosts file. HACMP now relies on an internal HACMP trusted host file, /usr/es/sbin/cluster/etc/rhosts. to authenticate HACMP communications.
Also, see Understanding the /usr/es/sbin/cluster/etc/rhosts File in Chapter 1: Administering an HACMP Cluster.
Note: The ~/.rhosts file is required for migration from HACMP or HAES 4.5 to HACMP 5.1 or later. After the migration is complete, the ~/.rhosts file should be removed if it is not required for rsh communications by other programs.
To manage inter-node communications, the Cluster Communications daemon requires a list of valid cluster IP labels or addresses to use. There are two ways to provide this information:
Automatic node configuration Individual node configuration (more secure) Note: During discovery, each node that receives a connect request checks the /usr/es/sbin/cluster/etc/rhosts file to ensure that the request is from a legitimate cluster node. The smit.log file indicates whether this file is missing or has incorrect entries.
Automatic Configuration of the /usr/es/sbin/cluster/etc/rhosts File
In general, you do not need to edit the /usr/es/sbin/cluster/etc/rhosts file unless you have specific needs or concerns. HACMP manages connections for you automatically.
If you are configuring HACMP for the first time, the /usr/es/sbin/cluster/etc/rhosts file on a node is empty. As a result, the node does not have information about the IP labels/addresses for cluster nodes. The first time that a connection is made from another node, such as for HACMP verification, HACMP accepts the connection and adds IP labels/addresses to the /usr/es/sbin/cluster/etc/rhosts file. Thereafter HACMP communicates among nodes that have IP labels/addresses listed in the /usr/es/sbin/cluster/etc/rhosts file. When you verify and synchronize the cluster, HACMP populates the ~/.rhosts file on each node with a list of valid IP labels/addresses.
Warning: If an unwelcome host requests a connection to the node prior to the first connection from another HACMP cluster node, the unwelcome host’s connection will be successful, with the host’s IP address added to the /usr/es/sbin/cluster/etc/rhosts file.
For added security, to make sure that an unwelcome host does not connect to a node between the time when you install HACMP software and the time when you initiate a connection from one cluster node to another, you can edit the /usr/es/sbin/cluster/etc/rhosts file to add one or more IP labels/addresses (that will be part of your cluster) to the file. For information about editing the /usr/es/sbin/cluster/etc/rhosts file, see the section Manually Configuring /usr/es/sbin/cluster/etc/rhosts file on Individual Nodes.
Note: The clcomd.log file logs information about all attempted connections. For information about the clcomd.log file, see Chapter 2: Using Cluster Log Files in the Troubleshooting Guide.
Manually Configuring /usr/es/sbin/cluster/etc/rhosts file on Individual Nodes
For a more secure initial configuration, you can manually configure a /usr/es/sbin/cluster/etc/rhosts file for HACMP on each node before configuration. The HACMP installation creates this empty file with read-write permissions for root only. Ensure that each IP address/label is valid for the cluster, otherwise an error is logged in smit.log and clcomd.log.
To manually set up the /usr/es/sbin/cluster/etc/rhosts file:
1. As root, open the file /usr/es/sbin/cluster/etc/rhosts on a node.
2. Edit the file to add all possible network interface IP labels or addresses for each node. Put only one IP label or address on each line. Do not add any other characters or comments.The format of this file does not allow to have comments, additional lines, or characters in it, besides the IP labels.
Disabling and Enabling the Cluster Communications Daemon
If you want to remove the reliance on the Cluster Communications daemon you can turn off the Cluster Communications daemon or rename the usr/es/sbin/cluster/etc/rhosts file.
Warning: If you disable the Cluster Communications daemon or delete the /usr/es/sbin/cluster/etc/rhosts file, programs that require inter-node communication, such as C-SPOC, cluster verification and synchronization, file collections, and message authentication and encryption will no longer function.
To stop the Cluster Communications daemon, use the following command:
If you want to make changes to the configuration for your HACMP cluster after disabling the daemon, you need to restart the Cluster Communications daemon and supply a valid rhosts file.
To start the Cluster Communications daemon, use the following command:
Troubleshooting the Cluster Communications Daemon
In some cases, if you change or remove IP addresses in the AIX 5L adapter configuration, and this takes place after the cluster has been synchronized, the Cluster Communications daemon cannot validate these addresses against the /usr/es/sbin/cluster/etc/rhosts file or against the entries in the HACMP’s Configuration Database, and HACMP issues an error.
Or, you may obtain an error during the cluster synchronization.
In this case, you must update the information that is saved in the /usr/es/sbin/cluster/etc/rhosts file on all cluster nodes, and refresh clcomd to make it aware of the changes. When you synchronize and verify the cluster again, clcomd starts using IP addresses added to HACMP Configuration Database.
To refresh the Cluster Communications daemon, use:
refresh -s clcomdES
Also, configure the /usr/es/sbin/cluster/etc/rhosts file to contain all the addresses currently used by HACMP for inter-node communication, and then copy this file to all cluster nodes.
Kerberos Security Mode
Kerberos is a network authentication protocol used on the SP. Based on a secret key encryption scheme, Kerberos offers a secure authentication mechanism for client/server applications. It centralizes command authority by using one authentication server, normally configured to be the SP control workstation.
For a more detailed explanation of Kerberos and the security features of the SP system, refer to the IBM Parallel System Support Programs for AIX 5L Administration Guide.
In addition, PSSP 3.4 and greater provides the option of running an RS/6000 SP system with an enhanced level of security, and you can use DCE authentication rather than Kerberos 4 authentication. However, these options may affect your HACMP functionality. Read the following sections before planning your cluster security.
Configuring Kerberos Security with HACMP for AIX
By setting up all network IP labels in your HACMP configuration to use Kerberos authentication, you reduce the possibility of a single point of failure. You can configure Kerberos for a cluster automatically by running a setup utility called cl_setup_kerberos. Alternatively, you can perform the process manually. Because the utility-based approach is faster and less prone to error, it is usually preferable to the manual method.
To configure Kerberos on the SPs within an HACMP cluster, perform these general steps (where needed detailed procedures appear in the following sections):
Step What you do 1 Make sure that HACMP has been properly installed on all nodes in the cluster.For information about installing HACMP, see the Installation Guide. 2 Configure HACMP cluster topology on one node in the cluster. Note that because the cl_setup_kerberos utility needs an initial Kerberized rcmd path to each node in the cluster and to the control workstation, you must include the SP Ethernet as part of the configuration.Note that the setup_authent script is usually used to configure Kerberos on the entire SP system. The setup_authent script creates rcmd (used for rsh and rcp) service principals for all network IP labels listed in the System Data Repository (SDR). The SDR does not allow multiple IP labels to be defined on the same interface. However, HACMP requires that multiple IP labels be defined for the same interface during IPAT configurations. For these reasons, each time the nodes are customized after the SP setup_authent script is run (through setup_server or alone), you must rerun the cl_setup_kerberos script or manually reconfigure the systems to use Kerberos. 3 Create new Kerberos service principals and configure all IP labels for Kerberos authentication. You can choose to perform these tasks in either of the following ways:
- Automatically—see the section Configuring Kerberos Automatically
- Manually—see the section Configuring Kerberos Manually.
4 Set the cluster security mode to Kerberos, and then synchronize the cluster. 5 Delete (or at least edit) the cl_krb_service file, which contains the Kerberos service principals password you entered during the configuration process. At the very least, you should edit this file to prevent unauthorized users from obtaining the password and possibly changing the service principals. 6 Consider removing unnecessary ~/.rhosts files. HACMP does not require the traditional TCP/IP access control lists provided by these files (but other applications might). Consult your cluster administrator before removing any version of this file.
Configuring Kerberos Automatically
The cl_setup_kerberos utility performs the following tasks:
Creates new Kerberos service principals in the Kerberos Authentication Database by copying the IP labels from the cl_krb_service file Extracts the service principals and places them in a new Kerberos services file, cl_krb-srvtab Creates a cl_klogin file that contains additional entries required by the .klogin file Updates the .klogin file on the control workstation and on all nodes in the cluster Concatenates the cl_krb-srvtab file to each node’s /etc/krb-srvtab file. Note: Make sure that you have already installed HACMP on at least one node, and that you have configured cluster topology before performing the following procedure.
To run the cl_setup_kerberos utility:
1. Verify that there is a valid /.k file on the control workstation. This file stores the Kerberos authentication password so that batched commands can be run. If the /.k file is not present, issue the following command locally on the control workstation:
/usr/lpp/ssp/kerberos/etc/kstash2. Run cl_setup_kerberos from the configured node. (This utility is found in the /usr/es/sbin/cluster/sbin directory.)
Note: You must be within the directory to run this command successfully. It is not sufficient to define the path correctly; the only way to run the cl_setup_kerberos command correctly is from within the /usr/es/sbin/cluster/sbin directory.
The cl_setup_kerberos utility extracts the HACMP IP labels from the configured node and creates a file, cl_krb_service, that contains all of the IP labels and additional format information required by the add_principal Kerberos utility. It also creates the cl_adapters file that contains a list of the IP labels required to extract the service principals from the authentication database.
3. When prompted, enter a Kerberos password for the new principals:
Password:Note: The password is added to the cl_krb_service file. This password can be the same as the Kerberos Administration Password, but it does not have to be. Follow your site’s password security procedures.
Configuring Kerberos Manually
To properly configure Kerberos on all HACMP-configured networks, perform the following steps:
Step What you do 1 Add an entry for each new Kerberos service principal to the Kerberos Authentication Database. The rcmd.localhost principal is also required. Verify that it is already present and if it is not, manually add this principal.See the section Adding New Service Principals to the Authentication Database. 2 Update the krb-srvtab file by extracting each newly added instance from the Kerberos Authentication Database.See the section Updating the krb-srvtab File. 3 Add the new service principals to each node’s /.klogin file.See the section Adding Kerberos Principals to Each Node’s .klogin File. 4 Add the new service principals to each node’s /etc/krb.realms file.See the section Adding Kerberos Principals to Each Node’s /etc/krb.realms File.
Adding New Service Principals to the Authentication Database
To add new service principals to the Kerberos Authentication Database for each network interface:
1. On the control workstation, start the kadmin utility:
kadminA welcome message appears.
2. At the admin: prompt, type the add_new_key command with the name and instance of the new principal:
admin: ank service_name.instancewhere service_name is the service (rcmd) and instance is the address label to be associated with the service. For example, using the service rcmd and address label i1_sw, the command is:
admin: ank rcmd.i1_sw3. When prompted, enter the Kerberos Administration Password.
Admin password: password4. When prompted, enter a Kerberos password for the new principal.
Password for service_name.instance: passwordNote: The password can be the same as the Kerberos Administration Password, but does not have to be. Follow your site’s password security procedures.
5. Verify that you have added the new principals to the Kerberos database:
kdb_util dump /tmp/testdbcat /tmp/testdbRemove this copy of the database when you have finished examining it:
rm /tmp/testdbUpdating the krb-srvtab File
To update the krb-srvtab file and propagate new service principals to the HACMP cluster nodes:
1. Extract each new service principal for each instance you added to the Kerberos Authentication Database for those nodes you want to update. (This operation creates a new file in the current directory for each instance extracted.)
usr/lpp/ssp/kerberos/etc/ext_srvtab -n i1_sw i1_en i1_tr2. Combine these new files generated by the ext_srvtab utility into one file called node_name-new-srvtab:
cat i1_sw-new-srvtab i1_en-new-srvtab i1_tr-new-srvtab
> node_name-new-srvtabThe new file appears in the directory where you typed the command.
Note: Shared labels (used for non-concurrent resource groups with the Online Using Node Distribution Policy startup) need to be included in every krb-srvtab file (for nodes in that resource group), so you must concatenate each shared-label srvtab file into each node_name-new-srvtab file.
3. Copy each node_name-new-srvtab file to its respective node.
4. Make a copy of the current /etc/krb-srvtab file so that it can be reused later if necessary:
cp /etc/krb-srvtab /etc/krb-srvtab-datewhere date is the date you made the copy.
5. Replace the current krb-srvtab file with the new node_name-new-srvtab file:
cp node_name-new-srvtab /etc/krb-srvtab6. Verify that the target node recognizes the new principals by issuing the following command on it:
ksrvutil listYou should see all the new principals for each network interface on that node; if not, repeat this procedure.
Adding Kerberos Principals to Each Node’s .klogin File
To add the new Kerberos principals to the /.klogin file on each HACMP cluster node:
1. Edit the /.klogin file on the control workstation to add the principals that were created for each network instance:
vi /.kloginHere is an example of the /.klogin file for two nodes, i and j. ELVIS_IMP is the name of the realm that will be used to authenticate service requests. Each node has the SP Ethernet, a Token Ring service, and an Ethernet service adapter.
root.admin@ELVIS_IMPrcmd.i1@ELVIS_IMPrcmd.i1_ensvc@ELVIS_IMPrcmd.i1_trsvc@ELVIS_IMPrcmd.j1@ELVIS_IMPrcmd.j1_ensvc@ELVIS_IMPrcmd.j1_trsvc@ELVIS_IMP2. Copy the /.klogin file from the control workstation to each node in the cluster.
To verify that you set this up correctly, issue a Kerberized rsh command on all nodes using one of the newly defined interfaces. For example:
To eliminate single points of failure, you should add Kerberos rcmd principals for every interface configured in HACMP.
Adding Kerberos Principals to Each Node’s /etc/krb.realms File
To add the new Kerberos principals to the /etc/krb.realms file on each HACMP cluster node:
1. Edit the /etc/krb.realms file on the control workstation and add the principals that were created for each network instance:
vi /etc/krb.realmsHere is an example of the krb.realms file for two nodes, i and j. ELVIS_IMP is the name of the realm that will be used to authenticate service requests. Each node has the SP Ethernet, a Token-Ring service, and an Ethernet service adapter.
root.admin ELVIS_IMPi1 ELVIS_IMPi1_ensvc ELVIS_IMPi1_trsvc ELVIS_IMPj1 ELVIS_IMPj1_ensvc ELVIS_IMPj1_trsvc ELVIS_IMPi1 ELVIS_IMPi1_ensvc ELVIS_IMPi1_trsvc ELVIS_IMPj1 ELVIS_IMPj1_ensvc ELVIS_IMPj1_trsvc ELVIS_IMP2. Copy the /etc/krb.realms file from the control workstation to each node in the cluster.
Setting the HACMP Security Mode
You can set or change the security mode on all nodes in a cluster.
To set the security mode on all nodes in a cluster to use Kerberos:
1. Enter the fastpath smitty cl_admin
2. Select HACMP Security and Users Management > Change/Show HACMP Security Mode.
3. Set the security mode to Kerberos.
4. Synchronize the cluster.
Setting Up Cluster Communications over a VPN
You can set up a VPN for HACMP inter-node communications that use the Cluster Communications daemon. In most cases, you set up security when the nodes are not publicly available.
Note: For additional security, you can set up your configuration so that RSCT and SNMP also use the VPN tunnel.
VPN support relies on the IP Security feature in AIX 5L. IP Security is separately installable and loadable. The core filesets that need to be installed are:
bos.net.ipsec.rte—The runtime environment for the kernel IP Security environment and commands
bos.msg.LANG.net.ipsec where LANG is the desired language, such as en_US
Also, the following filesets need to be installed for Internet key exchange tunnel support:
bos.net.ipsec.keymgt
bos.net.ipsec.websm
The bos.crypto fileset that is appropriate for your country
You use SMIT or the Web-based System Manager to manage a VPN. Refer to your VPN documentation for information about setting up a VPN. For more information about VPNs, go to the following URL:
http://www.ibm.com/servers/aix/products/ibmsw/security/vpn/techref/
To set up HACMP to use a VPN connection for inter-node communications through the Cluster Communications daemon:
1. Configure IP labels on each node.
2. Configure persistent IP labels on each node for use by the VPN.
For information about configuring persistent IP labels, see Chapter 3: Configuring an HACMP Cluster (Standard).
3. Synchronize the configuration.
For information about synchronizing configuration, see Chapter 7: Verifying and Synchronizing an HACMP Cluster.
Note: If the configuration for persistent IP labels is not synchronized and you configure HACMP to use persistent labels for VPN tunnels, the cluster nodes will be unable to communicate with each other.
4. On one node, configure security to use the persistent labels:
a. Enter smit hacmp
b. In SMIT, select Enhanced Configuration > Security and Users Configuration > HACMP Cluster Security > Configure Connection Authentication Mode and press Enter.
c. For Use Persistent Labels for VPN Tunnels, select Yes.
d. Synchronize the configuration.
5. In the VPN configuration for the VPN implementation that you are using, specify the port to be used for the tunnel.
By default, the port to be tunneled is 6191. To check whether the port number uses the default value, or another one, review the values in the /etc/services file.
6. It is recommended that you close the port used by the VPN tunnel on IP labels other than the persistent IP label being used by the VPN.
a. Enter smitty tcpip
b. In SMIT, select Configure IP Security, then select the appropriate option.
Configuring Message Authentication and Encryption
In addition to connection authentication, you can secure the messages sent through the Cluster Communications Daemon between cluster nodes by authenticating and encrypting those messages. You can use message encryption with message authentication, but you cannot use not message encryption alone. Message authentication and encryption are disabled by default. For information about components that do not use the Cluster Communications Daemon, see the section Configuring Cluster Security.
Both message authentication and message encryption rely on secret key technology. For authentication, the message is signed and the signature is encrypted by a key when sent, and the signature is decrypted and verified when received. For encryption, the encryption algorithm uses the key to make data unreadable. The message is encrypted when sent and decrypted when received.
Message authentication and encryption rely on Cluster Security (CtSec) Services in AIX 5L, and use the encryption keys available from Cluster Security Services. HACMP message authentication uses message digest version 5 (MD5) to create the digital signatures for the message digest. Message authentication uses the following types of keys to encrypt and decrypt signatures and messages (if selected):
Data encryption standard (DES) Triple DES Advanced encryption standard (AES). The message authentication mode is based on the encryption algorithm. Your selection of a mesage authentication mode depends on the security requirements for your HACMP cluster.
For information about network security for the AIX 5L operating system, see the following URL:
http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/security/securitytfrm.htm
Authenticating and encrypting messages increases the overhead required to process messages and may impact HACMP performance. Processing more sophisticated encryption algorithms may take more time than less complex algorithms. For example, processing AES messages may take more time than processing DES messages.
Prerequisites
The HACMP product does not include encryption libraries. Before you can use message authentication and encryption, the following AIX 5L filesets must be installed on each cluster node:
For data encryption with DES message authentication: rsct.crypt.des For data encryption standard Triple DES message authentication: rsct.crypt.3des For data encryption with Advanced Encryption Standard (AES) message authentication: rsct.crypt.aes256 You can install these filesets from the AIX 5L Expansion Pack CD-ROM.
If you install the AIX 5L encryption filesets after you have HACMP running, restart the Cluster Communications daemon to enable HACMP to use these filesets. To restart the Cluster Communications daemon:
If your configuration includes persistent labels, make sure that this configuration is synchronized before proceeding.
Warning: Do not perform other cluster configuration activities while you are configuring message authentication and encryption for a cluster. Doing so may cause communication problems between nodes. Make sure that security configuration is complete and the cluster synchronized before performing other configuration tasks.
Managing Keys
HACMP cluster security uses a shared common (symmetric) key. This means that each node must have a copy of the same key for inter-node communications to be successful. You control when keys change and how keys are distributed.
You can allow HACMP to distribute a key for you, or you can manually copy a key to each node in a cluster. Copying a key to each cluster node can provide a higher level of security than having HACMP distribute the key, depending on the method you use to copy the key to the cluster nodes.
HACMP key distribution (disabled by default) is only as secure as the network over which a key is distributed. When HACMP distributes a key to other nodes, it requires confirmation that the intent is to have HACMP distribute keys. Confirmation information appears in the clcomd.log file.
Warning: If the key is intercepted during distribution by an unwelcome party, the security of the system can be compromised.
Cluster synchronization does not update keys and does not distribute keys among nodes.
Location of Keys
On each node, a key is stored in the /usr/es/sbin/cluster/etc directory. The name of the key identifies the encryption type selected:
key_md5_des key_md5_3des key_md5_aes When to Generate and Distribute a Key
Generate and distribute a key after:
Enabling message authentication Changing the configuration for message authentication. Also, change the key in accordance with the security policies for your organization.
Note: Communication between cluster nodes requires that all nodes have active copies of the same key. You activate a new key after you distribute the key to each node in the cluster.
If you change the configuration, you may have two different keys in the /usr/es/sbin/cluster/etc directory, the active one for your configuration and the one from the previous configuration.
Note: To prevent a configuration error, delete the key that is no longer being used from each cluster node.
About Configuring Message Authentication and Encryption
How you configure message authentication and encryption depends on the method you use to distribute a key: automatically through HACMP or manually by coping a key to each cluster node.
Ensure that the message authentication and encryption configuration is consistent across cluster nodes; otherwise, HACMP cannot communicate between cluster nodes.
Configuring Message Authentication and Encryption using Automatic Key Distribution
Make sure that the cluster is synchronized before you start to configure message authentication and encryption. This ensures that cluster nodes can communicate with each other.
Step 1: Enable Automatic Key Distribution on Each Node
To make sure that you can distribute a new key through HACMP, enable Automatic Key Distribution on each node in the cluster before:
You change the message authentication mode You try to automatically distribute a key to cluster nodes. To enable key distribution on each cluster node:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Security and Users Configuration > HACMP Cluster Security > Configure Message Authentication Mode and Key Management > Enable/Disable Automatic Key Distribution and press Enter.
3. For Enable Key Distribution, select Yes.
4. Repeat step 1.through step 3. on the other nodes in the cluster.
Step 2: Enable or Change Message Authentication
You enable or change message authentication and encryption from one cluster node.
To enable or change message authentication:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Security and Users Configuration > HACMP Cluster Security > Configure Message Authentication Mode and Key Management > Configure Message Authentication Mode and press Enter.
3. Enter field values as follows:
4. Press Enter.
Step 3: Generate and Distribute a Key from One Node
If you are enabling or changing message authentication and encryption, complete this procedure on the same node where you completed Step 2: Enable or Change Message Authentication.
To generate a new key and distribute it through HACMP:
1. In SMIT, select Extended Configuration > Security and Users Configuration > HACMP Cluster Security > Configure Message Authentication Mode and Key Management > Generate/Distribute a Key and press Enter.
2. Enter field values as follows:
3. When prompted, confirm that you want HACMP to distribute a key. This information is written to the /var/hacmp/clcomd.clcomd.log file.
Note: If for some reason SMIT cannot copy the key to cluster nodes, copy the key file to diskette and copy it to the node. For information about how to manually distribute a key, see the section Step 2: Distribute a New Key by Copying It to Cluster Nodes in the section Configuring Message Authentication and Encryption using Manual Key Distribution.
Step 4: Activate the Key on Each Node
After you distribute a new key to each node in the cluster, on the node from which you distributed the key, active it for all cluster nodes. This action makes it possible for cluster nodes to communicate with each other.
To activate a new key:
1. In SMIT, select Extended Configuration > Security and Users Configuration > HACMP Cluster Security > Configure Message Authentication Mode and Key Management > Activate the New Key on All Cluster Nodes and press Enter.
2. Press Enter to activate the key on all cluster nodes.
Step 5: Synchronize the Cluster
Synchronize the cluster configuration. For information about synchronizing the cluster, see Chapter 7: Verifying and Synchronizing an HACMP Cluster.
Step 6: Disable Automatic Key Distribution on Each Node
After you distribute a key to cluster nodes through HACMP and activate the key, disable Automatic Key Distribution on each node in the cluster.
Warning: Do not leave Automatic Key Distribution enabled. Doing so might allow an unwelcome user to distribute a spurious key to cluster nodes, which would compromise cluster security.
To disable automation key distribution from each cluster node:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Security and Users Configuration > HACMP Cluster Security > Configure Message Authentication Mode and Key Management > Enable/Disable Automatic Key Distribution and press Enter.
3. For Enable Key Distribution, select No.
Configuring Message Authentication and Encryption using Manual Key Distribution
Synchronize the cluster before you start to configure message authentication and encryption. This ensures that cluster nodes can communicate with each other.
Step 1: Enable or Change Message Authentication and Encryption
You enable message authentication and encryption from one cluster node.
To enable or change message authentication:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Security and Users Configuration > HACMP Cluster Configuration > Configure Message Authentication Mode and Key Management > Configure Message Authentication Mode and press Enter.
3. Enter field values as follows:
4. Press Enter.
Step 2: Distribute a New Key by Copying It to Cluster Nodes
Ensure that you distribute the same encryption key to each cluster node; otherwise, HACMP cannot communicate between cluster nodes.
To generate a new key and copy it to other cluster nodes:
1. On the node where you want to create a key, enter smit hacmp
2. In SMIT, select Extended Configuration > Security and Users Configuration > HACMP Cluster Security > Configure Message Authentication Mode and Key Management > Generate/Distribute a Key and press Enter.
3. Enter field values as follows:
4. Copy the key file from the node where the key was generated to each node in the HACMP cluster.
On each node, a key is stored in the /usr/es/sbin/cluster/etc directory. The name of the key identifies the encryption type selected:
key_md5_des key_md5_3des key_md5_aes You can copy the file to diskette and then go to each node and copy the key file to the appropriate directory, or you can use a remote copy command such as ftp or rcp.
Note: If for some reason you cannot copy the key from one node to another using a command such as ftp or rcp, then copy the key file to diskette and copy it to the node.
Warning: A key may already be present on each node, make sure that you copy the key to each node. The new key overwrites the older one if the keys are of the same type, for example if the key is for 3DES. If the keys on the nodes do not match, HACMP does not function.
Step 3: Activate the Key on Each Node
After you distribute a new key to each node in the cluster, from one node you activate the key on all cluster nodes to make it possible for cluster nodes to communicate with each other. If you enabled or changed the message authentication mode, you should activate the key from the cluster node where you made that configuration change.
To activate a new key:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Security and Users Configuration > HACMP Cluster Security > Configure Message Authentication Mode and Key Management > Activate the New Key on All Cluster Nodes and press Enter.
3. Press Enter to activate the key on all cluster nodes.
Step 4: Synchronize the Cluster
Synchronize the cluster configuration. For information about synchronizing the cluster, see Chapter 7: Verifying and Synchronizing an HACMP Cluster.
Changing the Security Authentication Mode
The procedure for changing the message authentication mode is the same as the procedure for initially setting up message authentication and encryption for a cluster. See the previous sections:
Changing a Key
If you want to change a security key, but not change the message authentication mode:
Troubleshooting Message Authentication and Encryption
Problems using message authentication and encryption are most likely caused by configuration errors.
To remedy configuration problems:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Security and Users Configuration > HACMP Cluster Configuration > Configure Message Authentication Mode and Key Management > Configure Message Authentication Mode and press Enter.
3. In the Configure Message Authentication Mode panel, set the Message Authentication Mode to None.
4. Configure message authentication and encryption again as described in this section.
![]() ![]() ![]() |