[cifs-protocol] [REG:114121712176508] MS-KILE Behaviour for client principal name in service tickets
vilmosf at microsoft.com
Tue Dec 16 21:50:24 MST 2014
[dochelp to Bcc, SR # to Subject]
Thank you for your question. I created the case SR 114121712176508 to track this issue with the Protocol Documentation support team. An engineer from our team will contact you soon via e-mail to begin working with you.
Vilmos Foltenyi - MSFT
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Tuesday, December 16, 2014 19:21
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org
Subject: MS-KILE Behaviour for client principal name in service tickets
I'm trying to pin down a behaviour of the Windows 2012R2 (and probably
all) AD DC, with regard to the client principal name that is encrypted into the service tickets issued to services.
While AD uses the PAC exclusivly as it's measure of identity, unix-based services typcially use the result of gss_display_name() on the client name returned from gss_accept_sec_context().
This is the client principal name encrypted into the Kerberos service ticket by the KDC, and decrypted with the service keytab entry.
I've noticed a curious number of variations in the principal name that is returned here. This concerns me, because ideally this should have consistently matched samAccountName, to allow a stable identity to be matched on the service side.
With a krb5.conf having:
default_realm = WIN2012R2.ABARTLET.WGTN.CAT-IT.CO.NZ
The administrator user has userPrincipalname of admin at w2k12.abartlet.wgtn.cat-it.co.nz
Then here are the names (cut off before the realm, which is always @WIN2012R2.ABARTLET.WGTN.CAT-IT.CO.NZ as far as I observe) the server decrypts out of the ticket, after each of these kinit commands:
kinit --enterprise admin at w2k12.abartlet.wgtn.cat-it.co.nz
kinit --enterprise administrator
kinit --enterprise ADMINISTRATOR
The point is, when a NT-Principal name is supplied by kinit, it is kept identically, however when a enterprise name is supplied, it is always overwritten with the samAccountName.
Additionally, I checked what happens if I set the userPrinciplaName to admin at win2012r2.abartlet.wgtn.cat-it.co.nz
kinit admin at WIN2012R2.ABARTLET.WGTN.CAT-IT.CO.NZ
This is a surprising result. It means that, apparently, we can not rely on the username returned from Kerberos to either case sensitivly or insensitively match the samAccountName
Can you please confirm if my understanding is correct, and where this is documented in MS-KILE, as I can't find any reference to this behaviour at all.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the cifs-protocol