[Date Prev][Date Next] [Chronological] [Thread] [Top]

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 Gibson-Mount
Principal Software Engineer
Zimbra, Inc
Zimbra ::  the leader in open source messaging and collaboration