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(a)FernUni-Hagen.de&gt; An: "openldap-technical" <openldap-technical(a)openldap.org&gt; 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: <>, <> 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 --