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 <ghud...@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...@krbtest.com for service/2...@krbtest.com
Oct 08 09:52:34 equal-rites krb5kdc[20908](info): ...
CONSTRAINED-DELEGATION s4u-client=u...@krbtest.com
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
