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.
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=
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.
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.
This ObjectClass is used to store a Principal. It contains one mandatory AttributeType, krb5PrincipalName, and two optionnal (cn and krb5PrincipalRealm)
This ObjectClass describes a Kerberos Realm. It just contains the Realm’s name (krb5RealName AttributeType).
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 :
|krb5ValidStart||The date at which the keys are valid|
|krb5ValidEnd||The date at which the keys aren’t valid any more|
|krb5PasswordEnd||The end of password validity|
|krb5MaxLife||The maximum duration|
|krb5MaxRenew||Th maximum number of renew|
|krb5KDCFlags||The KDC flags|
|krb5Key||The generated keys|
|krb5AccountDisabled||The account has been disabled|
|krb5AccountLockedOut||The account has been locked out|
|krb5AccountExpirationTime||The account expiration time|
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 ...'