1.1.5 - Database

This is the place where all the private keys are stored. It is very common to store all the keys in an LDAP server, even more natural when the Kerberos server is a part of an existing LDAP server, like *Apache Directory Server !

When Apache Directory Server was started, it was also thought as a repository for Kerberos keys, so we just had to develop the logic to manage those keys, and the Kerberos protocol.

In other words, you have everything embedded in a single server :

• The LDAP server to store the keys and other related information
• The Kerberos protocol
• The Authentication Server
• The Ticket Granting Server

We will focus on the database in this section.

Storage

We store everthing related to users, hosts and services in the LDAP base, as entries. In order to be able to retrieve them, we have to store them in a known place in the hierarchy. This position is fknown by the kerberos server using the Search Base DN parameter.

Everytime the Kerberos server received a request for a ticket from a principal, it will do a LDAP search starting from the Search Base DN, looking for any entry matching the filter '(krb5PrincipalName=)'. This entry should contain the Kerberos keys that will be used to generate the ticket.

One more requirement : the key as a version which allows a user to keep going with a previous key when he just changed its password (an operation that will change the Kerberos keys).

So for an LDAP entry to be seen as a valid Kerberos entry, it has to contain a Krb5PrincipalName, a Krb5Key and one more attribute, the Krb5KeyVersionNumber.

Structure

There is an existing LDAP schema to manage the keys and other information, named krb5kdc. It contains 3 ObjectClasses and 15 AttributeTypes.

All the ObjectClasses are auxilliary.

krb5Principal

This ObjectClass is used to store a Principal. It contains one mandatory AttributeType, krb5PrincipalName, and two optionnal (cn and krb5PrincipalRealm)

krb5Realm

This ObjectClass describes a Kerberos Realm. It just contains the Realm’s name (krb5RealName AttributeType).

krb5kdcEntry

This ObjectClass is used to store all the information needed to manage a Kerberos user or service. It has one mandatory AttributeType, krb5KeyVersioNumber, which is set to 0 for newly crated users or services, and incremented after each modification done on the password (which leads to the generation of new keys).

Here is a list of optional AttributeTypes the entry can have :

Sample

Here is a sample entry, which has the Krb5KdcEntry and Krb5Principal ObjectClasses set :

dn: uid=hnelson,ou=users,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: krb5principal
objectClass: krb5kdcentry
objectClass: top
uid: hnelson
userPassword: secret
krb5PrincipalName: hnelson@EXAMPLE.COM
krb5KeyVersionNumber: 0
cn: Horatio Nelson
sn: Nelson
krb5Key: '0x30 0x29 0xA0 0x03 0x02 0x01 0x12 0xA1 0x22 0x04 0x20 0x3D 0x33 0x31 0x8F 0xBE ...'
krb5Key: '0x30 0x21 0xA0 0x03 0x02 0x01 0x10 0xA1 0x1A 0x04 0x18 0x57 0x07 0xCE 0x29 0x52 ...'
krb5Key: '0x30 0x19 0xA0 0x03 0x02 0x01 0x17 0xA1 0x12 0x04 0x10 0x87 0x8D 0x80 0x14 0x60 ...'
krb5Key: '0x30 0x11 0xA0 0x03 0x02 0x01 0x03 0xA1 0x0A 0x04 0x08 0xF4 0xA7 0x13 0x64 0x8A ...'
krb5Key: '0x30 0x19 0xA0 0x03 0x02 0x01 0x11 0xA1 0x12 0x04 0x10 0xAD 0x21 0x4B 0x38 0xB6 ...'