I'm attempting to get pass-though auth to work against saslauthd and kerberos and while the problem seems to be in sasl I think it's most likely to be seen in this type of configuration with opendap which I why I chose this mailing list.
When I run testsaslauthd it works but when I run ldapsearch it fails. But the curious thing is where it is failing. in doing straces of saslauthd and packet traces I've found that when ldapsearch calls salsauthd, and not when I run saslauthd kerberos does not deliver the AS-REP packets till just after saslauthd times out.
I can't find any difference in how I'm invoking saslauthd with testdaslauthd and how ldapsearch is invoking saslauthd. However the packet traces are quite different as you will see below.
I've seen these kind of errors here and there on google but no resolutions that I can find. (http://www.openldap.org/lists/openldap-software/200602/msg00278.html)
Centos 6 openldap-2.4.23-15.el6_1.3.x86_64 openldap-clients-2.4.23-15.el6_1.3.x86_64 openldap-servers-2.4.23-15.el6_1.3.x86_64 openldap-devel-2.4.23-15.el6_1.3.x86_64 krb5-server-1.9-9.el6_1.2.x86_64 krb5-server-ldap-1.9-9.el6_1.2.x86_64 krb5-workstation-1.9-9.el6_1.2.x86_64 krb5-libs-1.9-9.el6_1.2.x86_64 cyrus-sasl-2.1.23-8.el6.x86_64 cyrus-sasl-lib-2.1.23-8.el6.x86_64 cyrus-sasl-gssapi-2.1.23-8.el6.x86_64 cyrus-sasl-plain-2.1.23-8.el6.x86_64 cyrus-sasl-devel-2.1.23-8.el6.x86_64
My slapd.conf contains nothing regarding kerberos / sasl / pass-through authentication. I'm using a slapd.conf file for the time being till i get it all worked out and plan on converting it to a cn=config configuration.
In my DIT the userPassword field contains: {SASL}myuser@MYREALM where myuser and my realm are replaced with the proper values.
/etc/sasl2/slapd.conf: mech_list: plain pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux
/etc/sysconfig/saslauthd KRB5_KTNAME=/etc/krb5.keytab SOCKETDIR=/var/run/saslauthd MECH=kerberos5
Which builds a daemon command line of: /usr/sbin/saslauthd -m /var/run/saslauthd -a kerberos5
My system keytab is: /etc/krb5.keytab (root.ldap 0640) host/my.hostname@realm ldap/my.hostname@realm
My socket parent dir is: /var/run/saslauthd (root.ldap 0770)
When I run testsaslauthd I get a packet trace between saslauthd and kerberos is all UDP and works:
AS-REQ
< KRB5KDC_ERR_PREAUTH_REQUIRED (25)
AS-REQ
< AS-REP
TGS-REQ
< TGS-REP
When I run ldapsearch the packet trace between saslauthd and kerberos is UDP and TCP communication. None of the kerberos replies come back for 18 seconds, the time it takes saslauthd to time out.
AS-REQ
< KRB5KDC_ERR_PREAUTH_REQUIRED (25)
AS-REQ TCP SYN
< TCP SYN, ACK
TCP ACK TCP AS-REQ
< TCP ACK
AS-REQ AS-REQ TCP FIN, ACK <-- saslauthd times out and the AS-REPS all come back at once.
< AS-REP < AS-REP < AS-REP < TCP AS-REP
TCP RST
an strace of saslauthd supports this timeout theory as it shows the the timeouts and backoffs.
I can't find any info regarding saslauthd and TCP or UDP or timeouts like this. Any ideas?
I still have *exactly* the same problem (testsaslauthd works, but ldapsearch failed with a timeout of 10-15s). My OpenLDAP version is 2.4.21, I think my next step is upgrade to 2.4.28, maybe this will help, but.....
On 12/20/2011 05:08 AM, Jeff B wrote:
I'm attempting to get pass-though auth to work against saslauthd and kerberos and while the problem seems to be in sasl I think it's most likely to be seen in this type of configuration with opendap which I why I chose this mailing list.
When I run testsaslauthd it works but when I run ldapsearch it fails. But the curious thing is where it is failing. in doing straces of saslauthd and packet traces I've found that when ldapsearch calls salsauthd, and not when I run saslauthd kerberos does not deliver the AS-REP packets till just after saslauthd times out.
I can't find any difference in how I'm invoking saslauthd with testdaslauthd and how ldapsearch is invoking saslauthd. However the packet traces are quite different as you will see below.
I've seen these kind of errors here and there on google but no resolutions that I can find. (http://www.openldap.org/lists/openldap-software/200602/msg00278.html)
Centos 6 openldap-2.4.23-15.el6_1.3.x86_64 openldap-clients-2.4.23-15.el6_1.3.x86_64 openldap-servers-2.4.23-15.el6_1.3.x86_64 openldap-devel-2.4.23-15.el6_1.3.x86_64 krb5-server-1.9-9.el6_1.2.x86_64 krb5-server-ldap-1.9-9.el6_1.2.x86_64 krb5-workstation-1.9-9.el6_1.2.x86_64 krb5-libs-1.9-9.el6_1.2.x86_64 cyrus-sasl-2.1.23-8.el6.x86_64 cyrus-sasl-lib-2.1.23-8.el6.x86_64 cyrus-sasl-gssapi-2.1.23-8.el6.x86_64 cyrus-sasl-plain-2.1.23-8.el6.x86_64 cyrus-sasl-devel-2.1.23-8.el6.x86_64
My slapd.conf contains nothing regarding kerberos / sasl / pass-through authentication. I'm using a slapd.conf file for the time being till i get it all worked out and plan on converting it to a cn=config configuration.
In my DIT the userPassword field contains: {SASL}myuser@MYREALM where myuser and my realm are replaced with the proper values.
/etc/sasl2/slapd.conf: mech_list: plain pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux
/etc/sysconfig/saslauthd KRB5_KTNAME=/etc/krb5.keytab SOCKETDIR=/var/run/saslauthd MECH=kerberos5
Which builds a daemon command line of: /usr/sbin/saslauthd -m /var/run/saslauthd -a kerberos5
My system keytab is: /etc/krb5.keytab (root.ldap 0640) host/my.hostname@realm ldap/my.hostname@realm
My socket parent dir is: /var/run/saslauthd (root.ldap 0770)
When I run testsaslauthd I get a packet trace between saslauthd and kerberos is all UDP and works:
AS-REQ
< KRB5KDC_ERR_PREAUTH_REQUIRED (25)
AS-REQ
< AS-REP
TGS-REQ
< TGS-REP
When I run ldapsearch the packet trace between saslauthd and kerberos is UDP and TCP communication. None of the kerberos replies come back for 18 seconds, the time it takes saslauthd to time out.
AS-REQ
< KRB5KDC_ERR_PREAUTH_REQUIRED (25)
AS-REQ TCP SYN
< TCP SYN, ACK
TCP ACK TCP AS-REQ
< TCP ACK
AS-REQ AS-REQ TCP FIN, ACK<-- saslauthd times out and the AS-REPS all come back at once.
< AS-REP < AS-REP < AS-REP < TCP AS-REP
TCP RST
an strace of saslauthd supports this timeout theory as it shows the the timeouts and backoffs.
I can't find any info regarding saslauthd and TCP or UDP or timeouts like this. Any ideas?
In regard to: Pass-though Authentication with Saslauthd and Kerberos, Jeff...:
I'm attempting to get pass-though auth to work against saslauthd and kerberos
I have this exact configuration working, thanks in great measure to people on this list and a lot of tinkering.
I note a few differences between your config and mine; I'm not certain which, if any, of the differences are important, but I'll point them out.
Centos 6 openldap-2.4.23-15.el6_1.3.x86_64 openldap-clients-2.4.23-15.el6_1.3.x86_64 openldap-servers-2.4.23-15.el6_1.3.x86_64 openldap-devel-2.4.23-15.el6_1.3.x86_64 krb5-server-1.9-9.el6_1.2.x86_64 krb5-server-ldap-1.9-9.el6_1.2.x86_64 krb5-workstation-1.9-9.el6_1.2.x86_64 krb5-libs-1.9-9.el6_1.2.x86_64 cyrus-sasl-2.1.23-8.el6.x86_64 cyrus-sasl-lib-2.1.23-8.el6.x86_64 cyrus-sasl-gssapi-2.1.23-8.el6.x86_64 cyrus-sasl-plain-2.1.23-8.el6.x86_64 cyrus-sasl-devel-2.1.23-8.el6.x86_64
I'm using locally-built openldap RPMs on RHEL 5, and have openldap 2.4.25 installed currently.
/etc/sasl2/slapd.conf: mech_list: plain pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux
I have two differences in my /etc/sasl2/slapd.conf from yours.
1) my mech_list is
mech_list: kerberos5 external
2) I specify
sasl-host: my-ldap-server-fqdn-here
/etc/sysconfig/saslauthd KRB5_KTNAME=/etc/krb5.keytab SOCKETDIR=/var/run/saslauthd MECH=kerberos5
Mine is similar, though I'm not specifying the krb5.keytab file for saslauthd.
For as useful as SASL is, it takes a while to come up to speed on how to configure it. I wish it was as well documented as openldap is.
Tim
I have narrowed this down the problem described below to what I think is a lock in the bdb database.
Against the same slapd I have an ldapbind that is waiting from the client to complete but kerberos is trying to do an ldapmodify to the same slapd before sending the AS-REP back to LDAP Passthough kerberos client that will complete the bind.
It seems that a ldapbind in flight blocks ldapmodify, but not ldapsearches. And this configuration requires to complete an ldapmodify before it completes the bind.
So how do I get the ldapbind to not block the modify, by using more threads, or finer grained locking? I've done some searching but don't see a solution.
On Mon, Dec 19, 2011 at 11:08 PM, Jeff B jeffb.list@gmail.com wrote:
I'm attempting to get pass-though auth to work against saslauthd and kerberos and while the problem seems to be in sasl I think it's most likely to be seen in this type of configuration with opendap which I why I chose this mailing list.
When I run testsaslauthd it works but when I run ldapsearch it fails. But the curious thing is where it is failing. in doing straces of saslauthd and packet traces I've found that when ldapsearch calls salsauthd, and not when I run saslauthd kerberos does not deliver the AS-REP packets till just after saslauthd times out.
I can't find any difference in how I'm invoking saslauthd with testdaslauthd and how ldapsearch is invoking saslauthd. However the packet traces are quite different as you will see below.
I've seen these kind of errors here and there on google but no resolutions that I can find. (http://www.openldap.org/lists/openldap-software/200602/msg00278.html)
Centos 6 openldap-2.4.23-15.el6_1.3.x86_64 openldap-clients-2.4.23-15.el6_1.3.x86_64 openldap-servers-2.4.23-15.el6_1.3.x86_64 openldap-devel-2.4.23-15.el6_1.3.x86_64 krb5-server-1.9-9.el6_1.2.x86_64 krb5-server-ldap-1.9-9.el6_1.2.x86_64 krb5-workstation-1.9-9.el6_1.2.x86_64 krb5-libs-1.9-9.el6_1.2.x86_64 cyrus-sasl-2.1.23-8.el6.x86_64 cyrus-sasl-lib-2.1.23-8.el6.x86_64 cyrus-sasl-gssapi-2.1.23-8.el6.x86_64 cyrus-sasl-plain-2.1.23-8.el6.x86_64 cyrus-sasl-devel-2.1.23-8.el6.x86_64
My slapd.conf contains nothing regarding kerberos / sasl / pass-through authentication. I'm using a slapd.conf file for the time being till i get it all worked out and plan on converting it to a cn=config configuration.
In my DIT the userPassword field contains: {SASL}myuser@MYREALM where myuser and my realm are replaced with the proper values.
/etc/sasl2/slapd.conf: mech_list: plain pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux
/etc/sysconfig/saslauthd KRB5_KTNAME=/etc/krb5.keytab SOCKETDIR=/var/run/saslauthd MECH=kerberos5
Which builds a daemon command line of: /usr/sbin/saslauthd -m /var/run/saslauthd -a kerberos5
My system keytab is: /etc/krb5.keytab (root.ldap 0640) host/my.hostname@realm ldap/my.hostname@realm
My socket parent dir is: /var/run/saslauthd (root.ldap 0770)
When I run testsaslauthd I get a packet trace between saslauthd and kerberos is all UDP and works:
AS-REQ
< KRB5KDC_ERR_PREAUTH_REQUIRED (25)
AS-REQ
< AS-REP
TGS-REQ
< TGS-REP
When I run ldapsearch the packet trace between saslauthd and kerberos is UDP and TCP communication. None of the kerberos replies come back for 18 seconds, the time it takes saslauthd to time out.
AS-REQ
< KRB5KDC_ERR_PREAUTH_REQUIRED (25)
AS-REQ TCP SYN
< TCP SYN, ACK
TCP ACK TCP AS-REQ
< TCP ACK
AS-REQ AS-REQ TCP FIN, ACK <-- saslauthd times out and the AS-REPS all come back at once.
< AS-REP < AS-REP < AS-REP < TCP AS-REP
TCP RST
an strace of saslauthd supports this timeout theory as it shows the the timeouts and backoffs.
I can't find any info regarding saslauthd and TCP or UDP or timeouts like this. Any ideas?
Upon more reflection It appears to be a row locking problem in BDB. In the example where I found the SASL pass though example their kerberos principal data was not stored in the user's ldap record. and the example where you could store your kerberos principal in the same record as the user wasn't using pass though auth. Combining the two options got me here.
Now I need to find one of these options to move forward:
- Make BindRequest not lock the row. - Make the kldap backend not modify the last login data. or do it after authenticating the user thus releasing the lock.
Any thoughts?
On Thu, Jan 5, 2012 at 5:33 PM, Jeff B jeffb.list@gmail.com wrote:
I have narrowed this down the problem described below to what I think is a lock in the bdb database.
Against the same slapd I have an ldapbind that is waiting from the client to complete but kerberos is trying to do an ldapmodify to the same slapd before sending the AS-REP back to LDAP Passthough kerberos client that will complete the bind.
It seems that a ldapbind in flight blocks ldapmodify, but not ldapsearches. And this configuration requires to complete an ldapmodify before it completes the bind.
So how do I get the ldapbind to not block the modify, by using more threads, or finer grained locking? I've done some searching but don't see a solution.
On Mon, Dec 19, 2011 at 11:08 PM, Jeff B jeffb.list@gmail.com wrote:
I'm attempting to get pass-though auth to work against saslauthd and kerberos and while the problem seems to be in sasl I think it's most likely to be seen in this type of configuration with opendap which I why I chose this mailing list.
When I run testsaslauthd it works but when I run ldapsearch it fails. But the curious thing is where it is failing. in doing straces of saslauthd and packet traces I've found that when ldapsearch calls salsauthd, and not when I run saslauthd kerberos does not deliver the AS-REP packets till just after saslauthd times out.
I can't find any difference in how I'm invoking saslauthd with testdaslauthd and how ldapsearch is invoking saslauthd. However the packet traces are quite different as you will see below.
I've seen these kind of errors here and there on google but no resolutions that I can find. (http://www.openldap.org/lists/openldap-software/200602/msg00278.html)
Centos 6 openldap-2.4.23-15.el6_1.3.x86_64 openldap-clients-2.4.23-15.el6_1.3.x86_64 openldap-servers-2.4.23-15.el6_1.3.x86_64 openldap-devel-2.4.23-15.el6_1.3.x86_64 krb5-server-1.9-9.el6_1.2.x86_64 krb5-server-ldap-1.9-9.el6_1.2.x86_64 krb5-workstation-1.9-9.el6_1.2.x86_64 krb5-libs-1.9-9.el6_1.2.x86_64 cyrus-sasl-2.1.23-8.el6.x86_64 cyrus-sasl-lib-2.1.23-8.el6.x86_64 cyrus-sasl-gssapi-2.1.23-8.el6.x86_64 cyrus-sasl-plain-2.1.23-8.el6.x86_64 cyrus-sasl-devel-2.1.23-8.el6.x86_64
My slapd.conf contains nothing regarding kerberos / sasl / pass-through authentication. I'm using a slapd.conf file for the time being till i get it all worked out and plan on converting it to a cn=config configuration.
In my DIT the userPassword field contains: {SASL}myuser@MYREALM where myuser and my realm are replaced with the proper values.
/etc/sasl2/slapd.conf: mech_list: plain pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux
/etc/sysconfig/saslauthd KRB5_KTNAME=/etc/krb5.keytab SOCKETDIR=/var/run/saslauthd MECH=kerberos5
Which builds a daemon command line of: /usr/sbin/saslauthd -m /var/run/saslauthd -a kerberos5
My system keytab is: /etc/krb5.keytab (root.ldap 0640) host/my.hostname@realm ldap/my.hostname@realm
My socket parent dir is: /var/run/saslauthd (root.ldap 0770)
When I run testsaslauthd I get a packet trace between saslauthd and kerberos is all UDP and works:
AS-REQ
< KRB5KDC_ERR_PREAUTH_REQUIRED (25)
AS-REQ
< AS-REP
TGS-REQ
< TGS-REP
When I run ldapsearch the packet trace between saslauthd and kerberos is UDP and TCP communication. None of the kerberos replies come back for 18 seconds, the time it takes saslauthd to time out.
AS-REQ
< KRB5KDC_ERR_PREAUTH_REQUIRED (25)
AS-REQ TCP SYN
< TCP SYN, ACK
TCP ACK TCP AS-REQ
< TCP ACK
AS-REQ AS-REQ TCP FIN, ACK <-- saslauthd times out and the AS-REPS all come back at once.
< AS-REP < AS-REP < AS-REP < TCP AS-REP
TCP RST
an strace of saslauthd supports this timeout theory as it shows the the timeouts and backoffs.
I can't find any info regarding saslauthd and TCP or UDP or timeouts like this. Any ideas?
On 2012-01-06 22:10, Jeff B wrote:
Upon more reflection It appears to be a row locking problem in BDB. In the example where I found the SASL pass though example their kerberos principal data was not stored in the user's ldap record. and the example where you could store your kerberos principal in the same record as the user wasn't using pass though auth. Combining the two options got me here.
Thank you for your analysis, it is much appreciated. I was having the exact same problems (modulo some DNS-related fubar) and could not, for the life of me, figure out why.
Very curiously, running a successful testsaslauthd against the LDAP service and *then* running ldapwhoami from a client machine works. But only after that successful testsaslauthd on the server. Restart saslauthd on the server and the problem reoccurs, until the new successful testsaslauthd run. O_o
For what it's worth, I can confirm that this problem only occurs whith the kdb5-ldap backend when the Kerberos principal is stored in the same DN as the user, i.e. using
addprinc -x dn="uid=foo,ou=people,dc=example,dc=com" foo
to create the principal. Separating the principal data from the user's DN makes SASL pass-through authentication work again.
Andreas
On 09.01.2012 19:38, Andreas Ntaflos wrote:
On 2012-01-06 22:10, Jeff B wrote:
Upon more reflection It appears to be a row locking problem in BDB. In the example where I found the SASL pass though example their kerberos principal data was not stored in the user's ldap record. and the example where you could store your kerberos principal in the same record as the user wasn't using pass though auth. Combining the two options got me here.
Thank you for your analysis, it is much appreciated. I was having the exact same problems (modulo some DNS-related fubar) and could not, for the life of me, figure out why.
Very curiously, running a successful testsaslauthd against the LDAP service and *then* running ldapwhoami from a client machine works. But only after that successful testsaslauthd on the server. Restart saslauthd on the server and the problem reoccurs, until the new successful testsaslauthd run. O_o
For what it's worth, I can confirm that this problem only occurs whith the kdb5-ldap backend when the Kerberos principal is stored in the same DN as the user, i.e. using
addprinc -x dn="uid=foo,ou=people,dc=example,dc=com" foo
to create the principal. Separating the principal data from the user's DN makes SASL pass-through authentication work again.
Andreas
Yes thanks!, that's also my problem I wrote one/two months ago...
Is this a known bug or is there no other way to fix it?
On Mon Jan 09 2012 at 19:38:05 CET, Andreas Ntaflos wrote:
On 2012-01-06 22:10, Jeff B wrote:
Upon more reflection It appears to be a row locking problem in BDB. In the example where I found the SASL pass though example their kerberos principal data was not stored in the user's ldap record. and the example where you could store your kerberos principal in the same record as the user wasn't using pass though auth. Combining the two options got me here.
For what it's worth, I can confirm that this problem only occurs whith the kdb5-ldap backend when the Kerberos principal is stored in the same DN as the user, i.e. using
addprinc -x dn="uid=foo,ou=people,dc=example,dc=com" foo
to create the principal. Separating the principal data from the user's DN makes SASL pass-through authentication work again.
I'm running OpenLDAP 2.4.31 in Multi-Master Replication mode with BDB 4.7.25.NC (with 4 patches) and am experiencing the same issue. (Have tried with BDB 5.1.29 which doesn't change anything.) I have one slapd running on Centos 6.2 (2.6.32-220.13.1.el6.x86_64 SMP x86_64) and the other on OS/X 10.6.8. Kerberos is MIT krb5-1.10.1 on both.
If I launch saslsauthd with a KRB5_CONFIG pointing to a second KDC which access a slapd mirror, all works fine.
When both KDC (with kldap back-end) and slapd run on the same machine, and krb5.conf points to that KDC, saslauthd fails if the Kerberos principal objects are in the user's DN:
# /usr/sbin/saslauthd -d -a kerberos5 -m /var/run/openldap
saslauthd[96294] :main : num_procs : 5 saslauthd[96294] :main : mech_option: NULL saslauthd[96294] :main : run_path : /var/run/openldap saslauthd[96294] :main : auth_mech : kerberos5 saslauthd[96294] :ipc_init : using accept lock file: /var/run/openldap/mux.accept saslauthd[96294] :detach_tty : master pid is: 0 saslauthd[96294] :ipc_init : listening on socket: /var/run/openldap/mux saslauthd[96294] :main : using process model saslauthd[96294] :have_baby : forked child: 96295 saslauthd[96294] :have_baby : forked child: 96296 saslauthd[96295] :get_accept_lock : acquired accept lock saslauthd[96294] :have_baby : forked child: 96297 saslauthd[96294] :have_baby : forked child: 96298
saslauthd[96295] :rel_accept_lock : released accept lock saslauthd[96297] :get_accept_lock : acquired accept lock saslauthd[96295] :do_auth : auth failure: [user=jpm] [service=ldap] [realm=MENS.DE] [mech=kerberos5] [reason=saslauthd internal error]
If, on the other hand, the kerberos principal data in LDAP is separate from the user's entry, authentication works:
saslauthd[96298] :rel_accept_lock : released accept lock saslauthd[96294] :get_accept_lock : acquired accept lock saslauthd[96298] :do_auth : auth success: [user=f5] [service=ldap] [realm=MENS.DE] [mech=kerberos5] saslauthd[96298] :do_request : response: OK
Has anybody found a solution? I want to keep Kerberos principal data in the users' entries.
-JP
openldap-technical@openldap.org
-
Andreas Ntaflos -
Jan-Piet Mens -
Jeff B -
Raffael Sahli -
Tim Mooney