Kerberos: The Definitive Guide

Adding slave KDCs

If you’re setting up a network with only one KDC, you can stop here. We’re going to continue, and create some slave KDCs that will replicate the master Kerberos database and respond to client requests.

With MIT Kerberos, slave KDCs can answer client requests by issuing tickets, but cannot perform any operations that would modify the Kerberos database (such as changing passwords). In other words, slave KDCs have a read-only copy of the Kerberos database. All updates must go through the master KDC. Updates are periodically distributed to the slave KDCs in a push model. A cron job running on the master KDC periodically sends a complete copy of the Kerberos database to the slave KDCs over an encrypted and authenticated connection.

The first step is to build the MIT Kerberos distribution on each of the slave KDCs. The same procedure detailed above in Section 4.4.1.1 should be repeated on each of your slave KDCs.

Once MIT Kerberos is installed, we can continue by extracting host keytabs for each of the slave KDCs. The Kerberos database propagation mechanism uses these keytabs to securely transfer the database between the master and slave KDCs. Log into each KDC, connect to kadmin, create a host principal for the machine, and extract the new key into the hosts’ keytab:

slave# /usr/local/sbin/kadmin Authenticating as principal jgarman/admin with password. Enter password: kadmin: addprinc -randkey host/slave.wedgie.org WARNING: no policy specified for host/[e-mail]; ...