MIT Kerberos 5 v1.9.1 krb5_set_password_using_ccache() fails with Windows 2003 R2

[Mark R Bannister]

Hi,

I'm not sure if I've found a bug in MIT Kerberos 5 v1.9.1, or a bug in Windows
2003 R2, or both.  So let me explain what I've found.

I'm using http://fuhm.net/software/msktutil/ on RHEL 5 and Solaris 10 to create
computer objects and keytab files in an environment with Active Directory running
on Windows 2003 R2.

This works fine on RHEL 5.5 with MIT Kerberos 5 v1.6.1, and also works ok on
Solaris 10 Update 8 with MIT Kerberos 5 v1.4.4 obtained from
http://mirror.opencsw.org/opencsw/stable/i386/5.10/.

However, when attempted on Solaris 10 with MIT Kerberos 5 v1.9.1 obtained from
http://www.opencsw.org/packages/CSWlibkrb5-3/ the process fails to obtain a
kadmin/changepw ticket after successfully creating the computer object.

The C++ code launches krb5_set_password_using_ccache(), and promptly fails with:
Error: krb5_set_password_using_ccache failed (Cannot contact any KDC for
requested realm)
Error: set_password failed

Analysing network packets and comparing successful and unsuccessful attempts,
when it works I see:

TGS-REQ for kadmin/changepw, KDC option bit 15 (canonicalize) is NOT set.
TGS-REP supplies kadmin/changepw as requested.

When it fails I see:

TGS-REQ for kadmin/changepw, KDC option bit 15 (canonicalize) is set.
TGS-REP provides a TGT, not kadmin/changepw.

So it appears to be a problem with KDC option bit 15.  Reading around this
subject, RFC 4120 only mentions in section 5.4.1 (KRB_KDC_REQ Definition) that
bit "15 is reserved for canonicalize".  The subject is discussed further in
draft-ietf-krb-wg-kerberos-referrals-13
http://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-referrals-13/ in sections 3
(Requesting a Referral) and 6 (Name Canonicalization).  Section 6 is quoted below:

   If the "canonicalize" KDC option is set, then the KDC MAY change the
   client and server principal names and types in the AS response and
   ticket returned from those in the request.  Names MUST NOT be changed
   in the response to a TGS request, although it is common for KDCs to
   maintain ta set of aliases for service principals.  Regardless of
   which alias a client requests, the same service key is used.
   However, in the TGS request, the client receives a ticket for
   whichever alias is requested.

This implies to me that Windows 2003 R2 has a bug.  It ought to be ignoring bit
15 in a TGS-REQ, but this would not appear to be the case.

However, what's the rationale for the change in behaviour to MIT Kerberos v5? 
Why is MIT Kerberos now setting KDC option bit 15 on a TGS-REQ for a changepw? 
Evidence shows that previous versions did not set this bit.

Thanks & regards,
Mark Bannister.