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

[Darren Taft]

> > In the non-Kerberos package (jcifs-1.2.25.jar) the domain based DFS works fine, but the dodgy
> server does not.
> 
> How does the "dodgy server" not work? What is the error?

jcifs.smb.SmbException: Transport1 timedout waiting for response to
SmbComSessionSetupAndX[command=SMB_COM_SESSION_SETUP_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0xC003,signSeq=0,tid=0,pid=63098,uid=0,mid=5,wordCount=13,byteCount=111,andxCommand=0x75,andxOffset=172,snd_buf_size=16644,maxMpxCount=10,VC_NUMBER=1,sessionKey=0,passwordLength=24,unicodePasswordLength=24,capabilities=4180,accountName=myuser,primaryDomain=mydomain,NATIVE_OS=Windows
XP,NATIVE_LANMAN=jCIFS]
jcifs.util.transport.TransportException: Transport1 timedout waiting for response to
SmbComSessionSetupAndX[command=SMB_COM_SESSION_SETUP_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0xC003,signSeq=0,tid=0,pid=63098,uid=0,mid=5,wordCount=13,byteCount=111,andxCommand=0x75,andxOffset=172,snd_buf_size=16644,maxMpxCount=10,VC_NUMBER=1,sessionKey=0,passwordLength=24,unicodePasswordLength=24,capabilities=4180,accountName=myuser,primaryDomain=mydomain,NATIVE_OS=Windows
XP,NATIVE_LANMAN=jCIFS]
        at jcifs.util.transport.Transport.sendrecv(Transport.java:76)
        at jcifs.smb.SmbTransport.send(SmbTransport.java:619)
        at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:288)
        at jcifs.smb.SmbSession.send(SmbSession.java:233)
        at jcifs.smb.SmbTree.treeConnect(SmbTree.java:161)
        at jcifs.smb.SmbFile.doConnect(SmbFile.java:850)
        at jcifs.smb.SmbFile.connect(SmbFile.java:893)

> >  I'm unable to use the regular 1.3.* package as it complains of a missing
> java.lang.StringBuilder (Java 1.5 or later required).
> 
> What do you mean by "complain"? Did you mean a stack trace? If yes,
> post it. Let's see line numbers and file names.
> 
> BTW, no version of JCIFS has ever used the java.lang.StringBuilder.

Although you've never directly used StringBuilder, the JCIFS package was compiled using Java 1.5+.
 This changed your "String" + "String" references to use StringBuilder.  I've recompiled JCIFS
1.3.3 using Java 1.4 and this reference is now gone.  See below for my results with this
newly-compiled version.

> There's a saying "if you don't know what you're doing, do it neatly".
> You're not being very systematic about this. First, take WebLogic out
> of the picture. Execute examples/ListFiles.java on the commandline.
> That way you have a simple isolated test case. Then incrementally try
> different VMs, different versions of JCIFS, etc. Then try the same
> thing with WebLogic. If it works on the commandline and it doesn't
> with WebLogic then maybe WebLogic is the problem. See?

The reason I've not tested it outside of WebLogic and JRockit so far is because that's the
constant - the single item in this entire scenario that cannot change.  I can see how proving that
it works outside of that environment would be useful to you, but I hadn't considered useful to me
which is why I hadn't tried it so far.  I'd methodically tested 4 different versions of JCIFS with
3 scenarios each (standard server, domain-based DFS, dodgy server), and those are the results I've
given so far.

So - testing outside of WebLogic now (which I must admit is a LOT easier!):

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)
JRockit 1.4 - As per Sun JRE 1.4

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)
JRockit 1.4 - As per Sun JRE 1.4

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?

Cheers,

darren