Authenticate to LDAP with GSSAPI

[Arran Cudbard-Bell]

> Why not have rlm_krb5 use a seperate in-memory ccache rather than the
> same one as other users / processes?

What other processes? What other users? FreeRADIUS is a single process running under the same user. It has multiple modules, each of which may have multiple instances, with different configurations.

Yes krb5 does use a different in memory cache, in fact it uses serveral, one for each 'context'. Each MEMORY CC is only used by one thread at a time, to ensure there's no contention.

The modifications I suggested would allow krb5 to work with a single MEMORY CC, and change the lifetime of the entries, so they could be used with other modules which implemented kerberos. Currently that's probably only ldap, but it could theoretically be the rest module as well.

This would be where, for some reason, you wanted the server to have the same authorizational profile as the user connecting. The server essentially becomes the user's proxy. This is a different sort of setup to the one you're enquiring about.

> Or am I misreading.

You're misunderstanding.

There's a big long chain of libraries before we get to kerberos when using it with LDAP.

It goes: rlm_ldap -> libldap -> cyrus-sasl -> libkrb5.

Question: How do you configure the keytab in krb5 via API calls?

Answer: You don't, because the cyrus-sasl guys never exposed that functionality.

The only way to configure libkrb5 is via environmental variables.

That's how the code you posted sets its custom credential cache.

It doesn't 'pass' the CC to LDAP functions, it sets an environmental variable which libkrb5 picks up way down the line.

You can set the CC in radiusd's environment too (to a FILE, KCM or KEYRING CC for example).


> Again, I'm not using the users krb5 ccache to auth to LDAP here, I want
> a radiusd keytab to auth to ldap via gssapi.

Then the functionality exists today? Set the keytab/CC in radiusd's environment and it'll work.

There is no way to configure keytabs in FreeRADIUS on a per LDAP module instance basis. It's not a limitation of FreeRADIUS, it's a limitation of cyrus-sasl. There is no way we could add this functionality with current versions of libldap/cyrus-sasl.

If we wanted to write our own SASL implementation, we could add this functionality, but that's a hell of a lot of work, and for the vast majority of users there'd be no benefit.

> However, the ability to
> support this specific setup you mention could be useful for some other
> people no doubt.

Maybe, if other people want that, could they speak up now? Or are other people wanting the same type of authentication as the OP described?

>> 
>> Sure, but please discuss its development if thats your intention.
>> 
> 
> Sadly, my development abilities lay else where. The purpose of this
> email was to ascertain whether the functionality existed

Well, it does. Just not quite in the form you suggested it should, and again, that's not a limitation of FreeRADIUS, it's a limitation of cyrus-sasl, and IMHO not one that we should waste time addressing.

If you find the current interact function does not work for you (i.e. it's not responding correctly to one of the prompts), post the debug output, and i'll do my best to fix it.

-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/d68295aa/attachment.sig>