S4U2self and S4U2proxy don't honor Canonicalize option

[Srinivas Cheruku]

Hello,



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?

Is there any other option that needs to be set to get the canonicalized
client name in the S4U2self and S4U2proxy tickets?



I found an heimdal thread
http://comments.gmane.org/gmane.comp.encryption.kerberos.heimdal.general/611
1 which also talks about this issue.



Thanks,
Srini

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Srinivas Cheruku
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.

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.

For S4U2Proxy you present an evidence ticket which should already have a
canonicalized client name.

[MS-S4U] https://msdn.microsoft.com/en-us/library/cc246071.aspx
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Srinivas Cheruku]

Thanks Greg. Please see my inline comments:

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

Post by Srinivas Cheruku
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. ***@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?

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Srinivas Cheruku

Post by Greg Hudson
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.

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.

Post by 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?

I would suggest asking Microsoft (via ***@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.

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[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?

I would suggest asking Microsoft (via ***@microsoft.com) if there is a
way to canonicalize the principal name during an S4U2Self request.
[Srinivas Cheruku] Will check with Microsoft. Thank you.

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.
[Srinivas Cheruku] I haven't checked PA-S4U-X509-USER yet. I think when
using Smartcard logon certificate the Subject Alternate Name contains the
UserPrincipalName.

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev