--On Monday, September 08, 2008 7:33 PM +0200 Hauke Coltzau hauke.coltzau@FernUni-Hagen.de wrote:
Hi Quanah,
thank you for your immediate reply.
(a) Which Kerberos implementation are you using? MIT Kerberos 5 as shipped with Hardy (1.6.dfsg.3~beta1-2ubuntu1)
It's likely unrelated, but I've had this problem before when the server was compiled against Heimdal's libraries, and the KDC was MIT. But I think that was very specific to Stanford's setup.
Did you make sure the GSSAPI module was installed with Cyrus-SASL? IIRC, it's a separate package under Ubuntu.
p libgssapi2-heimdal - Heimdal Kerberos - GSSAPI support library p libsasl2-modules-gssapi-heimdal - Pluggable Authentication Modules for SASL (GSSAPI) p libsasl2-modules-gssapi-mit - Cyrus SASL - pluggable authentication modules (GSSAPI)
(b) saslauthd and SASL/GSSAPI are unrelated. I.e., you don't need to be running saslauthd for SASL/GSSAPI to work. Now I'm confused. I always understood the way to use Kerberos authentication for accessing the ldap directory to be:
LDAP->SASL->Kerberos
and that I have to fill the SASL part with something real, like saslauthd. What did I miss here?
SASL/GSSAPI uses the existing Kerberos ticket to auth a user to LDAP
When using saslauthd, you do a simple bind to the LDAP server, which then connects to the KDC, gets a ticket, and auths the user.
Two very different things. I.e., the first, the user already has authed to the KDC. In the second, they haven't.
p.s.: ZCS fan here ;-)
:)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration