[cifs-protocol] 115012912337526 Where is the link between Kerberos principals and servicePrincipalName/userPrincipalName specified?
abartlet at samba.org
Wed Feb 18 02:48:36 MST 2015
On Wed, 2015-02-18 at 04:50 +0000, Sreekanth Nadendla wrote:
> Hello Andrew, below are the answers for your questions (numbered for convenience).
> 1) A valid Server Principal Name would be samAccountName @ REALM
> 2) And for a Service it would be ServicePrinicpalName @ REALM
> 3) A valid Client Principal Name would be userPrincipalName or samAccountName at REALM
> Where are details for #1, #2, #3 ?
> 4) What specifically determines that a principal is a valid Kerberos service principal? I can't find where this is actually written down, and I'm not entirely clear what exact restriction I should implement on these mappings, if any.
> For #1 above i.e. format of "Server Principal Name" refer to MS-DISO section 18.104.22.168. Nothing new to add apart from what MIT Kerberos docs describe "Server Principal" to be.
> For #2 i.e. format of "Service Principal Name" text in MS-ADTS section 22.214.171.124.126.96.36.199 servicePrincipalName seems to answer it adequately.
> "MS-KILE section 188.8.131.52 Naming " also describes this and [SPNNAMES] reference in MS-KILE points to the following
That doesn't seem to be comprehensive, per my testing. For example, you
can ask for a service ticket to a UPN, if the server has one and you
encode the request as an enterprise principal. But you can't do it with
an AP-REQ, only a TGS-REQ (you can ask for a service ticket with an
AP-REQ to normal SPNS).
Since starting this thread, I've gone back to basics and written a
comprehensive test suite. Our new krb5.kdc smbtorture test suite covers
all manner of strange and unexpected combinations, showing the full
complexity here, or at least some part of it.
The Windows KDC isn't 'just following the spec' in a sufficiently
obvious manner as the shortness of MS-KILE would suggest. It is a very
different beast, with special/different behaviours to what I've seen
anywhere else. Those differences need to be documented, clearly and in
one place. Both the overall pattern deserves to be clearly explained so
the implementer has a reasonable expectation of being able to find the
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the cifs-protocol