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