Problems with WinXP joining a Samba-head domain (and suggested solutions)
lukeh at padl.com
Wed Sep 11 17:48:00 GMT 2002
>Well, the interesting thing to me is that WinXP managed to join with
>Sign/Seal enabled, but failed on the first logon attempt.
At least with Windows 2000 joining Active Directory (which is what we're
testing right now) the domain join doesn't seem to mind if the
NetrServerAuthenticate() / NetrLogonGetDomainInfo() fails. As long
as the LSA and SAM RPCs that are made over SMB succeed, the client
thinks that it has joined.
>This failure seems to occur after Samba responds SUCCESS to
>ServerAuthenticate2, but, I suspect, with the wrong bits. I noticed that
>XP includes at least one new flag bit that Win2K does not send.
Interesting, which one is this?
>I surmise that it was some bit not set in the result flags that Samba
>returns, as it still returns 0X1FF.
According to Luke Leighton's book 0x40000000 is the Secure Channel flag.
Presumably if the client is configured to _require_ SignOrSeal, then if
this bit is not negotiated it will fail. Other bits appear to determine
whether the client uses Kerberos or NT 4 RPCs for domain logon. A Windows
2000 sends 0x6007ffff.
>> Last time I looked, the secure channel bind PDU included the NetBIOS
>> name, the workstation name, and the DNS domain name and host, which
>> are presumably used by the server as a key to retrieve the session key
>> previously negotiated by NetrReqChallenge() and NetrServerAuthenticate3().
>> The session key is used to sign/seal the channel (roughly per
>> draft-brezak-win2k-krb-rc4-hmac-04.txt). I didn't take note of how
>> these were encoded (whether they were Unicode strings, etc).
>Hmmm, that is interesting.
It makes sense, and some of this is implemented in TNG (not sure whether
it works or not). It's an interesting abstraction violation to consider how
the session key gets passed to the RPC authentication layer; we did it
with a callback in the Schannel GSS-API mechanism to the NETLOGON server.
(By Schannel, I'm referring to the Netlogon secure channel, not Microsoft's
SSL/TLS encapsulation within GSS-API; the nomenclature is confusing.)
>These might be interesting. I might not have enough VMware engines to test
>this all out.
Huh, VMware and Ethereal are definitely the tools of the trade here :-)
>It might be interesting to implement SIGN/SEAL ... for a number of
Well, the best reason is being able to work with out-of-the-box clients,
regardless of whether we're talking about NT 4-style domain logon or
Active Directory. Note that Active Directory clients still use the
Netlogon credentials chain / secure channel for, amongst other things,
verifying the PAC signatures (as completely unnecessary as this is from
an architectural standpoint).
OTOH, from a resourcing point of view, there are other interoperability
hurdles that we need to resolve before we look at finishing our
implementation of this (which doesn't use SAMBA anyway, so it's probably
Luke Howard | lukehoward.com
PADL Software | www.padl.com
More information about the samba-technical