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@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. > > > ANSWERS: > ========= > > For #1 above i.e. format of "Server Principal Name" refer to MS-DISO section > 7.4.5.5. 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 > 3.1.1.5.3.1.1.4 servicePrincipalName seems to answer it adequately. > > "MS-KILE section 3.1.5.11 Naming " also describes this and [SPNNAMES] > reference in MS-KILE points to the following > https://msdn.microsoft.com/en-us/library/ms677601(v=vs.85).aspx > https://msdn.microsoft.com/en-us/library/ms676921(v=vs.85).aspx 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 details. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
