gssapi and an expired TGT in cache
ghudson at mit.edu
Tue Mar 3 12:05:58 EST 2015
On 03/03/2015 10:34 AM, Sorin Manolache wrote:
> If I have a cache file and the cache contains an expired TGT then
> *) no request is made to the KDC
This looks like a bug. I will file a ticket.
> Is there a way to change this behaviour at GSSAPI level? To expose the
> krb5_ccache of a gss_cred_id_t credential? In particular I would like to
> remove the expired TGT from the cache and reexecute the
Not using generic GSSAPI functions, no.
> 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
For the first option, you want krb5_init_context(), krb5_cc_default(),
and krb5_cc_destroy(). To clean up you want krb5_free_context().
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
For the third option, you'll need to change the application to use
gss_acquire_cred() instead of gss_acquire_cred_with_password(). Create
a keytab whose first key is the desired client key, set the
KRB5_CLIENT_KTNAME environment variable to the path to that file,
possibly set KRB5CCNAME to a file which won't be disturbed by other
uses, and let the krb5 GSSAPI code manage the ccache.
Some of the features mentioned above are relatively new and might not be
available in older versions.
More information about the krbdev