Ticket History #6902: S4U impersonated credential KRB5_CC_NOT_FOUND

When using Active Directory you can set the lifetime for TGTs and service tickets to be different. It turns out that an impersonated TGT is subject to the service ticket lifetime setting. Gss_init_sec_context is reporting KRB5_CC_NOT_FOUND in this case. It turns out that when the in-memory version of the impersonated TGT is created by kg_compose_deleg_cred, its expiration is being set to the expiration of the original TGT used to obtain the impersonated TGT and not to the end time of the impersonated TGT. When gss_init_sec_context searches for the impersonated TGT in the cache, the search fails because it is matching on the wrong end time. This fixed it for us:

Index: src/lib/gssapi/krb5/s4u_gss_glue.c
===================================================================
--- src/lib/gssapi/krb5/s4u_gss_glue.c (revision 24877)
+++ src/lib/gssapi/krb5/s4u_gss_glue.c (working copy)
@@ -218,7 +218,7 @@
cred->usage = GSS_C_INITIATE;
cred->proxy_cred = !!(subject_creds->ticket_flags & TKT_FLG_FORWARDABLE);

- cred->tgt_expire = impersonator_cred->tgt_expire;
+ cred->tgt_expire = subject_creds->times.endtime;

code = kg_init_name(context, subject_creds->client, NULL, NULL, NULL, 0,
&cred->name);

Arlene Berry
Software Design Engineer
Likewise Software, Inc.
T 425.378.7887 x220 F 425.484.6316 E aberry@likewise.com
 

15395 SE 30th Place, Suite 140
Bellevue, WA 98007
www.likewise.com

When doing S4U2PROXY, first you get a TGT for yourself. Then you call
gss_acquire_cred_impersonate_name which gets you what it essentially a
TGT for the identity you're impersonating. It's this credential which
has an incorrect end time. Next you use this impersonated credential to
call gss_init_sec_context for the service you want to contact as the
impersonated identity and pass in the impersonated credential.
Gss_init_sec_context uses the impersonated credential to fetch a service
ticket for the service you're contacting. When it does that it has to
first find the impersonated credential in the credentials cache which
fails because the end time doesn't match. I reproduced this with some
enhanced GSS sample programs but you should be able to do it with kvno
also. I get three credentials in my cache, one which is my original
TGT, one for myself for the impersonated user, and one for the target
service for the impersonated user. Both of the credentials for the
impersonated user have the shorter lifetime and it's the second one, the
one for myself, which it fails to find in the credentials cache when
attempting to get the third one.