Support for Windows Server 2003 referrals

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Support for Windows Server 2003 referrals

Nate Rosenblum
All--

I've submitted a pull request that allows referrals to work in Windows
Server 2003 forests. The issue is described in the patch, but in short
Server 2k3 uses the wrong error type (PRINCIPAL_UNKNOWN) to indicate a
referral. I speculate that this continues to be the case in later
service releases for backwards compatibility, 2k3 predating the
referrals draft, but don't really have any context.  Let me know if
there are any questions.

https://github.com/krb5/krb5/pull/39

Best,

--nate
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Support for Windows Server 2003 referrals

Nate Rosenblum
>
> I've submitted a pull request that allows referrals to work in Windows
> Server 2003 forests. The issue is described in the patch, but in short
> Server 2k3 uses the wrong error type (PRINCIPAL_UNKNOWN) to indicate a
> referral. I speculate that this continues to be the case in later
> service releases for backwards compatibility, 2k3 predating the
> referrals draft, but don't really have any context.  Let me know if
> there are any questions.
>
> https://github.com/krb5/krb5/pull/39


Checking in to see whether there's anything I can clarify or do to help get
this compatibility patch merged. If reproducing the issue is a problem due
to lack of Windows Server 2k3 availability, I can capture a wire trace that
shows the non-compliant referral behavior of that implementation. Please
let me know.

Best,

--nate
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Support for Windows Server 2003 referrals

Greg Hudson
On 01/29/2014 12:30 PM, Nate Rosenblum wrote:
> Checking in to see whether there's anything I can clarify or do to help get
> this compatibility patch merged. If reproducing the issue is a problem due
> to lack of Windows Server 2k3 availability, I can capture a wire trace that
> shows the non-compliant referral behavior of that implementation. Please
> let me know.

A wire trace would definitely be helpful.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: 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 `[hidden email]`,
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): [hidden email]
            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
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Support for Windows Server 2003 referrals

Tom Yu
Nate Rosenblum <[hidden email]> writes:

>>
>> A wire trace would definitely be helpful.
>>
>
> Happily:
>
> Here's an AS-REQ & error response for a login for `[hidden email]`,
> 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.

[...]

Thanks for the trace.  Is this behavior documented in the MSDN Libray
by any chance?  I couldn't find it during a quick skim.  If it's not
documented, perhaps you could report that to Microsoft?
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Support for Windows Server 2003 referrals

Nate Rosenblum
>
> Thanks for the trace.  Is this behavior documented in the MSDN Libray
> by any chance?  I couldn't find it during a quick skim.  If it's not
> documented, perhaps you could report that to Microsoft?
>

I was unable to find anything on MSDN when I discovered this issue. I'll
take another pass for technet articles and so forth tonight and pass
something on to Microsoft..

--nate
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Support for Windows Server 2003 referrals

Greg Hudson
In reply to this post by Nate Rosenblum
On 01/29/2014 01:13 PM, Nate Rosenblum wrote:
> Here's an AS-REQ & error response for a login for `[hidden email]`,
> an enterprise principal name.

We asked Microsoft for clarification about this behavior, and the
engineer noted that the canonicalize flag is not set in the AS request:

>     Kerberos AS-REQ
>         KDC_REQ_BODY
>             KDCOptions: 00000010 (Renewable OK)
>             Client Name (Enterprise Name): [hidden email]

We have logic to accept a canonicalized response if the client name is
an NT_ENTERPRISE principal, but not to set the canonicalize flag in the
request.  I think we will want to change that.  For the moment, can you
try setting the canonicalize flag by hand (with kinit -C or
krb5_get_init_creds_opt_set_canonicalize) and checking that you get a
WRONG_REALM response from Server 2003?

Our KDC treats the canonicalize flag as implicitly set if the client
name type is NT_ENTERPRISE.  I would speculate that Server 2008 does the
same, but that Server 2003 does not.

If I am right, then it's still kind of interesting that Server 2003
includes the referral realm in the PRINCIPAL_UNKNOWN error for a
non-canonicalize NT_ENTERPRISE AS-REQ, but it's probably not behavior we
want to react to.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Support for Windows Server 2003 referrals

Nate Rosenblum
>
>
> Our KDC treats the canonicalize flag as implicitly set if the client
> name type is NT_ENTERPRISE.  I would speculate that Server 2008 does the
> same, but that Server 2003 does not.
>
>
Oh, would that it were so. However, in my application I do set the
canonicalize bit; I regret that I muddied the waters by failing to do so
when reproducing with kinit. I've responded in the Microsoft with traces
that show that Server 2k3 does the wrong thing even when asked to
canonicalize.


> If I am right, then it's still kind of interesting that Server 2003
> includes the referral realm in the PRINCIPAL_UNKNOWN error for a
> non-canonicalize NT_ENTERPRISE AS-REQ, but it's probably not behavior we
> want to react to.
>

I would strongly prefer that the patch be merged; I think we have pretty
strong confidence that 2k3's behavior is not intentional and needs this
workaround, but am happy to wait for another iteration with our Microsoft
contact.

Best,

--nate
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev