Bug 8003 - DFS Referral requesting does not work to w2k8 servers
DFS Referral requesting does not work to w2k8 servers
Status: NEW
Product: Samba 3.5
Classification: Unclassified
Component: Client Tools
3.5.8
All All
: P5 normal
: ---
Assigned To: Volker Lendecke
Samba QA Contact
:
Depends on:
Blocks: 10289
  Show dependency treegraph
 
Reported: 2011-03-10 09:34 UTC by Sean Finney
Modified: 2016-01-07 14:08 UTC (History)
8 users (show)

See Also:


Attachments
Proposed fix (3.16 KB, patch)
2011-03-14 11:00 UTC, Sean Finney
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sean Finney 2011-03-10 09:34:46 UTC
FYI, this was tested on ubuntu lucid's version of samba, as well as the latest git versions in the 3.5 and 3.6 stable trees.

We have a DFS setup for ourdomain.net, where the dns name ourdomain.net
is round-robin load balanced between about 20 servers.  The servers are
a mix of win2k8 and win2k3.

When a client (mount.cifs, smbclient) resolves the dns name to what is
a 2k3 server, it is able to connect/mount the DFS share "/site/project"
without problem.  However, if it picks a 2k8 server, it fails with
STATUS_BAD_NETWORK_NAME.

I have a network dump of the good and bad connections, though it contains
sensitive customer data so I can't really post it on a public ml/bugtracker.
I'll append the summary below though, and if there's any specific
questions I can provide more info and/or see about forwarding the dump
out-of-band.

The juicy difference between the good/bad is is at the point that the
client sends a Trans2 Request to GET_DFS_REFERRAL.  The 2k3 server
responds back with a list of referrals to fileservers/locations for
"site/project", whereas the 2k8 server responds with STATUS_NOT_FOUND
(and the client then has some kind of fallback upper case attempt
afterwards).

Packet Summary (working):

Source  Destination  Protocol Info
client  w2k3         Negotiate Protocol Request
w2k3    client       Negotiate Protocol Response
client  w2k3         Session Setup AndX Request, NTLMSSP_NEGOTIATE
w2k3    client       Session Setup AndX Response, NTLMSSP_CHALLENGE, Error: STATUS_MORE_PROCESSING_REQUIRED
client  w2k3         Session Setup AndX Request, NTLMSSP_AUTH, User: OURDOMAIN\userid
w2k3    client       Session Setup AndX Response
client  w2k3         Tree Connect AndX Request, Path: \\ourdomain.net\IPC$
w2k3    client       Tree Connect AndX Response
client  w2k3         Trans2 Request, GET_DFS_REFERRAL, File: \ourdomain.net\site\project
w2k3    client       Trans2 Response, GET_DFS_REFERRAL
client  w2k3         Tree Disconnect Request
w2k3    client       Tree Disconnect Response

Packet Summary (broken):

Source  Destination  Protocol Info
client  w2k8         Negotiate Protocol Request
w2k8    client       Negotiate Protocol Response
client  w2k8         Session Setup AndX Request, NTLMSSP_NEGOTIATE
w2k8    client       Session Setup AndX Response, NTLMSSP_CHALLENGE, Error: STATUS_MORE_PROCESSING_REQUIRED
client  w2k8         Session Setup AndX Request, NTLMSSP_AUTH, User: OURDOMAIN\userid
w2k8    client       Session Setup AndX Response
client  w2k8         Tree Connect AndX Request, Path: \\ourdomain.net\IPC$
w2k8    client       Tree Connect AndX Response
client  w2k8         Trans2 Request, GET_DFS_REFERRAL, File: \ourdomain.net\site\project
w2k8    client       Trans2 Response, GET_DFS_REFERRAL, Error: STATUS_NOT_FOUND
client  w2k8         Tree Disconnect Request
w2k8    client       Tree Disconnect Response
client  w2k8         Tree Connect AndX Request, Path: \\ourdomain.net\SITE\PROJECT
w2k8    client       Tree Connect AndX Response, Error: STATUS_BAD_NETWORK_NAME


I have also done a packet dump from a windows 7 client, talking to both the win2k3 and win2k8 servers.  The first big difference that I note is that to the win2k3 server, it asks for a referral for \ourdomain.net\site, not ourdomain\site\project .  When connecting to a w2k8 server, it seems to use some SMB2 Ioctl not known by wireshark, but the data payloads seem to contain the equivalent referral data.  I don't think the SMB2 ioctl usage is a strict requirement though, as I can use smbclient to connect to just "//ourdomain/site" on a w2k8 server, it seems to work fine.  I can not, however, mount just "site" from mount.cifs.

So it seems to me that the behavior in samba client programs should look for DFS referrals at the top-level directory first, and then maybe work their way down if you're allowed to have dfs shares deeper in a directory structure (I'm not super familiar with the spec here, so I don't know if that's allowed).

I hope this makes sense, please let me know if you need any further info.  I'm also on #-technical if you want any info out-of-band like mentioned above.
Comment 1 Sean Finney 2011-03-14 11:00:26 UTC
Created attachment 6287 [details]
Proposed fix

Please note that this talloc stuff is a bit foreign to me so I am probably not doing things correctly in that respect, or at least it probably deserves a looking over.

From the patch:

In some scenarios (limited to win2k8 from our testing), attempting
to resolve a DFS path with a Trans2 GET_DFS_REFERRAL request will
fail if the path includes subdirectories not part of the DFS path.

To work around this problem, if a server does not return any DFS
referrals for a given share/path, try once again for the "split"
path containing only the top-level share name.  If this is successful,
then follow the referral and append the "extra" split-off path back
onto the path before returning to the caller.

While a more robust solution is probably needed, it would likely require
significant code shuffling and thus I leave that for someone more
familiar with the code.  The workaround should hopefully be acceptable
in the meantime.
Comment 2 Jeff Layton 2011-03-14 13:49:33 UTC
Ahh sorry, grabbed this by mistake thinking it was against cifsfs.
Comment 3 Felipe Pereira 2015-01-27 22:11:54 UTC
Gentlemen, 
Here at my company we have a mixed Windows+Linux environment and some scripts use smbclient put operations. We use Red Hat Linux 5 in most servers and hit this bug recently as we are updating our domain controllers. We tried RHEL6 with samba4 as well and the same error occurred.
Could this fix make into the main version?
Comment 4 Michael Adam 2016-01-06 18:04:17 UTC
seems to be very similar to bug #10289