The following steps create the required Kerberos principals and keytab entries in the KDC database. For each cluster node, the keytab entries for which service principals are created depend on the version of Oracle Solaris that is running on the cluster node.
The principal for the nfs service over the logical hostname is created on one node only and then added manually to the default Kerberos keytab file on each cluster node. The Kerberos configuration file krb5.conf and the keytab file krb5.keytab must be stored as individual copies on each cluster node and must not be shared on a cluster file system.
Principals must be created using the fully qualified domain names.
Add these entries to the default keytab file on each node. These steps can be greatly simplified with the use of pconsole cluster console utilities. See How to Install pconsole Software on an Administrative Console in Installing and Configuring an Oracle Solaris Cluster 4.4 Environment for more information.
The following example creates the root and host entries. Perform this step on all cluster nodes, substituting the physical hostname of each cluster node for the hostname in the example.
# kadmin -p username/admin Enter Password: kadmin: addprinc -randkey host/phys-red-1.mydept.example.com Principal "host/phys-red-1.mydept.example.com@EXAMPLE.COM" created. kadmin: addprinc -randkey root/phys-red-1.mydept.example.com Principal "root/phys-red-1.mydept.example.com@EXAMPLE.COM" created. kadmin: ktadd host/phys-red-1.mydept.example.com Entry for principal host/phys-red-1.mydept.example.com with kvno 2, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: ktadd root/phys-red-1.mydept.example.com Entry for principal root/phys-red-1.mydept.example.com with kvno 2, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: quit #
Principals must be created using the fully qualified domain names. Perform this step on only one cluster node.
# kadmin -p username/admin Enter Password: kadmin: addprinc -randkey nfs/relo-red-1.mydept.example.com Principal "nfs/relo-red-1.mydept.example.com@EXAMPLE.COM" created. kadmin: ktadd -k /var/tmp/keytab.hanfs nfs/relo-red-1.mydept.example.com Entry for principal nfs/relo-red-1.mydept.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/var/tmp/keytab.hanfs. kadmin: quit #
In the above example, relo-red-1 is the logical hostname used with HA for NFS.
Do not use insecure copying methods such as regular ftp or rcp, and so forth. For additional security, you can use the cluster private interconnect to copy the database.
The following example copies the database.
# scp /var/tmp/keytab.hanfs clusternode2-priv:/var/tmp/keytab.hanfs# scp /var/tmp/keytab.hanfs clusternode3-priv:/var/tmp/keytab.hanfs
The following example uses the ktutil command to add the entry. Remove the temporary keytab file /var/tmp/keytab.hanfs on all cluster nodes after it has been added to the default keytab database /etc/krb5/krb5.keytab.
# ktutil ktutil: rkt /etc/krb5/krb5.keytab ktutil: rkt /var/tmp/keytab.hanfs ktutil: wkt /etc/krb5/krb5.keytab ktutil: quit # # rm /var/tmp/keytab.hanfs
List the default keytab entries on each cluster node and make sure that the key version number (KVNO) for the nfs service principal is the same on all cluster nodes.
# klist -k Keytab name: FILE:/etc/krb5/krb5.keytab KVNO Principal ---- --------------------------------- 2 host/phys-red-1.mydept.example.com@EXAMPLE.COM 2 root/phys-red-1.mydept.example.com@EXAMPLE.COM 3 nfs/relo-red-1.mydept.example.com@EXAMPLE.COM
On all cluster nodes, the principal for the nfs service over the logical host must have the same KVNO number. In the above example, the principal for the nfs service over the logical host is nfs/relo-red-1.mydept.example.com@EXAMPLE.COM, and the KVNO is 3.
Build the user credential database by running the following command on all cluster nodes.
# gsscred -m kerberos_v5 -a
See the gsscred(8) man page for details.
Note that the above approach builds the user credentials database only once. Some other mechanism must be employed, for example, the cron command, to keep the local copy of this database up to date with changes in the user population.