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

Re: AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))

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