impersonation issue, wrong principal

[Greg Hudson]

On 10/08/2015 09:10 AM, Martin Gee wrote:
> Desc: I'm implementing constrained delegation. I've wiresharked what I believe is the issue.  Issue: the TGS-REP->Client Name(Principal) on gss_init_sec_context is NOT using my impersonated user cred.  I believe the problem shows itself in step #3 below where the Client Principal is using the gss_service_name NOT the gss_user_name. 
> Here is pseudo code.

Your prepared text came through with a lot of missing newlines, but I
believe I was able to more or less reconstruct the formatting.

In steps 2 and 3, your protocol traces say AS-REQ and AS-REP.  I assume
these should be TGS-REQ and TGS-REP?  There wouldn't be ticket padata in
an AS-REQ.

Likewise, I assume http/test1.practice.com is actually
HTTP/test1.practice.com?

I believe you are correct that the step 3 TGS-REP should be coming back
with a client of user1, not host/centos.practice.com, but there's not
enough information to speculate as to why.  The following might help:

* Is the KDC also running MIT krb5 1.13.2, or something else?
* If it is a KDC under your control, what shows up in the KDC log file
for this query?
* Does the TGS-REQ have the cname-in-addl-tkt flag set in kdc-options?
* Does the TGS-REQ body contain a ticket in the additional-tickets
field?  If so, what is in it?

You might also try using the t_s4u program (from src/tests/gssapi)
against your realm setup, and compare its behavior to your program's.
Our automated test case which runs t_s4u produces KDC log messages like
this for the S4U2Proxy query:

Oct 08 09:52:34 equal-rites krb5kdc[20908](info): TGS_REQ (6 etypes {18
17 16 23 25 26}) 127.0.0.1: ISSUE: authtime 1444312354, etypes {rep=17
tkt=17 ses=17}, service/1 at KRBTEST.COM for service/2 at KRBTEST.COM
Oct 08 09:52:34 equal-rites krb5kdc[20908](info): ...
CONSTRAINED-DELEGATION s4u-client=user at KRBTEST.COM