[jcifs] Domain based DFS support in Kerberos code, or NTLMv2 support in Java 1.4?

[Michael B Allen]

On Wed, Mar 25, 2009 at 11:18 AM, Darren Taft <daztop at rocketmail.com> wrote:
>
>> > Using the List example code compiled with Java 1.4, with these scenarios:
>> >
>> > 1. Standard server (always works)
>> > 2. Domain based DFS
>> > 3. Dodgy server
>> >
>> > Sun JRE 1.5 - all passes (as expected)
>> > Sun JRE 1.4 - #1 and #3 work, but #2 fails as it doesn't have an RC4 cipher
>> > available (also as expected)
>>
>> It sounds like your "dodgy server" simply does not support NTLMv2 so
>> the RC4 code isn't exercised. My guess is it's either NetApp or an old
>> version of Samba.
>>
>> The #2 test fails with the RC4 cipher unavailable error because domain
>> based DFS needs to communicate with the DC which does support NTLMv2.
>>
>> > Following the above 3 scenarios again, but this time setting
>> > jcifs.smb.client.useExtendedSecurity=false and jcifs.smb.lmCompatibility=0
>> >
>> > Sun JRE 1.4 - #1 and #2 are OK, but #3 fails with the timeout error (at the
>> beginning of this email)
>>
>> #3 should work here. Running any version of JCIFS with
>> jcifs.smb.client.useExtendedSecurity=false and
>> jcifs.smb.lmCompatibility=0 should work with any server that supports
>> NTLMv1.
>
> It's the combination of the above 2 tests that I'm finding the most interesting -
> there is code present that causes my "dodgy" server to work, but that code is
> disabled when NTLMv2 support is disabled.  Surely fixing this issue will just
> involve comparing 2 execution paths:
>
> 1. Connecting to a server with NTLMv1 when NTLMv2 support is enabled
> 2. Connecting to a server with NTLMv1 when NTLMv2 support is disabled
>
> That's what it's coming down to - one works, and the other doesn't.  I would
> have expected both code paths to be the same (after the initial check for NTLMv2
> returned false), but they're obviously not.

The version of NTLM used is not negotiated. The default behavior is
NTLMv2. If you want NTLMv1 you set the two properties.

In the (distant) future properties will be configurable at runtime but
that still won't make NTLM negotiable. It will just allow you to set
which version is used within some scope (probably per-thread but this
isn't clear yet).

>> > So what we're left with now is awkward.
>> >
>> > It appears that our domain server supports NTLMv1 and v2.  With JCIFS 1.3
>> > it tries to use v2 but can't due to the lack of RC4.
>> >
>> > The 1.3 code stream has fixed whatever fault there was with the dodgy server,
>> > however it can't be using NTLMv2 otherwise it would have trigged the RC4 error
>> > as above.
>> >
>> > Disabling the NTLMv2 support (using jcifs.smb.client.useExtendedSecurity=false
>> > and jcifs.smb.lmCompatibility=0) fixes the domain based DFS, but breaks the
>> > dodgy server again.
>> >
>> > What would you recommend as the next course of action?
>>
>> Try to find out what the "dodgy server" is and what version it is. If
>> you look closely at the JCIFS log output you might see that
>> information.
>
> It has taken me a while to find the support engineer for that server.  Eventually
> the response has come back as:
>
> Server Op Sys: Windows server 2003 Ver. 5.2
> No service Pack
>
> He's been unable to tell me of anything different about that server build.

That's strange. I forget. Why can't you do NTLMv2? If the server is
really Windows Server 2003, it can do NTLMv2 so please remind me what
your overall issue is again.

>> Meanwhile I'll recompile with 1.4 and run the usual tests with
>> jcifs.smb.client.useExtendedSecurity=false and
>> jcifs.smb.lmCompatibility=0 against NetApp and an old version of
>> Samba.
>>
>> But I'm a little busy with other things right now so this might take a
>> week or so.
>
> Have you had a chance to look at this at all?  Have you had any thoughts on what it
> might be?

All versions of JCIFS released after replying to this the last time
have been recompiled with Java 1.4. I think the last two versions at
least were compiled with Java 1.4. And I tested and confirmed NTLMv1
behavior with Java 1.4 w/o RC4 and confirmed that it works.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/