S4U2self and S4U2proxy don't honor Canonicalize option
ghudson at mit.edu
Wed Mar 25 12:36:55 EDT 2015
On 03/25/2015 03:16 AM, Srinivas Cheruku wrote:
>> For S4U2Self I believe you are supposed to identify the client principal
>> name using an AS-REQ as described in [MS-S4U] section 184.108.40.206.1.1 before
>> making the S4U2Self TGS request.
> 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 :).
Hm. Looking at our code for this (which is kind of tangled), it does
appear that the only thing we really get out of this process is the
realm, so I think you are correct.
> 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?
I would suggest asking Microsoft (via dochelp at microsoft.com) if there is
a way to canonicalize the principal name during an S4U2Self request.
I'm actually a little surprised that they aren't canonicalizing during
the request, as PA-S4U-X509-USER contains a way to identify the user by
certificate without even specifying a principal name.
More information about the krbdev