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

[Mark R Bannister]

On 11/09/2011 02:50 PM, Greg Hudson wrote:
> On 11/09/2011 08:40 AM, Mark R Bannister wrote:
> > 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.
> 
> The canonicalize bit is still meaningful for TGS requests; see section 8
> on server referrals.  The text you quoted is about alias
> canonicalization, not referrals to another realm.

I'm not sure section 8 applies in this case, there should be no referral as
there's only one realm in play here.

> > 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.
> 
> Starting with version 1.6, we set the canonicalize bit on TGS requests
> in order to support server referrals to other realms.  In many error
> cases, we fall back to a request without the canonicalize bit; there is
> a bug in 1.9 and 1.9.1 (fixed in 1.9.2, which was issued very recently)
> which reduces the number of cases where we make that fallback.  I'm
> guessing that bug is the source of your problems:
> 
> http://krbdev.mit.edu/rt/Ticket/Display.html?id=6917&user=guest&pass=guest
> 
> although the situation in your case seems to be more complicated.

I've installed v1.9.2 from
http://buildfarm.opencsw.org/experimental.html#kerberos and re-tested.  I get
exactly the same problem:

# /usr/local/sbin/msktutil -c --delegation --user-creds-only -k /etc/krb5/krb5.keytab
No computer account for myhost found, creating a new one.
dn: cn=myhost,CN=Computers,DC=mytest,DC=net
Error: krb5_set_password_using_ccache failed (Cannot contact any KDC for
requested realm)
Error: set_password failed

# ldd /usr/local/sbin/msktutil | grep libkrb5.so
        libkrb5.so.3 =>  /opt/csw/lib/libkrb5.so.3

# /usr/ccs/bin/nm /opt/csw/lib/libkrb5.so.3 | grep using_ccache
[2392]  |    473956|     225|FUNC |GLOB |0    |12     |krb5_set_password_using_ccache

# grep /opt/csw/lib/libkrb5.so.3 /var/sadm/install/contents
/opt/csw/lib/libkrb5.so.3=libkrb5.so.3.3 s none CSWlibkrb5-3
/opt/csw/lib/libkrb5.so.3.3 f none 0644 root bin 1523800 5740 1320859927 CSWlibkrb5-3

# pkgparam CSWlibkrb5-3 VERSION
1.9.2,REV=2011.11.09


Analysing network packets (captured with snoop, dumped with tshark) shows:

------------------------------------------------------------
Kerberos TGS-REQ
...
    padata: PA-TGS-REQ
        Type: PA-TGS-REQ (1)
...
                Ticket
                    Tkt-vno: 5
                    Realm: MYTEST.NET
                    Server Name (Unknown): krbtgt/MYTEST.NET
                        Name-type: Unknown (0)
                        Name: krbtgt
                        Name: MYTEST.NET
...
    KDC_REQ_BODY
...
        KDCOptions: 40810000 (Forwardable, Renewable, Canonicalize)
...
        Realm: MYTEST.NET
        Server Name (Unknown): kadmin/changepw
            Name-type: Unknown (0)
            Name: kadmin
            Name: changepw
        till: 2011-11-14 22:26:31 (UTC)
------------------------------------------------------------
Kerberos TGS-REP
    Record Mark: 1306 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0101 0001 1010 = Record Length: 1306
    Pvno: 5
    MSG Type: TGS-REP (13)
    Client Realm: MYTEST.NET
    Client Name (Principal): ldap
        Name-type: Principal (1)
        Name: ldap
    Ticket
        Tkt-vno: 5
        Realm: MYTEST.NET
        Server Name (Service and Instance): krbtgt/MYTEST.NET
            Name-type: Service and Instance (2)
            Name: krbtgt
            Name: MYTEST.NET
------------------------------------------------------------

So we provide a valid TGT for the MYTEST.NET realm, and request a kadmin/changepw
ticket in the same realm.  Instead of being given a kadmin/changepw ticket in the
response, we're being given another TGT for the same realm.

As I indicated at the start of this thread, if kdc option bit 15 (canonicalize)
is cleared everything works fine, as demonstrated using Kerberos libraries v1.4.4
on Solaris 10 (and v1.6.1 on RHEL 5.5).

It appears that this is a new bug...

Thanks,
Mark Bannister.