DFS failure about jcifs-ng HOT 14 CLOSED

Hi,

So if you directly connect to the DFS target share that works? On first sight that does not seem to be that much DFS related but more like a general signing problem during session setup with the target.

Are both the DFS share and the target are on the same server? What kind of server(s)?

Could you provide a packet trace of the exchange? That would probably help alot to track down what happens there. Debug logs could be of some help, too.

from jcifs-ng.

Hi mbechler,

I will conduct the tests you mentioned.

How can i enable debug logging?

Thanks

from jcifs-ng.

Depends on the SLF4J logger backend implementation you are using (log4j1, log4j2, ...). In most cases you would have some config file where you can set the logging level for the jcifs package to DEBUG.

from jcifs-ng.

Hi,

For a reason i ignore, SmbResourceLocator.handleDFSReferral was returning a incorrect path.
Commenting this block solved the issue:

if ( this.dfsReferral != null ) {
            return this.unc;
        }

from jcifs-ng.

Any chance there is a DFS link pointing into (the same or another) DFS involved? Can you provide some details how the links are set up, maybe I'm able to reproduce this then.

Still that should not result in a signature validation error, so we might be looking at two separate issues here. Packet trace and debug log would be great.

from jcifs-ng.

So I finally dug a litte through the code to see what could be going wrong there. The shortcut was obviously incorrect if multiple different referrals are received for the same resource (or a child receives a different referral than it's parent). The obvious situtation where this could happen if a link points into a DFS again.
If that's the case in your situtation I think this should now be fixed in master, along with some efficiency improvments for that situtation (as far as I can tell that would have resulted in requests doing two roundtrips).

If it does not help, I'll definitively need more info on this.

Also I'd really like to figure out what is the actual cause of that signature validatation error before doing a proper release.

from jcifs-ng.

Hi mbecher,

Thank you for your work. I managed to get it to work with all the fix you did regarding DFS links.
However, i had to fix the following:

My program was failing on Path not found exception because i have notice the path was not adjusted after DFS target has been resolved. Problem was coming from:

SmbTreeConnection.resolveDfs0 : 669
if ( t.isInDomainDfs() )

This condition returns false and i assume it should return true because my target is a DFS link.

I have noticed the connectTree method was not marking the domainDFS tag:

if ( referral != null && referral.getShare() != t.getShare() ) {
   t.markDomainDfs();
}

This condition was false because referral.getShare() == t.getShare()

By removing referral.getShare() != t.getShare(), it is working fine so far.

I would like to send you the logs but i work in a highly confidential company and they are freak about data leakage. I am going to check if i can replace all sensitive information by fake one.

from jcifs-ng.

Ouch, that check is pretty wrong anyhow (==). I remember having added that when resolving some issue listing the links on a DFS share itself, but that looks fine even removing the check, so this obviously wasn't the cause for the problem I was hunting there - seems it's okay to remove it. Tests are fine without it.

Can you still provide some details on the DFS layout (what kinds of servers are involved, standalone/domain, what the links look like) so that I can possibly reproduce that (my test cases had not show these issues even though I have a couple of DFS configurations in it) and add test cases to prevent regressions?

If you cannot share packet traces/debug logs, maybe you can answer a couple of questions regarding the signature verification failure.

1. how did the wrong UNC/URL look like that was produced by the UNC bug?
2. what kind of server/share was that pointing to?
3. directly connecting (e.g. an exists() call) to that UNC produces the same error?
4. I added new logging for cases where a signature is expected, but the server did not sign, does that get triggered?
5. (if 4.) does not throwing the exception in SmbSessionImpl:646 change anything, or will signature validation then fail on the next packet?

from jcifs-ng.

Hi,

Here are the news of the day. I am NOT GOING to talk about signature in this message, i will do it in another one.

About the wrong condition if ( referral != null && referral.getShare() != t.getShare() ) please not there is a second occurence of it to fix at SmbTreeConnection:606 (credentials renewal).

After having tested my program under Windows, i have deployed it on my Linux box, and i ran into the problem of path not adjusted again. The difference i have noted in the logs between my Windows workstation and myLinux box is the share was NOT marked as in Dfs (inDomainDfs=false) on the Linux box.

I actually noticed in the logs that the Windows domain of user credentials was not reachable as is from my Linux box because of a DNS problem:

2017-07-18 20:35:06 DEBUG DfsImpl:208 - Getting domain controller for FOO failed
java.net.UnknownHostException: FOO
	at jcifs.netbios.NameServiceClientImpl.getAllByName(NameServiceClientImpl.java:1022)
	at jcifs.netbios.NameServiceClientImpl.getAllByName(NameServiceClientImpl.java:1)
	at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:170)
	at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:1)
	at jcifs.smb.DfsImpl.getDcReferrals(DfsImpl.java:189)
	at jcifs.smb.DfsImpl.getDc(DfsImpl.java:234)
	at jcifs.smb.DfsImpl.getTrustedDomains(DfsImpl.java:112)
	at jcifs.smb.DfsImpl.resolve(DfsImpl.java:348)
	at jcifs.smb.DfsImpl.resolve(DfsImpl.java:322)
	at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:504)
	at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:453)
	at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:414)
	at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:611)
	at jcifs.smb.SmbFileOutputStream.<init>(SmbFileOutputStream.java:112)
	at jcifs.smb.SmbFileOutputStream.<init>(SmbFileOutputStream.java:101)
	at jcifs.smb.SmbFileOutputStream.<init>(SmbFileOutputStream.java:76)

