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

[Eric Glass]

Forgot to zip for the list.

Eric


---------- Forwarded message ----------
From: Eric Glass <eric.glass at gmail.com>
Date: Wed, 11 Aug 2004 10:09:20 -0400
Subject: Re: [jcifs] No response to NTLM challenge: **SOLVED**
To: "steven.durkin at scotland.gsi.gov.uk" <steven.durkin at scotland.gsi.gov.uk>
Cc: jackie.davis at scotland.gsi.gov.uk, jcifs at lists.samba.org,
john.knowles at scotland.gsi.gov.uk

Attached are patched versions of the TypeX messages to indicate
support for 128- and 56-bit encryption; this would fix this issue for
people who have registry settings indicating those as a requirement.
It probably won't help your case though (as your box is requiring
NTLM2).

Support for handling the NTLM2 session response on the server side
(i.e. in the filter) would require extended security support in jCIFS.
This is on the horizon, but not in the immediate future I'm afraid :(


Eric




On Wed, 11 Aug 2004 13:02:08 +0100, steven.durkin at scotland.gsi.gov.uk
<steven.durkin at scotland.gsi.gov.uk> wrote:
> *******************************************************************************************************************************************************
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: typex.tgz
Type: application/x-gzip-compressed
Size: 6312 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20040811/79212057/typex.bin