[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
email.
> > 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:
Key:
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
tested:
http://lists.samba.org/archive/jcifs/2009-February/008478.html
cheers,
darren
More information about the jcifs
mailing list