Backing Up and Propagating the Kerberos Database

Propagating the Kerberos database from the master KDC to the slave KDCs is one of the most important configuration tasks. If propagation doesn't happen often enough, the master KDC and slave KDCs will become out-of-sync, so if the master KDC goes down, the slave KDCs will not have the most recent database information. Also, if a slave KDC has been configured as a master for purposes of load balancing, the clients using that slave as a master KDC will not have the latest information. Therefore, it is important to make sure the propagation occurs often enough, based on how often you change the Kerberos database.

When you configure the master KDC, you set up the kprop_script in a cron job to automatically back up the Kerberos database to the /var/krb5/slave_datatrans dump file and propagate it to the slave KDCs. But, as with any file, the Kerberos database can become corrupted. If this happens on one of the slave KDCs, you might never notice, since the next automatic propagation of the database installs a fresh copy. However, if it happens to the master KDC, the corrupted database is propagated to all of the slaves during the next propagation. And, the corrupted backup overwrites the previous uncorrupted backup file on the master KDC.

Because there is no "safe" backup copy in this scenario, you should also set up a cron job to periodically copy the slave_datatrans dump file to another location or to create another separate backup copy by using the dump command of kdb5_util. Then, if your database becomes corrupted, you can restore the most recent backup on the master KDC by using the load command of kdb5_util.

Another important note is that, because the database dump file contains principal keys, you need to protect the file from being accessed by unauthorized users (by default, the database dump file has read/write permissions only as root). This includes using only the kprop command to propagate the database dump file, which encrypts the data being transferred. Also, kprop propagates the data only to the slave KDCs, which minimizes the chance of accidentally sending the database dump to unauthorized hosts.

If the Kerberos database is updated after it has been propagated and if the database subsequently is corrupted before the next propagation, the slaves will not contain the updates: the updates will be lost. Because of this scenario, if you add significant updates to the database before a regularly scheduled propagation, you should manually propagate the database to avoid data loss.

kpropd.acl File

The kpropd.acl file on a KDC provides a list of host principal names, one per line, that specifies the systems from which the KDC can receive an updated database through the propagation mechanism. If the master KDC is used to propagate all the slave KDCs, the kpropd.acl file on each slave needs to contain only the host principal name of the master.

However, the SEAM installation and subsequent configuration steps in this guide instruct you to add the same kpropd.acl file to the master and slave KDCs. The file contains all the KDC host principal names. This configuration allows you to propagate from any KDC, in case the propagating KDCs become temporarily unavailable. And, keeping an identical copy on all KDCs makes it easy to maintain.

kprop_script Command

The kprop_script command uses the kprop command to propagate the Kerberos database to other KDCs. (If the kprop_script is run on a slave KDC, it propagates the slave's copy of the Kerberos database to other KDCs.) The kprop_script accepts a list of host names for arguments, separated by spaces, which denote the KDCs to propagate.

When the kprop_script is run, it creates a backup of the Kerberos database to the /var/krb5/slave_datatrans file and copies the file to the specified KDCs. The Kerberos database is locked until the propagation is finished.