Authenticate to LDAP with GSSAPI

Isaac Boukris iboukris at gmail.com
Sun Jun 21 22:36:36 CEST 2015


On Sun, Jun 21, 2015 at 10:37 PM, Arran Cudbard-Bell
<a.cudbardb at 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.c#L1573

> 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 at 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.


More information about the Freeradius-Users mailing list