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.