[jcifs] Win 2003 support?
eglass1 at comcast.net
eglass1 at comcast.net
Tue Sep 2 21:57:43 EST 2003
> So why are we different from IIS? Will IE not fully participate in the
> NTLM netgotiation and accept the Negotiate NTLM2 Key flag? Meaning can we
> just marshall the tokens back and fourth and only decode/encode
> decrypt/encrypt as little as necessary?
Basically, what we do is a bit different from IIS on several levels. We
authenticate via passthrough; when we need authentication, we do this:
1. Get a Type 1 message from the client.
2. Send a NegProt request (w/out extended security) to the "DC" (any box
serving SMB really).
4. Get a NegProt response from the DC, where the EncryptionKey field contains
3. Create a Type 2 message containing the challenge and send it to the
4. Get a Type 3 message containing the responses from the client.
5. Send a SessionSetupAndX request to the "DC" with the LM and NTLM responses
in the CaseInsensitive and CaseSensitive password fields.
6. Get an affirmative response back indicating that authentication was
Essentially, we impersonate a client to a server, and let them do the
authentication to the domain controller for us (assuming the server is not
itself a domain controller). The SMB session we establish with the server can
be used to access resources on that server (i.e., Davenport/NetworkExplorer).
We can perform the same process against another server to access its resources.
The problem we will see is that the passthrough authentication we use is
essentially a man-in-the-middle attack between the client and our "DC" --
which is precisely what SMB signing is designed to foil. The authentication
handshake above works fine; the user is authenticated properly, and
everybody's happy. 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. It still works for simple authentication of web apps
(since we can just skip verification of the signature on the SessionSetupAndX
response), but throws a big monkey wrench at Davenport/NetworkExplorer, where
we subsequently use the session to access server resources.
IIS uses the SSPI; this would look something like:
1. Get a token from the client (we will assume NTLMSSP, so this is a Type 1
2. Call AcceptSecurityContext, passing in the received token.
3. Send the resulting output token to the client (in our case a Type 2
4. Repeat until finished.
IIS doesn't really care *how* the user is authenticated; it only cares that
SSPI was able to successfully establish a security context for the user. On
the NTLMSSP backend, what happens is that the user is either authenticated
against the local SAM database, or NetLogon calls are performed to
authenticate them against a domain controller's SAM.
IIS authenticates the user to establish a security context; this is used to
access web server resources. No SMB file accesses are typically performed.
This would be similar to using the NtlmHttpFilter to authenticate the user,
then using local java.io.File accesses. The concept of accessing arbitrary
SMB resources across multiple servers is "special" to
Davenport/NetworkExplorer. The closest thing I could think of in the IIS
world would be to set up virtual directories to network shares.
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
level (although it employs the user session key, which plays a large part in
deriving the NTLMSSP keys) and is described in Chris' book. IIS just
negotiates the "vanilla" NTLM flags used by the NTLMSSP by default; while it
indicates that NTLM2 session security is supported, it doesn't request
NTLMSSP signing or sealing.
> > The complete solution would be to implement RPC NetLogon, but we're a
> > ways from that; even once simple RPC functionality is in, that's one of
> > the more difficult ones to implement
> Why, is the NetLogon RPC not subject to signing/sealing?
> > (as it is my understanding that it
> > requires SecureChannel encryption to the domain controller).
> Err, I thought SecureChannel was just another way of describing sealing.
> Does the sealing described in your NTLM document apply to SMB
> signing/sealing? What's is SecureChannel?
NetLogon effectively does the following:
1. The server generates its own challenge (i.e., doesn't pass through to the
DC). This is sent in the Type 2 message.
2. The client responds with the Type 3 message (containing the LM/NTLM
3. The server sends its challenge and both responses to the DC over the
NetLogon channel for authentication.
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
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.
Obviously, there are significant security issues surrounding the transmission
of the user session key and LM hash. This is where NetLogon SecureChannel
encryption enters the picture. It's basically described in Leighton's book
(appendix B.3.4), although it may have changed in the interim. Essentially,
the DC and server authenticate each other using the server's account in the
domain, and establish a session key. A second connection to the DC is opened
by the server, which is signed/sealed using a different scheme based on the
established session key. I assume this exchange takes place when the server
boots up, but I'm not sure. In any case, this is apparently the channel that
the server sends the NetLogon calls across.
The big obstacle with implementing NetLogon isn't the extra crypto involved
(mostly the "usual suspects" -- HMAC and RC4); rather, it's the "foundation
work" that needs to be in place. This includes doing full-blown domain joins
as a member server. Looking at utils/net_rpc_join.c (from Samba), this would
(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
More information about the jcifs