Authenticate to LDAP with GSSAPI

[Arran Cudbard-Bell]

> On 13 Jun 2015, at 22:48, William <william at firstyear.id.au> wrote:
> 
> 
>>>>> i vote for this functionality, too.
>>>> 
>>>> You're free to write a patch and submit it.
>>> 
>>> It's already supported. I just backported it from v3.1.x as SASL
>>> non-interactive bind didn't seem to work for EXTERNAL binds (which
>>> was the main reason I added SASL bind support).
>>> 
>>> Regarding setting the keytab... no idea. How do you do it for
>>> ldapsearch?
>> 
>> Hmm, this explains the limitation:
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412017
>> 
>> Apparently it's KRB5_KTNAME, there are probably other environmental
>> variables to set other things...
>> 
> 
> You can specify it with KRB5_KTNAME if you want the LDAP library to
> actually do the ktinit and manage the ccache itself. Alternatively, you
> can do the ktinit from your own application (IE radiusd) and then
> because the ccache is already created at that point, you can then pass
> that to the ldap search routines

I guess you could call it passing... but thats a bit misleading.

Looks like it sets the KRB5CCNAME environmental variable, which then must get picked up somewhere deep and dark inside cyrus-sasl/krb5.

https://github.com/pspacek/bind-dyndb-ldap/blob/master/src/krb5_helper.c#L125

and that code is used like this:

https://github.com/pspacek/bind-dyndb-ldap/blob/master/src/ldap_helper.c#L2891
https://github.com/pspacek/bind-dyndb-ldap/blob/master/src/ldap_helper.c#L2901 <https://github.com/pspacek/bind-dyndb-ldap/blob/master/src/ldap_helper.c#L2901>

their interact function certainly doesn't do anything special:

https://github.com/pspacek/bind-dyndb-ldap/blob/master/src/ldap_helper.c#L2690 <https://github.com/pspacek/bind-dyndb-ldap/blob/master/src/ldap_helper.c#L2690>

That'd mean you could only maintain one global credential cache for the server... I guess that works, it's a bit crap, because it means the CC would be highly contended, but I don't really see security issues with it (someone feel free to correct me on that).

> So anyway, what I'm gathering from this response is:
> 
> * It's not currently supported

Well you've not really said what you're trying to do here... What's the authentication flow? You'd authenticate the users with rlm_krb5, cache the tgt, then use it to authenticate against LDAP via SASL/GSSAPI?

Currently rlm_krb5 removes the cached credentials soon after they're added. So that'd need to be altered, then we'd need to add maybe a post-auth method to remove the credentials after they'd been used with rlm_ldap. Past experience has shown that if you just let credentials build up in the CC it eventually starts having a big impact on performance.

Hopefully the krb5 MEMORY CC is threadsafe, else that'd be a complete PITA.

All the code changes would be inside rlm_krb5. Possibly:

* Have an option to set the CC for the kerberos module. If the CC is just MEMORY, then a temporary in-memory CC is created.

* Add an option to set_global_cc = <bool>, which sets KRB5CCNAME to the CC value of the module instance. if when the module instance attempts to set it, it finds an existing value, and the existing value does not match the configured value (with the exception of MEMORY prefixed CC values) the server refuses to start. CC initialisation is done if an existing CC does not exist.

* Setting the CC config item automatically disables cache removal at the end of authenticate, but enables removal in a rlm_krb5 post-auth method.

The other option is to have a global mutex, which is held during binds, and makes sure KRB5CCNAME isn't swapped out. But that's pretty nasty. No idea if it'd even work.

> * It would be nice to have

Sure, but please discuss its development if thats your intention.

-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/20150614/4c827722/attachment.sig>