[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))
Hi all,
I misused the term "simple bind" in my last mail, I apologize.
Obviously, I meant that SASL-binds with Kerberos do not
work.
Regards,
Hauke
----- UrsprÃngliche Mail -----
Von: "Hauke Coltzau" <hauke.coltzau@FernUni-Hagen.de>
An: "openldap-technical" <openldap-technical@openldap.org>
Gesendet: Montag, 8. September 2008 17:15:20 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien
Betreff: Simple binds with SASL/GSSAPI (Resource temporarily unavailable)
Hi all,
I have a problem to make simple binds with authentication done by kerberos5.
I use OpenLDAP to store all user account information and have
everything set up so far that users can login:
$ su - testuser
Password:
$ klist
Ticket cache: FILE:/tmp/krb5cc_2000_yukVIJ
Default principal: testuser@REALM
Valid starting Expires Service principal
09/08/08 16:54:16 09/09/08 02:54:16 krbtgt/REALM@REALM
renew until 09/09/08 16:54:16
Kerberos 4 ticket cache: /tmp/tkt2000
klist: You have no tickets cached
$ id
uid=2000(testuser) gid=2000(dusers) groups=2000(dusers)
uid, gid,etc. have been successfully taken from the
LDAP directory.
But then, ldapsearch fails:
$ ldapsearch
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
$
Details:
========
Currently, the KDC and the LDAP-Server reside on the same host,
running Ubuntu 8.04 x64_64.
I made sure that principals exist for
<fqdn>@REALM
ldap/<fqdn>@REALM
host/<fqdn>@REALM
and exported them to /etc/krb5.keytab as well as
/etc/ldap/ldap.keytab, which is now owned by the openldap user.
# ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 6 ldap/<fqdn>@REALM
2 6 ldap/<fqdn>@REALM
3 4 host/<fqdn>@REALM
4 4 host/<fqdn>@REALM
5 4 <fqdn>@REALM
6 4 <fqdn>@REALM
ktutil:
ktutil: clear
ktutil: rkt /etc/ldap/ldap.keytab
ktutil: l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 6 ldap/<fqdn>@REALM
2 6 ldap/<fqdn>@REALM
3 4 host/<fqdn>@REALM
4 4 host/<fqdn>@REALM
5 4 <fqdn>@REALM
6 4 <fqdn>@REALM
# ll /etc/ldap/ldap.keytab
-rw------- 1 openldap openldap 512 2008-09-08 15:23 /etc/ldap/ldap.keytab
(Even tried 666, but that didn't change anything. If I move this file, slapd
complains, so I'm pretty sure it's actually been used)
Next, I set
START=yes
and
MECHANISMS="kerberos5"
in /etc/default/saslauthd, started saslauthd and tested:
# testsaslauthd -u testuser -p <secret>
0: OK "Success."
As recommended, I used sasl-sample-server and /-client to test the configuration
SASSL/GSSAPI <-> Kerberos:
# sasl-sample-client -s ldap -m GSSAPI -n <fqdn> (partial output)
service=ldap
Waiting for mechanism list from server...
Forcing use of mechanism GSSAPI
Choosing best mechanism from: GSSAPI
Using mechanism GSSAPI
Preparing initial.
Sending initial response...
C: ....
...
Username: testuser@REALM
SSF: 56
Waiting for encoded message...
recieved decoded message 'srv message 1'
sending encrypted message 'client message 1'
On the sample-server side, it's the same, 'client message 1' was successfully decoded.
Next thing I did was to add following lines to /etc/ldap/slapd.conf
sasl-secprops noplain,noactive,noanonymous
sasl-regexp uid=(.*),cn=<domain>,cn=gssapi,cn=auth ldap:///dc=...??sub?uid=$1
sasl-regexp uid=(.*),cn=<domain>,cn=gssapi,cn=auth uid=$1,dc=...
and created /usr/lib/sasl2/slapd.conf
mech_list: gssapi digest-md5 cram-md5 external
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux
keytab: /etc/ldap/ldap.keytab
Then I chgrouped /var/run/saslauthd to openldap and gave g=rwx permissions to the
directory:
# ls -al /var/run/saslauthd/
total 0
drwxrwxr-x 2 root openldap 100 2008-09-08 16:36 .
drwxr-xr-x 15 root root 580 2008-09-08 12:13 ..
srwxrwxrwx 1 root root 0 2008-09-08 16:36 mux
-rw------- 1 root root 0 2008-09-08 16:36 mux.accept
-rw------- 1 root root 0 2008-09-08 16:36 saslauthd.pid.lock
But now, when trying ldapsearch on the same machine, it fails:
$ klist
Ticket cache: FILE:/tmp/krb5cc_2000_tA7220
Default principal: testuser@REALM
Valid starting Expires Service principal
09/08/08 16:33:05 09/09/08 02:33:05 krbtgt/REALM@REALM
renew until 09/09/08 16:33:05
09/08/08 16:33:46 09/09/08 02:33:05 ldap/<fqdn>@REALM
renew until 09/09/08 16:33:05
Kerberos 4 ticket cache: /tmp/tkt2000
klist: You have no tickets cached
$ ldapsearch
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
$
And on the server side:
# echo $KRB5_KTNAME
/etc/ldap/ldap.keytab
# slapd -d127 -h "ldap:///"; -u openldap -g openldap
...
>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
do_bind: dn () SASL mech GSSAPI
==> sasl_bind: dn="" mech=GSSAPI datalen=583
SASL [conn=0] Failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Resource temporarily unavailable)
send_ldap_result: conn=0 op=1 p=3
send_ldap_result: err=80 matched="" text="SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Resource temporarily unavailable)"
send_ldap_response: msgid=2 tag=97 err=80
ber_flush2: 158 bytes to sd 13
...
and saslauthd is not contacted at all:
# saslauthd -d -a kerberos5
saslauthd[7243] :main : num_procs : 5
saslauthd[7243] :main : mech_option: NULL
saslauthd[7243] :main : run_path : /var/run/saslauthd
saslauthd[7243] :main : auth_mech : kerberos5
saslauthd[7243] :ipc_init : using accept lock file: /var/run/saslauthd/mux.accept
saslauthd[7243] :detach_tty : master pid is: 0
saslauthd[7243] :ipc_init : listening on socket: /var/run/saslauthd/mux
saslauthd[7243] :main : using process model
saslauthd[7244] :get_accept_lock : acquired accept lock
saslauthd[7243] :have_baby : forked child: 7244
saslauthd[7243] :have_baby : forked child: 7245
saslauthd[7243] :have_baby : forked child: 7246
saslauthd[7243] :have_baby : forked child: 7247
<no more output>
What did I do wrong this time ;-) ?
Best regards,
Hauke
--