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

[Michael B Allen]

On Thu, Feb 26, 2009 at 12:16 PM, Darren Taft <daztop at rocketmail.com> wrote:
>
>> > 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.

Whoops. I didn't mean to do that. I should definitely still be
compiling with 1.4.

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

That is a much better analysis.

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.

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

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

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

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.

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.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/