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:[email protected]] Sent: Wednesday, January 28, 2015 7:14 PM To: Sreekanth Nadendla Cc: MSSolve Case Email; [email protected] 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 [email protected] > > 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 [email protected] > [canonicalization occurs with stock build of kinit with enterprise option] > Principal: [email protected] > > 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 [email protected] > Principal: [email protected] > > 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 [email protected] [only > enterprise, no canonicalization] > Principal: [email protected] 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:[email protected]] > Sent: Sunday, January 25, 2015 9:34 PM > To: Sreekanth Nadendla > Cc: MSSolve Case Email; [email protected] > 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 _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
