News came out today that MIT launches a Kerberos-related consortium.
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 .
For an example, let's have a look at available OSS solutions. Apache Directory has Kerberos and LDAP integrated from the start, but it's painfully slow 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 cannot use LDAP databases. So doesn't Shishi Kerberos, although they plan implementing this in the future. That leaves us with Heimdal Kerberos. Heimdal requires the LDAP server to be on the same machine and support LDAPI connections. So that rules out Fedora Directory Server, 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 .
There were also lots of gotchas:
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.