[jcifs] Win 2003 support?

[Michael B Allen]

> The problem is that from step 6 on, all SMB packets
> are
> signed using the user session key.  We don't have the user's password, so
> we
> can't derive the key; which means that we can't do anything useful with
> the
> established SMB session.

But can you just pass tokens back and fourth and get the user session key?

> The "Negotiate NTLM2 Key" flag, etc. are used to negotiate NTLMSSP
> signing/sealing; this is used for DCE/RPC traffic (and is based on the
> operations described in my NTLM documentation).  SMB signing is at a lower

Ok. I misunderstood your document. It need to try and get a packet capture
of the SessionSetupAndXs that do this extended nogotiation to see how your
description is manifested on the wire with SMBs.

> 4.  The server gets back from the DC the user session key, as well as the
> first 8 bytes of the LM hash (which can be used to establish the
> LanManager
> session key).
>
> The server can then use the user session key (or LanManager session key,
> depending on the NTLM options negotiated) to sign and seal, either to the
> client or on behalf of the client.
>
> (roughly) include implementing the client side of:
>
> PIPE\lsarpc -- to look up the domain SID
> PIPE\samr   -- to create the machine account in the domain

Ok. So we even if IE will cough up the user session key that's obviously
not the Right Way. Let's chaulk this one up as yet another reason to
implement RPCs.

Well get there. Unfortunately it's two iterations away...

Mike