[cifs-protocol] 114121712176508 MS-KILE Behaviour for client principal name in service tickets

[Sreekanth Nadendla]

Hello Andrew, please confirm the accuracy of the summary for the 3 test cases and provide the network trace for test case 3.  


My default realm is 379135DOM.LAB
sAMAccountName  is Administrator
userPrinciplaName is  admin at 379135DOM.lab

Case 1) If we are set to canonicalize, we get back the fixed UPPER case realm and the real username matching LDAP samAccountName

$ /usr/lib/klibc/bin/kinit  --enterprise admiN at 379135DOM.LAb     [canonicalization occurs with stock build of kinit with enterprise option]
Principal: Administrator at 379135DOM.LAB

enterprise-canon-samAccountName.cap shows this.


Case 2) If we are not set to canonicalize, we get back the fixed UPPER case realm, but the same username as-sent. If we ignore case, username always matches here.

$ /usr/lib/klibc/bin/kinit  admiN at 379135DOM.LAb
Principal: admiN at 379135DOM.LAB

regular-username-as-is.cap shows this.


Case 3) Using custom test suite, If we are set to enterprise but without canonicalization, we get back the whole principal as-sent. i.e. No UPPER case realm. 

i.e. something similar to the following 
$ /usr/lib/klibc/bin/kinit  --enterprise admiN at 379135DOM.lAb      [only enterprise, no canonicalization]
Principal: admiN at 379135DOM.lAb

If we ignore case, username always matches here.              
The only situation where the user name in the ticket may NOT match with the one specified in the Request is Case 1.

 

Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org] 
Sent: Sunday, January 25, 2015 9:34 PM
To: Sreekanth Nadendla
Cc: MSSolve Case Email; cifs-protocol at samba.org
Subject: Re: [cifs-protocol] 114121712176508 MS-KILE Behaviour for client principal name in service tickets

On Fri, 2015-01-16 at 20:47 +0000, Sreekanth Nadendla wrote:
> Hello Andrew,
> In my new test environment, I have Ubuntu 14.10 server added to MS Windows domain with heimdal client installed.

> If yes, then why is this a surprising result for you ? Because when we 
> are not doing canonicalization, we keep the name identical to what was 
> supplied in the command i.e. admin.

I've spent a great deal of time testing this area, and so understand it a bit better now.  I was surprised that as Microsoft Windows does realm canonicalisation unconditionally, that username canonicalisation is optional, and controlled by the clients.

I've observed that the KDC does this:

	/* 
	 * If we are set to canonicalize, we get back the fixed UPPER
	 * case realm, and the real username (ie matching LDAP
	 * samAccountName) 
	 *
	 * Otherwise, if we are set to enterprise, we
	 * get back the whole principal as-sent 
	 *
	 * Finally, if we are not set to canonicalize, we get back the
	 * fixed UPPER case realm, but the as-sent username
	 */

(getting the result for enterprise without canonicalize required hacking the protocol in our tests, as the stock krb5 libs won't send this)

This creates some interesting situations for implementers of (say) web services that attempt to accept Kerberos tickets from AD clients, as while they will 'mostly' get a kerberos principal that case-insensitively matches a samAccountName, but that sometimes does not. 

Regardless, where is this, and the mapping of possible client and server principals onto LDAP attributes documented or defined?

Thanks,

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba




-------------- next part --------------
A non-text attachment was scrubbed...
Name: regular-username-as-is.cap
Type: application/octet-stream
Size: 3371 bytes
Desc: regular-username-as-is.cap
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20150127/28798ddb/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enterprise-canon-samAccountName.cap
Type: application/octet-stream
Size: 3435 bytes
Desc: enterprise-canon-samAccountName.cap
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20150127/28798ddb/attachment-0001.obj>