Hi all,
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
Voila!
ldapsearch -Y GSSAPI works
ldaps 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,
Hauke
----- Ursprüngliche Mail ----- Von: "Quanah Gibson-Mount" quanah@zimbra.com An: "Hauke Coltzau" hauke.coltzau@FernUni-Hagen.de CC: openldap-software@openldap.org Gesendet: Montag, 8. September 2008 21:44:16 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien 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 hauke.coltzau@FernUni-Hagen.de wrote:
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 for
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 clients messages?
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 (plain),
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 http://www.bayour.com/LDAPv3-HOWTO.html but the site is offline for some days now.
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.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration