--On Monday, September 08, 2008 7:33 PM +0200 Hauke Coltzau
<hauke.coltzau(a)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