Authenticate to LDAP with GSSAPI

[Isaac Boukris]

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 :)

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.

Program received signal SIGSEGV, Segmentation fault.
0xb7773114 in rlm_ldap_result (inst=0x8277490, conn=0x82a23b0,
msgid=-1, dn=0xb777b564 "", result=0x0,
    error=0xbffff2fc, extra=0xbffff2f8) at src/modules/rlm_ldap/ldap.c:480
480             *result = NULL;
(gdb) bt
#0  0xb7773114 in rlm_ldap_result (inst=0x8277490, conn=0x82a23b0,
msgid=-1, dn=0xb777b564 "", result=0x0,
    error=0xbffff2fc, extra=0xbffff2f8) at src/modules/rlm_ldap/ldap.c:480
#1  0xb77789e4 in rlm_ldap_sasl_interactive (inst=0x8277490,
request=0x0, conn=0x82a23b0, identity=0xb777b564 "",
    password=0x0, sasl=0x82774ac, error=0xbffff2fc, extra=0xbffff2f8)
at src/modules/rlm_ldap/sasl.c:142
#2  0xb77736a0 in rlm_ldap_bind (inst=0x8277490, request=0x0,
pconn=0xbffff350, dn=0xb777b564 "", password=0x0,
    sasl=0x82774ac, retry=false) at src/modules/rlm_ldap/ldap.c:717

Perhaps I could add dbg prints.