Authenticate to LDAP with GSSAPI

[William]

> 
> 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?

No: I would still be using LDAP for all *user* authentications, I just
want the freeradius process to bind to ldap via GSSAPI/SASL using a
service keytab rather than simple with a password.

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

Why not have rlm_krb5 use a seperate in-memory ccache rather than the
same one as other users / processes? Or am I misreading. 

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. However, the ability to
support this specific setup you mention could be useful for some other
people no doubt.

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

Sadly, my development abilities lay else where. The purpose of this
email was to ascertain whether the functionality existed, rather than
to ask for it to be developed.

Sincerely,

William
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20150614/34701b96/attachment.sig>