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

Darren Taft daztop at rocketmail.com
Thu Mar 26 16:55:13 GMT 2009

> >> That server probably just requires NTLMv2. And FYI Windows Server 2008
> >> requires NTLMv2 by default. And many people using Windows 2003 are
> >> starting to require NTLMv2.
> >>
> >> There's nothing wrong. You can't have a server that requires NTLMv2
> >> and another that requires NTLMv1 and expect everyone to work. This is
> >> not just a problem with JCIFS. Any Windows client will have the same
> >> problem.
> >
> > Sorry, but no.  I *can* connect to the server when I *enable* NTLMv2,
> > but it isn't using NTLMv2 (which I know definitely doesn't work in my 
> > Java 1.4 environment).
> That is contradictory. If you enable NTLMv2 and use Java 1.4 you
> should get an RC4 error. If you're saying it works if you use 1.5u7+,
> then it should use NTLMv2 and just work. If that is not the case, then
> do an analysis, post a log, get a capture, etc.

I already have done on this thread.  We seem to be going in circles. The point I keep making is
that when I don't specify "-Djcifs.smb.client.useExtendedSecurity=false
-Djcifs.smb.lmCompatibility=0" (i.e. NTLMv2 is enabled) I *can* connect to the server, but it
definitely *isn't* using NTLMv2.

> So you claim the one server won't work with NTLMv2 disabled but it
> doesn't required NTLMv2. In that case I would need a packet capture to
> verify your claim.

OK - I'll email you seperately with 4 captures, for the 4 scenarios detailed at the end of this

> > It isn't using NTLMv2, but there is something about the NTLMv2
> > code stream that works when talking NTLMv1.
> I don't see how you could have deduced something that but there is
> something called "NTLM2 Session Security" that augments the password
> hash calculation when NTLMv1 is used. What is the NtlmMinServerSec
> registry value on the server? Is it different from the others?

I'll try and find out what that value is set to, but it may take a while.
> Try setting but jcifs.smb.lmCompatibility=0 but do NOT set
> useExtendedSecrurity. If NtlmMinServerSec is not 0 you will need to
> use extended security (in theory this should not break other things
> but be on the lookout as I don't know if I've tested this completely -
> at least not with JCIFS).

That works for the dodgy server - if I don't include the
"-Djcifs.smb.client.useExtendedSecurity=false" setting on the command line, I *can* connect to the
dodgy server.  In this configuration however, I'm unable to use domain based DFS - that fails as
the RC4 cipher isn't available.

For all scenarios that matter:
    XS = Extended Security
    lmC = lmCompatibility

Dodgy server works when:
  XS = unspecified and lmC = 0
  XS = unspecified and lmC = unspecified

Dodgy server doesn't work when:
  XS = false and lmC = 0
  XS = false and lmC = unspecified (invalid config)

Domain based DFS works when:
  XS = false and lmC = 0

Domain based DFS doesn't work when:
  XS = false and lmC = unspecified (invalid config)
  XS = unspecified and lmC = 0 (missing RC4)
  XS = unspecified and lmC = unspecified (missing RC4)

> Also, what exactly is the error or errant behavior that you see with
> this one W2K3 server when you try to use NTLMv1?

See the following URL for a full description of the problem and the scenarios that have been





More information about the jcifs mailing list