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

[Darren Taft]

> > 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.

> > 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.

> 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?

Cheers

darren