gssapi and an expired TGT in cache
sorinm at gmail.com
Wed Mar 4 10:42:44 EST 2015
On 2015-03-03 18:05, Greg Hudson wrote:
Thank you for your very informative reply.
>> If it is not possible at GSSAPI level, how should I do it at krb5 level?
>> I have a gss_cred_id_t and I need a krb5_context, a krb5_creds, and a
>> krb5_ccache in order to execute krb5_cc_remove_cred.
> krb5_cc_remove_cred() isn't implemented for the FILE ccache type. Your
> best options for working around this are (1) to destroy the cache
> entirely, (2) to use a memory ccache, or (3) to use a client keytab.
> The third option is the best if it meets your requirements, which it
> might not.
> For the second option, you want krb5_init_context(),
> krb5_cc_new_unique(context, "MEMORY", NULL, &id),
> krb5_cc_get_full_name(), and gss_krb5_ccache_name(). To clean up you
> want krb5_cc_close() and krb5_free_context(). gss_krb5_ccache_name()
> sets a thread-specific global variable which affects future krb5 GSSAPI
> operations in that thread; you can clear it by calling it again with a
> NULL value.
Unfortunately it seems that krb5_cc_remove_cred is not implemented for
the memory cache type either.
Apparently the kcm cache type implements it. However kcm is not
available in my version of kerberos (1.12.1) and it's unlikely that the
sysadmins will backport it for the version of the linux distribution
that we have in production.
I guess I'll stick with the cache destruction method.
More information about the krbdev