gssapi and an expired TGT in cache

Sorin Manolache sorinm at
Tue Mar 3 10:34:35 EST 2015


I use the GSSAPI in order to get a TGT and then I use the TGT in order 
to get a service ticket.

The code is:

gss_cred_id_t cred;
gss_acquire_cred_with_password(&minor, name, &pwd, GSS_C_INDEFINITE, 
GSS_C_NO_OID_SET, GSS_C_INITIATE, &cred, &actual_mechs, &time_rec);

Then I pass the acquired cred to gss_init_sec_context(... cred ...).

If I have a cache file and the cache contains an expired TGT then

*) no request is made to the KDC
*) gss_acquire_cred_with_password succeeds
*) time_rec is zero after gss_acquire_cred_with_password
*) gss_init_sec_context fails with GSS_S_FAILURE and the minor code is 
KRB5KRB_AP_ERR_TKT_EXPIRED. The call chain is 

If I run kdestroy and I reexecute the code above then

*) a request is made to the KDC
*) gss_init_sec_context succeeds
*) the TGT and the service ticket are added to the cache.

Is this the intended behaviour? I thought that caches do not change the 
functionality of a program but just improve its performance.

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 

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.


More information about the krbdev mailing list