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?