S4U2self and S4U2proxy don't honor Canonicalize option

[Srinivas Cheruku]

Thanks Greg. Please see my inline comments:

-----Original Message-----
From: Greg Hudson [mailto:ghudson at mit.edu] 
Sent: 24 March 2015 23:49
To: Srinivas Cheruku; 'krbdev at mit.edu'
Subject: Re: S4U2self and S4U2proxy don't honor Canonicalize option

On 03/24/2015 05:44 AM, Srinivas Cheruku wrote:
> I am sending S4U2self and S4U2proxy requests to MS AD (2003/2008/2012) 
> and found that the client name in these tickets is not canonicalized 
> even though KDC option Canonicalize is set.

> Any idea why MS AD is not canonicalizing the client name in these tickets?


I can only speculate based on the documentation, but it seems that client
name canonicalization is an AS-REQ facility, while S4U requests are
specialized TGS-REQs.
[Srinivas Cheruku] Yes, I understand S4U2self request is a TGS-REQ with
PA-FOR-USER PA-DATA containing the name of the username, realm, etc. The
S4U2self ticket returned contains the client name constructed from the
username and realm as given in the PA-FOR-USER PA-DATA e.g. username at REALM.
The username in PA-DATA may not be with the right case , e.g. username can
be SCheruku instead of scheruku  as stored in sAMAccountName attribute.

For S4U2Self I believe you are supposed to identify the client principal
name using an AS-REQ as described in [MS-S4U] section 3.1.5.1.1.1 before
making the S4U2Self TGS request.
[Srinivas Cheruku] The specified section describes how to identify the
user's realm. Unless there is a returned AS-REP to the AS-REQs sent,  I
don't think there is any way to know the canonicalized user principal name
(in correct case) using this method. As the user's password is not known,
there won't be any successful AS-REP and of course if password is known,
then there is no need of S4U :).

For S4U2Proxy you present an evidence ticket which should already have a
canonicalized client name.
[Srinivas Cheruku] The S4U2self ticket is presented to get S4U2proxy ticket
and I think if S4U2self uses the canonicalized client principal name, then
S4U2proxy will use the correct client principal name. 

[MS-S4U] https://msdn.microsoft.com/en-us/library/cc246071.aspx
[Srinivas Cheruku] Looks like there is no way to determine the canonicalized
user principal name (in correct case) when getting S4U2self ticket. As the
KDC that issues S4U2self ticket may not be same as the one where the user
principal resides, it becomes tricky to send the actual principal name to
the ticket issuing KDC. Maybe MS-PAC might contain the actual client
principal name, but the MS-PAC generated by the user's KDC may not be read
by S4U2self ticket issuing KDC.  Any ideas?