--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