[cifs-protocol] 114121712176508 MS-KILE Behaviour for client principal name in service tickets
srenaden at microsoft.com
Fri Dec 19 13:25:20 MST 2014
I will be assisting you with this issue. I have couple of questions to ensure that we both are reproducing the same issue.
On the Windows domain controller, you could open "Active Directory Users and Computers" and view the properties for account Administrator. By default, the field "User logon name" is empty. So when you say you have set the userPrinciplaName to admin at win2012r2.abartlet.wgtn.cat-it.co.nz, you have specified "admin" in the field "User logon name" and chose the FQDN win2012r2.abartlet.wgtn.cat-it.co.nz from the dropdown for domain. Correct ?
I am using kinit.exe from Java Development kit which does not support -enterprise option. I will look for an alternative that works on windows and supports the -enterprise option.
I've created a user as following on my test win2k12 R2 AD. Note that the letter J is capital letter and UPN is Jenny2 while sAMAccountName is Jenny3.
name Jennifer Klick
userPrincipalName Jenny2 at 379135DOM.lab
C:\Program Files\Java\jdk1.8.0_25\jre\bin>kinit.exe jenny2 ( here j is lower case)
New ticket is stored in cache file.
Default principal: jenny2 at 379135DOM.LAB (Just like you found, the supplied name is kept as is).
I would like to know what you will see in your environment if you were to create the same account Jennifer as described and execute the following and check the output of klist.exe. Assuming you use klist.exe to verify, if not can you use it to see if your method yields the same results seen from klist.exe ? Please let me know. Also note the case of letter J in each of the commands below
kinit -enterprise jenny2 at yourdomain
kinit -enterprise Jenny2 at yourdomain
kinit -enterprise jenny3 at yourdomain
kinit -enterprise Jenny3 at yourdomain
kinit -enterprise jenny2
kinit -enterprise Jenny3
kinit -enterprise Jenny2
kinit -enterprise Jenny3
Microsoft Windows Open Specifications
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Tuesday, December 16, 2014 10:21 PM
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