This procedure shows how to reconfigure a slave KDC server running the Solaris 10 release to use full propagation. Normally, the procedure would only need to be used if the master KDC server is running either the Solaris 9 release or an earlier release. In this case, the master KDC server can not support incremental propagation, so the slave needs to be configured to allow propagation to work.
In this procedure, a slave KDC named kdc3 is configured. This procedure uses the following configuration parameters:
Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
Slave KDC = kdc2.example.com and kdc3.example.com
admin principal = kws/admin
Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
Adjust the URL to point to the “Graphical Kerberos Administration Tool” section, as described in the Online Help URL in the Graphical Kerberos Administration Tool.
The master KDC must be configured. For specific instructions if this slave is to be swappable, see Swapping a Master KDC and a Slave KDC.
On the master KDC, become superuser.
On the master KDC, start kadmin.
You must log in with one of the admin principal names that you created when you configured the master KDC.
kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
On the master KDC, add slave host principals to the database, if not already done.
For the slave to function, it must have a host principal. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.
kadmin: addprinc -randkey host/kdc3.example.com Principal "host/kdc3@EXAMPLE.COM" created. kadmin: |
Quit kadmin.
kadmin: quit |
On the master KDC, edit the Kerberos configuration file (krb5.conf).
You need to add an entry for each slave. See the krb5.conf(4) man page for a full description of this file.
kdc1 # cat /etc/krb5/krb5.conf . . [realms] EXAMPLE.COM = { kdc = kdc1.example.com kdc = kdc2.example.com kdc = kdc3.example.com admin_server = kdc1.example.com } |
On the master KDC, add an entry for the master KDC and each slave KDC into the kpropd.acl file.
See the kprop(1M) man page for a full description of this file.
kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.example.com@EXAMPLE.COM host/kdc2.example.com@EXAMPLE.COM host/kdc3.example.com@EXAMPLE.COM |
On all slave KDCs, copy the KDC administration files from the master KDC server.
This step needs to be followed on all slave KDCs, because the master KDC server has updated information that each KDC server needs. You can use ftp or a similar transfer mechanism to grab copies of the following files from the master KDC:
/etc/krb5/krb5.conf
/etc/krb5/kdc.conf
/etc/krb5/kpropd.acl
On all slave KDCs, make sure that the Kerberos access control list file, kadm5.acl, is not populated.
An unmodified kadm5.acl file would look like:
kdc2 # cat /etc/krb5/kadm5.acl */admin@___default_realm___ * |
If the file has kiprop entries, remove them.
On the new slave, start the kadmin command.
You must log in with one of the admin principal names that you created when you configured the master KDC.
kdc2 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
Add the slave's host principal to the slave's keytab file by using kadmin.
This entry allows kprop and other Kerberized applications to function. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.
kadmin: ktadd host/kdc3.example.com Entry for principal host/kdc3.example.com with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc3.example.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc3.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc3.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc3.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: |
Quit kadmin.
kadmin: quit |
On the master KDC, add the slave KDC name to the cron job, which automatically runs the backups, by running crontab -e.
Add the name of each slave KDC server at the end of the kprop_script line.
10 3 * * * /usr/lib/krb5/kprop_script kdc2.example.com kdc3.example.com |
You might also want to change the time of the backups. This entry starts the backup process every day at 3:10 AM.
On the new slave, start the Kerberos propagation daemon.
kdc3 # svcadm enable network/security/krb5_prop |
On the master KDC, back up and propagate the database by using kprop_script.
If a backup copy of the database is already available, it is not necessary to complete another backup. See How to Manually Propagate the Kerberos Database to the Slave KDCs for further instructions.
kdc1 # /usr/lib/krb5/kprop_script kdc3.example.com Database propagation to kdc3.example.com: SUCCEEDED |
On the new slave, create a stash file by using kdb5_util.
kdc3 # /usr/sbin/kdb5_util stash kdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key: <Type the key> |
(Optional) On the new slave KDC, synchronize the master KDCs clock by using NTP or another clock synchronization mechanism.
Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.
On the new slave, start the KDC daemon (krb5kdc).
kdc3 # svcadm enable network/security/krb5kdc |