Authenticate to LDAP with GSSAPI

[Isaac Boukris]

On Mon, Jun 22, 2015 at 4:05 AM, Arran Cudbard-Bell
<a.cudbardb at freeradius.org> wrote:
>
>> On 21 Jun 2015, at 21:01, Isaac Boukris <iboukris at gmail.com> wrote:
>>
>> On Mon, Jun 22, 2015 at 3:52 AM, Arran Cudbard-Bell
>> <a.cudbardb at freeradius.org> wrote:
>>>
>>>> On 21 Jun 2015, at 20:04, Isaac Boukris <iboukris at gmail.com> wrote:
>>>>
>>>> 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).
>>>
>>> Ah possibly.
>>>
>>>> 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.
>>>
>>> Nah I see the problem.
>>>
>>>> Thanks for working with me on this.
>>>
>>> No problem. Should work now (hopefully).
>>
>> One more to go :)
>
> done.
>
> Result can be null now *sigh*.

And one more assertion:

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.
radiusd: io.c:186: ber_free_buf: Assertion
`((ber)->ber_opts.lbo_valid==0x2)' failed.
Aborted (core dumped)

Thanks!