Re: Authenticate to ldap using Kerberos

[Dan White <dwhite@olp.net>]

At this point, your issues are most likely due to your sasl configuration,
or other directory permissions problems. I don't feel that your saslauthd
permissions problem is openldap related. In this case, openldap is just
depending on libsasl to perform the authentication, and slapd is doing it's
job (which is apparent from the saslauthd permissions problem in your
logs).

(more below)

On 09/09/10 22:59 +0800, Wouter van Marle wrote:
> > What's the output of /etc/default/saslauthd (minus the comments)?
>
> START=yes
> DESC="SASL Authentication Daemon"
> NAME="saslauthd"
> MECHANISMS="pam"
> MECH_OPTIONS=""
> THREADS=5
> OPTIONS="-c -m /var/run/saslauthd"
>
> > Also, assuming IMAP is running on the same system, what's the 
> > output of:
> >
> > grep sasl /etc/imapd.conf | sed 's/^sasl_//'
>
> pwcheck_method: saslauthd pam
> auto_transition: no
> (after removing lots of comments with sasl in it)

pam is not valid. libsasl has no direct communication with pam, so that's a
dead config item (and it'll just use saslauthd in this instance).

The correct order is to have libsasl communicate with saslauthd over its
mux, and in turn saslauthd communicates with pam, which is how you have it
configured.

You probably want to have a:

sasl_mech_list: plain login gssapi external

line in /etc/imapd.conf, because clients will most likely choose the
mechanism with greatest security bits, which would be digest-md5 (even if
gssapi is offered), and digest-md5 will fail with your existing
configuration.

> > Is that substantially different from /usr/lib/sasl2/slapd.conf?
> pwcheck_method: saslauthd
> mech_list: plain login gssapi external
> keytab: /etc/ldap/ldap.keytab
>
> Most important difference is that pam is not mentioned here. But then 
> from other mails I understand that slapd only wants to use saslauthd 
> and not pam.

Right. That's because, in this particularly instance, openldap is depending
on the libsasl -> saslauthd -> pam path to authentication, which is
a reasonable approach in your scenario.

> > To trouble shoot, find out where saslauthd is listening:
> >
> > # netstat -an | grep saslauthd
> > unix  2      [ ACC ]     STREAM     LISTENING     9712 
> > /var/run/saslauthd/mux
>
> # netstat -an | grep saslauthd
> unix  2      [ ACC ]     STREAM     LISTENING     85098910 
> /var/run/saslauthd/mux
>
> Cyrus uses saslauthd at least; that is working well. And saslauthd 
> again talks to Kerberos.

I'm still not convinced you've resolved any directory permissions problems.
The reason I suggested that you restart slapd is so that it would pick up
the new group membership (for sasl).

You could shotgun it in this case, but temporarily giving very permissiable
permissions to your directory structure leading to the mux, or you could
try to give the openldap user a shell and run testsaslauthd as that user.
If you're not authenticating that way (but testsaslauthd works as root),
then you've just got a permissions problem to fix.

--
Dan White