Skip Menu |

Subject: S4U impersonated credential KRB5_CC_NOT_FOUND
Date: Thu, 14 Apr 2011 20:55:13 -0400
From: "Arlene Berry" <>
To: <>
Download (untitled) / with headers
text/plain 1.4KiB
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,

Arlene Berry
Software Design Engineer
Likewise Software, Inc.
T 425.378.7887 x220 F 425.484.6316 E

15395 SE 30th Place, Suite 140
Bellevue, WA 98007
I'm having trouble understanding this report. In the case you're seeing,
is kg_compose_deleg_cred being called from kg_impersonate_name (from
krb5_gss_acquire_cred_impersonate_name, S4U2Self) or from
create_constrained_deleg_creds in accept_sec_context?

In either event, the phrase "impersonated TGT" is confusing me further.
S4U does not create impersonated TGTs as far as I know, only impersonated
service tickets.
Date: Mon, 25 Apr 2011 13:57:14 -0400
From: "Arlene Berry" <>
To: <>
Subject: RE: [ #6902] S4U impersonated credential KRB5_CC_NOT_FOUND
Download (untitled) / with headers
text/plain 1.1KiB
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.
Subject: SVN Commit

Correctly set the expiration field of impersonated credentials in
kg_compose_deleg_cred(), so we can find them in the cache in
init_sec_context. From
Commit By: ghudson
Revision: 24900
Changed Files:
U trunk/src/lib/gssapi/krb5/s4u_gss_glue.c