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

--