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

[Sreekanth Nadendla]

Hello Andrew, Our product team finds that no explicit change to our documents is needed. Below is the summary of explanation 
covering the 3 scenarios we have been investigating.


1.)	When canonicalization is NOT asked for, the Cname in the KDC reply is identical to the Cname that was sent in the request.  This is exactly RFC behavior, so MS-KILE doesn’t need to describe this separately.

2.)	When canonicalization is asked for, the Cname in the KDC reply will be the user account’s normalized SAM account name.  
So this could result in mismatch of username between what is present in the Kerberos ticket and the value specified in the Request.

Section 6 from http://tools.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals-11 describes this.  

3.)	The KDC always returns its proper realm name.  This is not part of the canonicalize flag.  Per the RFC, realm names are case sensitive and so sending a realm name with the case modified should result in Kerberos rejecting the authentication outright since the realm name provided is not known.  Windows allows realm names to be case insensitive which is why you can get away with this.


Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org] 
Sent: Wednesday, January 28, 2015 7:14 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 Tue, 2015-01-27 at 23:19 +0000, Sreekanth Nadendla wrote:
> 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.

This looks reasonable.

> 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.

This is what I see.

> 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

See attached. 

> 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.

I agree with you about the username, but the realm has also been 'fixed'.  That doesn't seem to be specified in MS-KILE, or in: 

[Referrals-11] Raeburn, K., and Zhu, L., "Kerberos Principal Name Canonicalization and KDC- Generated Cross-Realm Referrals", July 2008,
http://tools.ietf.org/internet-drafts/draft-ietf-krb-wg-
kerberos-referrals-11

For service implementers, the challenge as I mentioned before is that if the client chooses not to specify canonicalization, the server they contact, unknowing and unable to control this part, gets different principals for the same user.  This much should be called out somewhere. 

> 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
> 
> 
> 
> 

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