--On Thursday, September 09, 2010 08:02:54 AM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Thursday, September 09, 2010 5:13 PM +0800 Wouter van Marle wouter@squirrel-systems.com wrote:
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
Following up on Quanah's assertion that this is a client problem, you might want to help some clients pick the correct SASL mechanism when connecting to your LDAP server by restricting the mechanism list that is presented to the clients. In the default installation OpenLDAP's slapd will present all of the mechanisms that it knows about which probably includes mechanisms that you don't support. In the case of allowing only Kerberos authenticated binds you will want to restrict the mechanism list to GSSAPI.
I went back to look at where setting the mechanism list was documented and what I found was a set of internal email exchanges describing the problem. Re-reading email stream it looks like the mechanism list on Debian systems will be read from either /usr/lib/sasl2/slapd.conf or /etc/ldap/sasl2/slapd.conf. We are using a /etc/ldap/sasl2/slapd.conf that consists of:
mech_list: GSSAPI
Bill