After having fixed the DNS problem on my server, this exception was gone and my target share was correctly marked as in DFS domain, causing the path to be adjusted correctly and working.

Let me explain this path adjustment problem.

Lets say i have this initial UNC path:

\Server1\Apple\Banana\Cherry\Strawberry\Pear\Temp

\Server1\Apple\Banana\Cherry\Strawberry part is actually a DFS link targeting:

\TargetServer\Strawberry$

Problem was it was trying to access:

\TargetServer\Strawberry$\Banana\Cherry\Strawberry\Pear\Temp

With correctly marked as DFS, path is adjusted to

\TargetServer\Strawberry$\Pear\Temp

from jcifs-ng.

About the wrong condition if ( referral != null && referral.getShare() != t.getShare() ) please not there is a second occurence of it to fix at SmbTreeConnection:606 (credentials renewal).

Thx. Fixed.

So FOO is your users short domain name, right? Is Server1 a domain (!= FOO?) name or a server name? Domain/standalone DFS is handled quite differently (domain DFS is looked up upfront, standalone DFS only after the server responds with a special error status).

If Server1 was actually a domain name, then this would make some sense (otherwise I don't see how the behaviors could be different just because the DC cannot be resolved). If the DC lookup and therefore DFS root lookup fails we fall back to the standalone behavior (resolve follow the referral after receiving a status indicating that we should).

I think I found the error when handling standalone (or fallback) referrals, connectHost did the lookup with the already adjusted location, therefor did not find a referral and did not mark the tree accordingly.

from jcifs-ng.

Hi,

Yes indeed. FOO is the domain name used in the credentials to connect to the share. FOO\MyUser
And yes, Server1 is a domain name, but different from FOO.

from jcifs-ng.

FOO trusts Server1 then? Then it makes sense, and I might have found the right bug ;)

from jcifs-ng.

Hi, that is correct, FOO trusts Server1

from jcifs-ng.

Thanks for the answers it was very helpful for me.
Below the two ways to implement for different SMB versions using jcifs-ng.

// Option 1 - SMB2 and SMB3:
Properties prop = new Properties();
prop.put( "jcifs.smb.client.enableSMB2", "true" );
prop.put( "jcifs.smb.client.disableSMB1", "false" );
prop.put( "jcifs.traceResources", "true" );
Configuration config = new PropertyConfiguration(prop);
CIFSContext baseContext = new BaseContext(config);
CIFSContext contextWithCred = baseContext.withCredentials(new NtlmPasswordAuthentication(baseContext, domain, fileSystemInfo.getUsername(), fileSystemInfo.getPassword()));
SmbFile share = new SmbFile(fullPath.replace('\', '/'), contextWithCred);
if (!share.exists())
{
share.mkdirs();
}
share.close();

// Option 2 - SMB1 and CIFS:
SingletonContext context = SingletonContext.getInstance();
CIFSContext testCtx = context.withCredentials(new NtlmPasswordAuthentication(context, domain, fileSystemInfo.getUsername(), fileSystemInfo.getPassword()));
SmbFile smbFile = new SmbFile(fullPath.replace('\', '/'), testCtx);
if (!smbFile.exists())
{
smbFile.mkdirs();
}
smbFile.close();

from jcifs-ng.