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

[Andrew Bartlett]

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-canon.enterprise.lc-realm.uc-user.krb5-realm.win2k.upn.pcapng
Type: application/x-pcapng
Size: 5336 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20150129/eec9d69e/attachment.bin>