impersonation issue, wrong principal

[Martin Gee]

OK, I believe the t_s4u program works. 
$ kinit -k host/centos.practice.com at PRACTICE.COM$ t_s4u p:user1 at PRACTICE.COM h:HTTP at test1.practice.com /etc/krb5.keytab
Proxy name: host/centos.practice.com at PRACTICE.COMTaget name: HTTP/test1.practice.com at PRACTICE.COMDelegated: user1 at PRACTICE.COMDelegated mech: { 1 2 840 113554 1 2 2 }
Ball in my court 


     On Thursday, October 8, 2015 9:33 AM, Martin Gee <geemang_2000 at yahoo.com> wrote:
   

 Thanks Greg,
Truly appreciate your help. Yes, you're correct on the 2,3 should be TGS-REQ, TGS-REP and HTTP/test1.practice.com
NOTE: I've modeled most of my code after the  t_s4u example.
* If it is a KDC under your control, what shows up in the KDC log file for this query?-- KDC: is an Active Directory, I'll work to get access to theses.
* Does the TGS-REQ have the cname-in-addl-tkt flag set in kdc-options?-- I'm assuming this is step#3 TGS-REQ. -- KDOptions: 40810000 (Forwardable, Renewable, Canonicalize)  (THIS IS FROM WIRESHARK)-- no cname-in-addl-tkt
* Does the TGS-REQ body contain a ticket in the additional-tickets field?  If so, what is in it?  -- There is NO additional ticket. 

Am I missing a flag for the init_sec_context?
Cheers,Martin



     On Thursday, October 8, 2015 8:56 AM, Greg Hudson <ghudson at mit.edu> wrote:
   

 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