Kerberos is the authentication system, it's specialised in that. At least that's what I learned about it. I have set it up in order to have a single sign-on, a single password for all services running on my network, makes it much easier for me to administer. LDAP is a specialised database system storing typically personal information, I also use it for aliases database, userID, groupID, and other system info. This part works great as well. Now all I want is for openldap to use kerberos as its authentication broker. Nothing more, nothing less. LDAP is now authenticating its users by itself which seems to be the default behaviour, and that's what I want to get rid of. As you say yourself LDAP is not an authentication broker, but why can it not easily be configured to use an external authentication broker, such as pam, which is designed to be just that?
You are directing your unhappiness at the wrong place, as Howard already noted. As someone who set up a large OpenLDAP directory service that only allows SASL/GSSAPI connections, the issue is not OpenLDAP. The problem is client software that, even though SASL has been a standard for many, many years, still fail to properly support it. This includes things like Evolution and Postfix. I used to maintain a patch for Postfix specifically that allowed it to do SASL/GSSAPI binds.
In sum, SASL is the RFC supported mechanism to use for doing these types of binds to LDAP. It has been the RFC supported method for a very, very long time. Unfortunately, people who write LDAP client software often skip implementing SASL support. This is not the fault of the OpenLDAP or any other directory project. If you have client software that doesn't support SASL that implements LDAP v3 support, then you need to contact the authors of that software or fix it yourself.
--Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration