[jcifs] NTLMv2 issues

[Tapperson Kevin]

Thanks, this is great!  I know for a fact that one of the users who was
having trouble after switching to lmCompatibility = 3 had a password that
was about 30 characters long (much longer than the 15 character limit for a
DC to store the LM hash).  I was able to create a test user account and set
it up with a long password (and hence no LM hash in the DC).  It looks like
a work-around might be to ask any users who have trouble to switch their
windows registry setting to lmcompatibilitylevel = 3 to avoid this problem.
Then IE sends the LMv2 and NTLMv2 hashes, and jcifs (at lmCompatibility = 3)
would forward the LMv2 hash only to the DC for verification.

As far as what's going on in jcifs...

I've compared the Type3 messages that jcifs receives from IE.  It looks like
the only difference between an NTLM and NTLMv2 Type3 message is the content
of the LM/LMv2 and NTLM/NTLMv2 hashes and the length of the NTLM/NTLMv2
hash.  The NTLM hash is always 0x18 bytes long, the NTLMv2 hash is 0x54
bytes long.  Does anyone know if these hash lengths are always 0x18 and 0x54
bytes long?  From what I have read, it looks safe to assume so.  If this is
consistent behavior, it would be possible then to detect whether the client
IE browser is supplying an NTLM or NTLMv2 Type3 message.  If the client has
provided an NTLM Type3 message, both the LM and NTLM hashes could then be
passed to the DC.  If the client has provided an NTLMv2 Type3 message, then
the NTLMv2 hash could be eliminated and only the LMv2 hash sent (as is
currently is today) to prevent failures related to jcifs not fully
supporting NTLMv2.

If someone can confirm that the hash lengths are constant, then I would
suggest changing Type3Message.parse() as follows.
from:
	...
	// NTLMv2 issues w/cross-domain authentication; leave NT empty if
[LM_COMPATIBILITY] >= 3
	if (LM_COMPATIBILITY < 3) setNTResponse(ntResponse);
	...
to:
	...
	// NTLMv2 issues w/cross-domain authentication; leave NT empty if
NTLMv2 was sent by the client
	if (ntResponse.length == 0x18) setNTResponse(ntResponse);
	...



> from the client.  My guess then is that these users that are having
trouble
> authenticating have something flagged on their account in Active Directory
> to deny them the ability to authenticate using only the LM password hash,
or
> simply don't have an LM password hash stored in the DC.  If this is the
> case, does anyone know how to create an account with such a configuration?

Here is a link for how to prevent the LM hash from being stored:

http://support.microsoft.com/default.aspx?scid=KB;EN-US;q299656

This seems to me to be what you suspected.  In Type3Message.java at
the bottom there is this:

// NTLMv2 issues w/cross-domain authentication; leave NT empty if >= 3
if (LM_COMPATIBILITY < 3) setNTResponse(ntResponse);

You could try to edit this and see if it works to fix it.