5. Kerberos Server Replication

5.1. Description of Replication

Kerberos was designed to allow for a Master/Slave replication cluster. While a Kerberos cluster can consist of any number of hosts, it is recommended that you have at least two. A master which serves as the primary server and at least one slave which is available as a backup to the master. The master and slave servers may be thought of as Primary and Secondary servers respectively.

Kerberos stores all of its information, both account and policy data, in application databases. The Kerberos software distribution includes software for replicating, or copying, this data to other servers.

Kerberos client applications are designed to attempt authentication against secondary servers if the primary master is down. Therefore you do not need to do any extra work during a system failure to fail over your Kerberos authentication service to the backup server. However, the administrative features of Kerberos do not provide for automatic failover.

In the event that your primary server fails, kadmind will be unavailable. Therefore, administrative functions will be unavailable until the primary server is restored or replace. Specifically, principal management, key creation, and key changes, cannot be done during a primary server failure.

5.2. Implementation

Server replication is handled by the kprop command. kprop must be run on the primary master KDC. It should be run in a scheduled cron job to keep the principal database in sync across all servers.

The first step in setting up replication, is to set up ACLs for kpropd. The kpropd acl filename is by default located at /var/Kerberos/krb5kdc/kpropd.acl. In our example, it would have the following contents:

host/[email protected] host/[email protected]

The kpropd.acl file should only exist on the slave Kerberos server. In Fedora derived GNU/Linux, kadmin will not run on a Kerberos server on which /var/Kerberos/krb5kdc/kpropd.acl exists.

Next you'll need to create host keys for your master and slave Kerberos servers:

{Kerberos1}bash# kadmin.local {Kerberos1}kadmin.local: addprinc -randkey host/kerberos1.gnud.ie {Kerberos1}kadmin.local: addprinc -randkey host/kerberos2.gnud.ie

The next step is to extract these keys to the keytab file. The keytab file is a keyring which contains the cryptographic keys needed to authenticate with the KDC. Extraction of keys to the keytab is done with the ktadd sub command:

{Kerberos1}kadmin.local: ktadd host/kerberos1.gnud.ie {Kerberos1}kadmin.local: ktadd host/kerberos2.gnud.ie

Finally, we want to copy the keytab over to the slave server so that it has the keys it needs available to authenticate.

{Kerberos2}bash# scp [email protected]:/etc/krb5.keytab /etc

Here is a crontab entry from the master Kerberos server used to synchronize principal databases every fifteen minutes:

15 * * * * /usr/local/bin/krb5prop.sh

Here are the contents of the krb5prop.sh script:

#!/bin/sh /usr/Kerberos/sbin/kdb5_util dump /var/Kerberos/krb5kdc/slave_datatrans /usr/Kerberos/sbin/kprop -f /var/Kerberos/krb5kdc/slave_datatrans kerberos2.gnud.ie > /dev/null

Initially running this command by hand, you should see something similar to the following:

{Kerberos1}bash# /usr/Kerberos/sbin/kdb5_util dump /var/Kerberos/krb5kdc/slave_datatrans {Kerberos1}bash# /usr/Kerberos/sbin/kprop -d -f /var/Kerberos/krb5kdc/slave_datatrans kerberos2.gnud.ie 3234 bytes sent. Database propagation to kerberos2.gnud.ie: SUCCEEDED {Kerberos1}bash#

The slave server will now synchronize its principal database with the master server.

5.3. Maintenance

With these cron jobs in place principal propagation should be sufficiently automated as to require no maintenance. At the time of a primary KDC failure, there is no need for human intervention unless the failure will last for an extended period of time.