Valid HTML 4.01 Transitional

Kerberos Database in LDAP

James F. Carter <jimc@math.ucla.edu>, 2012-02-24

Kerberos has two major weaknesses: first, the protocol for changing the password is not standardized (similar to the case with LDAP), and second, MIT Kerberos does not have intrinsic replication to the slave servers; you need to dump the master's database (kdb5_util), copy it to the slaves (kprop), and then update them. Heimdal does have realtime replication, and so does Microsoft Windows Active Directory, but we're using MIT Kerberos. I can't do much about the password issue, but there is a possibility for replication: use LDAP.

The first challenge is to identify the name of the package. On OpenSuSE 11.4 it is krb5-plugin-kdb-ldap . It is available from the SuSE Build Service, and has also been sent out in security update campaigns. On Ubuntu it is called krb5-kdc-ldap .

Index

Web Resources

Dump Your Database

If you already have a functioning Kerberos realm, dump your database before altering your krb5.conf file, and save a copy of your database master key, whose default location is /var/lib/kerberos/krb5kdc/.k5.EXAMPLE.ORG , i.e. .k5 with the realm appended. Here is the command line to dump it. In this example, ./principal is the basename of the file-based database. You need dumps in both the default and old formats.

kdb5_util dump ./principal > db.dumpi
kdb5_util dump -ov ./principal > db.dumpiov

Beware! The dumped information is encrypted with the current database key. You must restore it to a database that uses the same key. This means that for disaster recovery you need to save the key (and other configuration information) with the dumps. Preferably everything should be encrypted with the system adminstrators' own role account key which is also recoverable in a disaster.

Specifically for this project, you are going to have to provide the plaintext master password when you create the database in LDAP. kdb5_ldap_util does not want to read it from a pre-existing stash file (despite hints in the man page that it should do so). You did save the plaintext password, didn't you? If not, it turns out to be satisfactory to just restore the master key file.

Flat File Configuration

The admin guide chapter 6 tells how to set up the OpenLDAP backend. First you need to add LDAP-specific (and not so specific) sections to krb5.conf. See section 3.3.8 and 3.3.9 for details on these parameters. I'm converting an existing fully configured Kerberos to use the LDAP backend, so I've omitted from this list the sections that have to be set up for a new realm.

You actually don't need to change anything in /var/lib/kerberos/krb5kdc/kdc.conf ; all I did was to adjust my maximum ticket life (max_life parameter). There are hints in wiki postings that some of the database-specific parameters can be in kdc.conf instead of krb5.conf.

You need to give the adminstrators permission to administrate. This is set in /var/lib/kerberos/krb5kdc/kadm5.acl . * means the principal has all permissions.

*/admin@EXAMPLE.ORG *
admin@EXAMPLE.ORG *

Setting Up LDAP and Other Infrastructure

Now that you hae your flat configuration files set up, these are the steps to set up the database:

Creating the Kerberos Database

Continuing to actually create the Kerberos database in LDAP: