Not really correct, but does give a clue to what might be going on. With your patch status wouldn't get set on the final round of SASL auth, so rlm_ldap_sasl_interactive would return the wrong ldap_rcode_t value.
Admittedly, I am not familiar enough with ldap library to be confident about my patch. It was based on gdb'ing both 'ldapsearch' and 'radiusd' and comparing the library calls as mentioned.
Sure.
rlm_ldap_result should be used to get the result via ldap_result, and check it for errors with ldap_parse_result. I can see that possibly ldap_parse_result is giving bad return codes, which is causing the loop to terminate.
Note that this is what 'ldapsearch' seem to be doing, it breaks from the loop before calling 'ldap_result()' once we aren't in 'progress', see: https://github.com/osstech-jp/openldap/blob/wiredtiger/clients/tools/common....
OK that helps. So my guess is that ldap_result will indicate that the bind was successful before ldap_sasl_interactive_bind indicates tells us that, and that on the final loop ldap_sasl_interactive_bind doesn't actually send anything to the server, it just indicates that the previous operation was successful. Slightly odd that it wouldn't set some kind of NULL/noop msgid that would indicate that, I guess that's a bug (or 'feature') of libldap. I've fudged rlm_ldap_result to take a -1 msgid, which causes it to skip attempting to retrieve the result, and just do error processing using the handle. I think that should fix everything.
I can't really claim that, that's a bug in the libldap code, because the man pages don't explicitly mention ldap_result being able to parse SASL bind results.
I'm guessing previously you were getting an error message starting with 'LDAP lib error:' could you post that to the list so we can see what ldap_parse_result was returning and determine if it was something innocuous being miscategorised as an error.
Initially there was no error at binding stage but subsequents 'search' were sent and 'clear' and were not responded by the LDAP server (unless I limit 'ssf' as mentioned).
OK.
I saw one potential issue and fixed it, so you may want to try with current v3.0.x HEAD.
Now I get similar failure to the one I got with my initial 'patch' (which I've posted two emails ago). The server hangs right after it prints "SASL data security layer installed." then it fails.
Yeah, that makes sense now... -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2