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
--
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
--On Monday, September 08, 2008 6:10 PM +0200 Hauke Coltzau hauke.coltzau@FernUni-Hagen.de wrote:
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 -----
(a) Which Kerberos implementation are you using? (b) saslauthd and SASL/GSSAPI are unrelated. I.e., you don't need to be running saslauthd for SASL/GSSAPI to work.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Hauke Coltzau -
Quanah Gibson-Mount