Authenticate to LDAP with GSSAPI

[Arran Cudbard-Bell]

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

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20150621/21df560e/attachment.sig>