On Sun, Jun 21, 2015 at 10:37 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Ok, I got it to actually work (including the encryption / sealing part). Here is the working diff (LDAP_SASL_BIND_IN_PROGRESS = 14):
diff --git a/src/modules/rlm_ldap/sasl.c b/src/modules/rlm_ldap/sasl.c index 5686f2b..2d61107 100644 --- a/src/modules/rlm_ldap/sasl.c +++ b/src/modules/rlm_ldap/sasl.c @@ -125,6 +125,7 @@ ldap_rcode_t rlm_ldap_sasl_interactive(rlm_ldap_t const *inst, REQUEST *request, NULL, NULL, LDAP_SASL_AUTOMATIC, _sasl_interact, &sasl_ctx, result, &mech, &msgid); + if(ret != 14) break;
ldap_msgfree(result); /* We always need to free the old message */ if (ret >= 0) MOD_ROPTIONAL(RDEBUG3, DEBUG3, "Continuing SASL mech %s...", mech);
@@ -145,7 +146,7 @@ ldap_rcode_t rlm_ldap_sasl_interactive(rlm_ldap_t const *inst, REQUEST *request, ldap_memfree(srv_cred); } } - } while (status == LDAP_PROC_CONTINUE); + } while (ret == 14); ldap_msgfree(result);
return status;
Need some polishing etc but this works :)
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.
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....
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).
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. Pasting again: rlm_ldap: libldap vendor: OpenLDAP, version: 20440 accounting { reference = "%{tolower:type.%{Acct-Status-Type}}" } post-auth { reference = "." } rlm_ldap (ldap): Initialising connection pool pool { start = 5 min = 1 max = 1 spare = 10 uses = 0 lifetime = 0 cleanup_interval = 30 idle_timeout = 60 retry_delay = 30 spread = no } WARNING: Ignoring "start = 5", forcing to "start = 1" WARNING: Ignoring "spare = 10", forcing to "spare = 0" rlm_ldap (ldap): Opening additional connection (0), 1 of 1 pending slots used rlm_ldap (ldap): Connecting to ldap://ms.frenche.cp:389 rlm_ldap (ldap): Starting SASL mech(s): GSSAPI SASL/GSSAPI authentication started SASL username: anna@FRENCHE.CP SASL SSF: 56 SASL data security layer installed. rlm_ldap (ldap): Bind with (anonymous) to ldap://ms.frenche.cp:389 failed: Timed out while waiting for server to respond rlm_ldap (ldap): Opening connection failed (0) rlm_ldap (ldap): Removing connection pool /usr/local/etc/raddb/mods-enabled/ldap[8]: Instantiation failed for module "ldap" Regards.