After digging into this more, this definitely looks like a bug in openldap.
I modified openldap to make all mutex's recursive. Then my GSSAPI rebind proc worked properly, and the search searched all referrals and found the result (two referrals later).
Thanks, - Jeremiah
---------- Forwarded message ---------- From: Jeremiah Martell inlovewithgod@gmail.com Date: Mon, Mar 29, 2010 at 3:11 PM Subject: libldap mutex hang on ldap_int_sasl_mutex To: openldap-technical@openldap.org
I'm using openldap-2.4.18, library libldap_r.
I have three windows active directory servers setup: childA.parent.example.com parent.example.com childB.parent.example.com
I do a LDAP+GSSAPI bind to childA.parent.example.com. The bind succeeds.
I do a search that returns referrals, (I know I need to be referred to parent, and then childB in order to find my result), and I have openldap follow referrals for me.
My rebind proc is a function that only calls: ldap_sasl_interactive_bind_s( ld, NULL, NULL, NULL, NULL, LDAP_SASL_AUTOMATIC, sasl_driver, params ); where sasl_driver and params is the same parameters that I used for the initial bind call to childA.
After the seach call, the debug it looks like this:
ldap_chase_v3referrals, where ref[0] = parent.example.com
> myGSSAPIrebindProc > ldap_sasl_interactive_bind_s < ldap_sasl_interactive_bind_s < myGSSAPIrebindProc < ldap_chase_v3referrals
ldap_chase_v3referrals, where ref[0] = childB.parent.example.com
> myGSSAPIrebindProc > ldap_sasl_interactive_bind_s > ldap_chase_v3referrals, where ref[0] = childA.parent.example.com < ldap_chase_v3referrals > ldap_chase_v3referrals, where ref[0] = ForestDnsZones.parent.example.com > myGSSAPIrebindProc > ldap_sasl_interactive_bind_s ... HANG ON MUTEX
Since this is hanging on a mutex, that would suggest a code bug.
Perhaps the ldap_int_sasl_mutex needs to be a recursive mutex? Or should my rebind proc do something different than call ldap_sasl_interactive_bind_s? Any other ideas appreciated too.
Thanks, - Jeremiah