[jcifs] jCIFS Updates, redux
eglass1 at comcast.net
eglass1 at comcast.net
Wed Jul 9 22:23:45 EST 2003
Mike/all,
Attached is a bunch of cleaned-up code, including support for LMv2. I went
ahead and removed the NTLMv2 response stuff, since it was commented out
anyways; this was where the writeTime function was needed, so it's a moot point
for now. Theoretically, I suppose I could test whether the TZ adjustment is
needed by frobbing with my time and timezone settings and see what ends up in
the Type 3 messages. If/when I put the NTLMv2 stuff back in I'll do some
experimenting with this -- in the meantime, LMv2 works great.
The use of LMv2 is controlled via the "jcifs.smb.lmCompatibility" property,
which mirrors the corresponding registry setting:
0,1 -- Use LM/NTLM (the default)
2 -- Use only NTLM
3,4,5 -- Use LMv2
The rest of this message is a description of the issue I was seeing with
NTLMv2, and is a boring read -- feel free to skip it. ;)
Basically, the blob in the NTLMv2 response contains the "target information"
structure sent in the Type 2 message (which contains a list of NetBIOS and DNS
names). When dealing with NTLMSSP messages, this works great -- you grab the
target information block out of the Type 2 message, and use it directly in the
calculation of the NTLMv2 response. This is the case when "extended security"
handshaking takes place; the security blob in the session setup response
contains a Type 2 message with the appropriate target information block, and
the second setup request contains the Type 3.
In our case, however (non-extended security), we just have the encryptionKey
(server challenge) to work with. We need to calculate the ansiHash (LMv2
response) and unicodeHash (NTLMv2 response).
For the LMv2 response, this is easy -- you just create a random client nonce
and calculate the HMAC of the server challenge + the nonce.
The NTLMv2 response is a bit trickier, since we create the blob; this contains
a bunch of stuff, including the nonce, a timestamp, and the target information
block. Note, however, that we don't *have* the target information block; so we
have to create one. My initial attempt at this was simply to use a big block
of random data for the blob. There is some documentation in Samba-TNG
(smbencrypt.c) which indicates that this works. And it did, *most* of the
time. I ran into errors, however, when attempting to connect to servers that
were members of a different domain.
Apparently, when a user in domain 'A' is connecting to a server which is also a
member of 'A', the contents of the blob are not checked at all; the entire blob
is essentially treated as a giant client nonce. When a user in 'A' accesses a
server that is a member of 'B', however, I found that authentication would only
succeed if the target information block within the blob contained (at a
minimum) an entry for domain 'B'.
Currently, the unicodeHash is created via:
NtlmPasswordAuthentication.getUnicodeHash(challenge);
Which just creates the NTLM response from the password and challenge. To
create the NTLMv2 response, we need:
The user's domain (which we have)
The username (which we have)
The server challenge (which we have)
The client nonce (which we can create)
The target information block (which we *could* create properly, *if* we had the
server's domain)
To successfully create the NTLMv2 response, we need the domain to which the
server belongs. Technically, I believe we have this information (since it
seems to be sent in the "negotiate protocol" response); it might be feasible to
change getUnicodeHash to accept this as an additional parameter, if desired.
However, in the end it doesn't really matter; from a cryptographic standpoint,
the LMv2 response is as strong as the NTLMv2 response. The LMv2 response is
accepted by all servers which understand NTLMv2. There just isn't much point
in going to the extra effort to implement NTLMv2.
Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-tar
Size: 17719 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20030709/eb1bb36f/attachment.tar
More information about the jcifs
mailing list