[jcifs] Version 1.3.1 bug (and fix)
Michael B Allen
ioplex at gmail.com
Wed Dec 3 18:31:18 GMT 2008
On Wed, Dec 3, 2008 at 6:44 AM, <John.Baker at barclayscapital.com> wrote:
> I think I've found a bug in version 1.3.1 when using the NtlmHttpFilter.
> Having configured the system and watched it work, I then configured
> Restarted and it failed with this exception:
> jcifs.smb.SmbException: NTLMv2 requires extended security
> (jcifs.smb.client.useExtendedSecurity must be true if
> jcifs.smb.lmCompatibility >= 3)
> at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:295)
> at jcifs.smb.SmbSession.send(SmbSession.java:234)
> at jcifs.smb.SmbTree.treeConnect(SmbTree.java:161)
> at jcifs.smb.SmbSession.interrogate(SmbSession.java:83)
> at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:157)
> at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:121)
> (Be sure to start a new browser window.)
> Looking at NtlmPasswordAuthentication:
> private static final int LM_COMPATIBILITY =
> Config.getInt("jcifs.smb.lmCompatibility", 3);
> That is clearly wrong as it sets the compatibility when the class is
> first created (but I guess, never again). Hence, when the logging
> occurs, the value is set incorrectly and before it's been reset by the
> Removing 'static' fixes the problem.
Actually I didn't think you could even set the log.level from within
the filter. Ok.
Setting things when the class is first loaded is not "clearly wrong".
On Windows systems lmCompatibility is set in the registry and is
therefore a global fixed value.
But clearly it would be better to make some of these properties
dynamic. Unfortunately the code is simply not organized for this
property to be dynamic. The Config class is static and global so if
one thread sets lmCompatibility to 3 another thread could come a long
and set it to 0 before the first thread tried to use it. There needs
to be a Map of properties or context containing said map that is
passed around throughout the API or perhaps associated with the
thread. But that's not something that is going to change in 1.x.
One thing you could do is to set things on the command like using
-Djcifs.smb.lmCompatibility=0. Or better still set the properties file
on the commandline like -Djcifs.properties=jcifs.prp so that you can
add and remove properties to that file instead of those abominable XML
configuration files. At any rate, those commandline properties are
loaded when the Config class loads so it should be sufficient to work
around the problem.
Also note that so far JCIFS 1.3 offers no real benefits over 1.2 wrt
the Filter. The JCIFS NTLM HTTP Filter does not support NTLMv2 (and
can never support NTLMv2) and there are otherwise no Filter related
fixes in 1.3 releative to 1.2.25 (aside from a fix for something that
was broken in 1.3.0).
Michael B Allen
PHP Active Directory SPNEGO SSO
More information about the jcifs