[jcifs] No response to NTLM challenge: **SOLVED**

[Steven.Durkin at scotland.gsi.gov.uk]

*******************************************************************************************************************************************************
This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed.
*******************************************************************************************************************************************************

Eric,

You've done it, thank you! It was the NtlmMinClientSec registry key
entry on the PC that was causing the problem. It was set to 0x00080000,
and thus ensured that the connection was dropped if NTLMv2 session
security was not negotiated. Setting it to 0 fixes the problem. (I
haven't tried other values just yet, but that's next on my list.)

For info, The fact that NTLM2 is not supported in JCFIS has been at the
heart of the confusion for me. I had already checked the registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LmCompatibility
which was set to 1, so NTLM2 *authentication*  was not required by the
client. That's the point I ruled NTLM2 out. However, the registry key
you gave
(HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA\MSV1_0) was set
to 0x00080000 meaning that NTLM2 *session security* was required.
Without it the browser just stops the negotiation after the server's
challenge. (Though in some scenarios during testing it caused a
renegotiation which also subsequently failed.) 

I have not yet applied the amendment you suggested to Type2Message.java
to set the NTLMSSP_NEGOTIATE_128 and NTLMSSP_NEGOTIATE_56 flags in the
Type 2 message. Could you send the attachment and I will try it out?
Anyway, the messages now exchanged between IE6 and JCIFS are just the
same as they were before: the client negotiates for NTLMv2, and the
server responds with NTLMv2 not negotiated. But now that the registry
entry has changed the client responds as expected with a Type 3 message,
and the transaction is completed correctly. So this has  undoubtedly
been the heart of the problem.

There is a downside to all of this for me. Policy dictates that the
registry entry in question must be set to 0x00080000, which is a bit of
a problem. Are planning on supporting NTLM2 in a future release?

I am thrilled that we have finally found the solution to this, and your
advice has been invaluable! I will post an update to this if anything
interesting comes out of the upcoming tuning and tweaking of the system!
Many thanks,

Steve.


> 
> First, take a look on the client at the registry key:
>
>HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA\MSV1_0\NtlmMinC
lientSec
>
> This is a bitmask, the meaning of which is described at the bottom of
> this article:
>
>     http://support.microsoft.com/default.aspx?scid=KB;en-us;239869
>
> If there is a value there, that may be the cause; you can try deleting
> it and seeing if it succeeds.

The original of this email was scanned for viruses by the Government Secure Intranet (GSi) virus scanning service supplied exclusively by Energis in partnership with MessageLabs.

On leaving the GSi this email was certified virus-free