Authenticate to LDAP with GSSAPI

Isaac Boukris iboukris at gmail.com
Mon Jun 22 02:04:04 CEST 2015


On Mon, Jun 22, 2015 at 2:39 AM, Arran Cudbard-Bell
<a.cudbardb at freeradius.org> wrote:
>
>>>
>>> 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.c#L1573
>
> 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.

Yea, that what it looks like, I see on the wire that the server sent
'success' but ldap_sasl_interactive_bind still returns
LDAP_SASL_BIND_IN_PROGRESS.
Perhaps it just want to be called again in order to install the
security layers (not to communicate with the server).
I tried to read some doc, it isn't clear but it could match the
behaviour we see.

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

Not yet :(
I now get (limiting 'ssf' doesn't make a diff):

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.
radiusd: error.c:255: ldap_parse_result: Assertion `r != ((void *)0)' failed.
Aborted (core dumped)

Let me know if you want the back-trace.

Thanks for working with me on this.


More information about the Freeradius-Users mailing list