Wow, it seems to be done ;-)
To put it in a nutshell:
- apt-get purge MIT-Kerberos*
- apt-get install Heimdal*
- tried and failed, tried and failed, ...
- apt-get purge heimdal*, cyrus*, openldap*
- apt-get libssl-dev and libdb dev packages
- got cyrus, openldap and heimdal tarballs
- configured, compiled, tested, failed, configured, compiled,
tested, failed, conf.......... ...... ......
... --- ... ... --- ...
configured, compiled, succeeded!
- Followed well known configuration instructions
ldapsearch -Y GSSAPI works
(without client verification, did not solve that yet,
server verification works fine)
login with kerberos authentication works
(with proxy ticket for the machine, this way I
avoid having PLAIN username/password send to slapd)
su, id, etc. works
Seems, as if doing it by hand is still the best way ;-)
Thanks again for your help,
----- Ursprüngliche Mail -----
Von: "Quanah Gibson-Mount" <quanah(a)zimbra.com>
An: "Hauke Coltzau" <hauke.coltzau(a)FernUni-Hagen.de>
Gesendet: Montag, 8. September 2008 21:44:16 GMT +01:00
Betreff: Re: AW: Re: AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI
(Resource temporarily unavailable))
--On Monday, September 08, 2008 9:26 PM +0200 Hauke Coltzau
ii libsasl2-modules-gssapi-mit 2.1.22.dfsg1-18ubuntu2 \\
Cyrus SASL - pluggable authentication module
I would highly recommend using Heimdal on the master side. But that's up
to you. ;)
- In the first approach, the user already has a TGT and asks the KDC
a "ldap/fqdn@REALM-ticket"? This is done by ldapsearch, not by slapd?
Hence, slapd "only" needs access to its keytab to be able to decrypt the
I believe that is correct, yes. At Stanford, I had to point slapd at the
keytab in a shell script, but I believe that was because I was using
SASL/GSSAPI to do replication as well. It's been a while. ;)
- And in the second one, the user provides username and password
slapd converts the username into a principle (user@REALM) and forwards
this to saslauthd? So this should be secured via TLS?
You can try securing it via startTLS, but nothing blocks a user from still
doing it in the clear, unfortunately (i.e., you can reject the non-secured
bind, but they'll have already sent their credentials, so anyone sniffing
would be able to get them).
There used to be a well-known howto for all this at
but the site is offline for some
This howto is completely wrong, and the various folks have asked the author
to take it down for years. I'm glad to hear it is not accessible.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration