Merging Kerberos and LDAP protocols

News came out today that MIT launches a Kerberos-related consortium [1].

IMHO the future direction taken with Kerberos [2] should be merging the protocol with the LDAP protocol [3] (e.g. for the future LDAPv4 revision of LDAP).

As the LDAP protocol is extensible through the use of extended operations, this could be achieved by transporting Kerberos operations inside LDAP, thus preserving backward compatibility with LDAPv3. Another approach, breaking backward compatibility, would be to modify bind/unbind LDAP operations so that they would provide a Kerberos kinit/kdestroy functionality and use extended LDAP operations or define a new set of LDAP operations for the rest of Kerberos stuff.

Here's my rationale behind the merge of the two protocols: The problem with Kerberos being a distinct protocol from LDAP is that the distinction causes lots of confusion among the implementors, system architects, developers and administrators. This results in lots of cases where the two protocols are misused.

The correct distinction should be that you use Kerberos for authentication (that is, proving that a user is someone he claims to be) and LDAP for authorization (that is, given an authenticated user, determining information related to granting access to some resources - such as group memberships, possibly some application-specific ACLs etc) and for other data for which a directory is useful (hard to list all possible uses of LDAP, but e.g. mail aliases are a fine example).

But because the protocols are separate and very hard to setup together on a single authentication/authorization/directory server (or a group of servers!), people go along with only one of them, usually using LDAP for authentication instead of Kerberos (see mod_auth_ldap for Apache), effectively prohibiting themselves from implementing usable single sign-on [4] .

For an example, let's have a look at available OSS solutions. Apache Directory [5] has Kerberos and LDAP integrated from the start, but it's painfully slow [6] as a server at its current state. A mail server using LDAP for aliases can perform quite a bit of hammering on the LDAP server. MIT Kerberos [7] cannot use LDAP databases. So doesn't Shishi Kerberos [8], although they plan implementing this in the future. That leaves us with Heimdal Kerberos [9]. Heimdal requires the LDAP server to be on the same machine and support LDAPI [10] connections. So that rules out Fedora Directory Server [11], whose stable version 1.0.4 doesn't support LDAPI yet (although the CVS development version recently got LDAPI support, finally).

I've tried setting up a Heimdal Kerberos server with OpenLDAP (with SASL2 daemon in the middle), and succeeded, but it was a royal pain in the *ss.

All HOWTOs I've found on the web described a brain-dead design where Kerberos maintains a classic file-based database on its own, separate from OpenLDAP database, and one has to make sure they both are in sync (because it's possible that one can have a user that the other doesn't). In such a setup replication is really troublesome and has to be done using 2 different channels and mechanisms (e.g. LDAP syncrepl + Kerberos' own redundant servers).

I wanted an integrated design, where Heimdal stores its data directly in OpenLDAP.
This way, I couldn't possibly create a Kerberos account without an LDAP account (well, I could if I omitted Kerberos objectclass and attributes, but it would be harder to do and easier to detect). Also, I could use only LDAP's replication mechanisms and easily provide fault-tolerant cluster of LDAP and Kerberos servers.

Unfortunately, the diagram for this setup looks quite daunting for a beginner implementor, as you can see for yourself [12] .

There were also lots of gotchas:

• Heimdal can connect to LDAP as its database only using LDAPI - a networkless LDAP connection over UNIX domain socket. So you have to configure OpenLDAP in a quite non-standard way, and latest stable version of Fedora Directory Server even doesn't have such option (FDS CVS head, OTOH, got it implemented recently). Heimdal's LDAPI requirement is due to the fact that LDAPI doesn't require authentication whatsoever, so Heimdal code is simpler and you don't have to create an account in LDAP using which Heimdal could simple-bind. But the LDAPI socket is a potential security hole and has to have its UNIX permissions set tight.
• You end up with a sorta circular design [12], where Heimdal connects to OpenLDAP over LDAPI to access its database, while OpenLDAP connects to SASL2 daemon, which connects to Heimdal over Kerberos when OpenLDAP authenticates users who try to SASL-bind over LDAP protocol. When users simple-bind using LDAP, OpenLDAP does all by itself. Of course, as a result, you get separate userPassword and krb5Key attributes for each account, storing redundant authentication data that has to be kept in sync. Which brings us to the next point:
• Changing passwords so that they are in sync between LDAP and Kerberos requires building a special smbk5pwd module from contrib directory in the OpenLDAP sources, installing and configuring it. Otherwise you can end up with different passwords for authenticatng the user using Kerberos/OpenLDAP+SASL+Kerberos, and using OpenLDAP+simple bind.
• There are lots of different LDAP account management tools, and most of them don't dig Kerberos at all. Some [13] make unfounded assumptions about the setup of your directory and require their own non-typical schema and/or directory structure. You'll have most luck if you write your own account management tools.

I also had to do quite a bit of magic with options in lots of configuration files (this is on Fedora Core/RHEL):

/etc/krb5.conf
/etc/openldap/ldap.conf
/etc/openldap/slapd.conf
/etc/sysconfig/openldap
/etc/sasl2/slapd.conf
/etc/saslauthd.conf
/var/heimdal/kadmind.acl
/usr/lib64/sasl2/slapd.conf (a symlink to /etc/sasl2/slapd.conf)
/usr/lib/sasl2/slapd.conf (a symlink to /etc/sasl2/slapd.conf) 

In the end, I've got a basic working setup, but after having looked at its kludginess, decided to wait for Samba 4 (maybe I'm naive).

In summary, in order to build a basic network authentication server for single sign-on and directory services using OSS, you have to stitch together OpenLDAP and Heimdal in a very uncommon configuration, changing almost all possible options from their defaults on any major Linux/BSD distribution, having to make significant changes in all configuration files in dozens of places.
This task is beyond the patience of most persistent admins and hence most installations end up as a sort of messed-up half-cooked sorta-works solution, and you have to write your own account management software. Compared to that, MS AD has all of this functionality already set up after it has been installed. What's irritating, such functionality can be achieved with current OSS solutions, it's only a matter of overcomplex configuration.

I think that having Kerberos as an extension of LDAP protocol would force the LDAP implementors to produce solutions that have this basic functionality working out of the box (I'm meaning OpenLDAP and Fedora Directory Server) without having to spend a month constructing a monumental, fragile and possibly incorrect configuration.