[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Authenticate to ldap using Kerberos
On 9 Sep 10, at 21:47, Dan White wrote:
On 09/09/10 12:47 +0800, Wouter van Marle wrote:
Adding user `openldap' to group `sasl' ...
Adding user openldap to group sasl
Done.
(Did you restart slapd?)
I don't remember... restarted it many times in the process :) I'm not 
used to need to restart apps in this situation.
The issue is that the /var/run/saslauthd directory, where the
saslauthd unix socket is located, is only accessible by group 'sasl' 
(and
root).
True:
drwx--x--- 2 root       sasl       4096 2010-09-09 10:14 saslauthd
Still the same permission denied error message in syslog!
If I recall correctly, you mentioned running Postfix previously. Is it
running chrooted? Have you customized the location of your saslauthd 
mux?
Not chrooted; saslauthd mux is in the default location with proper 777 
permissions.
If so, you'll need to add:
saslauthd_path: /path/to/saslauthd
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)
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.
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.
For some reason it's still not possible for me to have slapd talk to 
pam or saslauthd for authentication.
And for some other reason the authors insist the only way to use 
kerberos authentication for slapd is gssapi.
OK well just been playing a bit with ldapsearch: it now takes 
sasl/gssapi by itself and I don't have to enter a password to get 
results out of the ldap database. So something has improved all in all:
$ ldapsearch -b 'ou=foobar,ou=addressbook,dc=squirrel'
SASL/GSSAPI authentication started
SASL username: wouter@SQUIRREL
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <ou=foobar,ou=addressbook,dc=squirrel> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 6
result: 32 No such object
matchedDN: ou=addressbook,dc=squirrel
# numResponses: 1
---------------------------------
Tls doesn't work, haven't bothered with that one too much yet.
And I still have a {CRYPT} password set for myself in the LDAP data 
base.
Interestingly according to klist I don't have a ticket, kinit doesn't 
give me a ticket, still it works.
Maybe because it's all the same computer. I have just one machine for 
server.
Wouter.
Set your saslauthd_path appropriately:
saslauthd_path: /var/run/saslauthd
(minus the /mux)
and correct any permissions problems to that directory. The mux itself
should have 777 permissions:
srwxrwxrwx 1 root root 0 2010-08-23 22:37 /var/run/saslauthd/mux
--
Dan White