thanks again for your answer.
Did you make sure the GSSAPI module was installed with Cyrus-SASL?
it's a separate package under Ubuntu.
- Heimdal Kerberos - GSSAPI support library
- Pluggable Authentication Modules for SASL (GSSAPI)
- Cyrus SASL - pluggable authentication modules (GSSAPI)
ii libsasl2-modules-gssapi-mit 2.1.22.dfsg1-18ubuntu2 \\
Cyrus SASL - pluggable authentication module
> (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:
> 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.
I see the difference, but still have
- 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,
"only" needs access to its keytab to be able to decrypt the clients messages?
- 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
secured via TLS?
I'm just looking for a setup that restricts access to LDAP to authenticated users
of course, information neccessary for authentication purposes). I need to use Kerberos
for authentication, because I want to use NFSv4.
There used to be a well-known howto for all this at
but the site is offline for some days now.
Thanks again for your help,