Support for Windows Server 2003 referrals

[Nate Rosenblum]

>
> A wire trace would definitely be helpful.
>

Happily:

Here's an AS-REQ & error response for a login for `nater at maginatics.com`,
an enterprise principal name. I've sent it to the domain controller for
TEST2K3.QA.LOCAL, a lab testbed which as its name suggests is a Windows
Server 2003 DC. The real account lives in the TEST2K8.QA.LOCAL domain, a
member of the same forest.

    No.     Time            Source                Destination
Protocol Length Info
         16 10:08:15.874840 10.1.10.223           10.102.50.102
KRB5     245    AS-REQ

    Frame 16: 245 bytes on wire (1960 bits), 245 bytes captured (1960 bits)
    Ethernet II, Src: a8:20:66:2b:d6:f1 (a8:20:66:2b:d6:f1), Dst:
b0:a8:6e:80:d6:01 (b0:a8:6e:80:d6:01)
    Internet Protocol Version 4, Src: 10.1.10.223 (10.1.10.223), Dst:
10.102.50.102 (10.102.50.102)
    User Datagram Protocol, Src Port: 61248 (61248), Dst Port: kerberos (88)
        Source port: 61248 (61248)
        Destination port: kerberos (88)
        Length: 211
        Checksum: 0x5290 [validation disabled]
    Kerberos AS-REQ
        Pvno: 5
        MSG Type: AS-REQ (10)
        padata: Unknown:149
        KDC_REQ_BODY
            Padding: 0
            KDCOptions: 00000010 (Renewable OK)
            Client Name (Enterprise Name): nater at maginatics.com
            Realm: TEST2K3.QA.LOCAL
            Server Name (Service and Instance): krbtgt/TEST2K3.QA.LOCAL
                Name-type: Service and Instance (2)
                Name: krbtgt
                Name: TEST2K3.QA.LOCAL
            from: 2014-01-29 18:08:15 (UTC)
            till: 2014-01-30 18:08:15 (UTC)
            Nonce: 573742634
            Encryption Types: aes256-cts-hmac-sha1-96
aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac

    No.     Time            Source                Destination
Protocol Length Info
         17 10:08:15.879986 10.102.50.102         10.1.10.223
KRB5     166    KRB Error: KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN

    Frame 17: 166 bytes on wire (1328 bits), 166 bytes captured (1328 bits)
    Ethernet II, Src: b0:a8:6e:80:d6:01 (b0:a8:6e:80:d6:01), Dst:
a8:20:66:2b:d6:f1 (a8:20:66:2b:d6:f1)
    Internet Protocol Version 4, Src: 10.102.50.102 (10.102.50.102), Dst:
10.1.10.223 (10.1.10.223)
    User Datagram Protocol, Src Port: kerberos (88), Dst Port: 61248 (61248)
        Source port: kerberos (88)
        Destination port: 61248 (61248)
        Length: 132
        Checksum: 0x8ab9 [validation disabled]
    Kerberos KRB-ERROR
        Pvno: 5
        MSG Type: KRB-ERROR (30)
        stime: 2014-01-29 18:08:14 (UTC)
        susec: 288207
        error_code: KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN (6)
        Client Realm: TEST2K8.QA.LOCAL
        Realm: TEST2K3.QA.LOCAL
        Server Name (Service and Instance): krbtgt/TEST2K3.QA.LOCAL
            Name-type: Service and Instance (2)
            Name: krbtgt
            Name: TEST2K3.QA.LOCAL


In the error response packet, the server returns `PRICIPAL_UNKNOWN` as I
describe in the github issue, but it also contains the proper client_realm
referral field. This spec deviation seems to have been corrected in Server
2008; I'll spare you the packet traces, but a similar referral experiment
on a domain controller of that vintage yields the expected `WRONG_REALM`
error code and the library does the right thing.

Let me know if you need anything else.

--nate