[Samba] Authentication problems using libsmbclient to traverse DFS links

[Avinash]

Hi,

I'm trying to create a map of DFS links to actual server/share's.
I know that you can get this information by logging on to the DFS root
server, but I'm trying to use the libsmbclient API to
get this information.

I have created a fairly simple DFS structure on 2003 servers with
everything on the same domain.

//MyDomain/DFSRoot

	/Link1	-> //Fileserv-1/FileShare1


	/Link2	-> //Fileserv-2/FileShare2

On the command line I can traverse the DFS tree without any problems,
so using smbclient I can perform the following steps:

 # smbclient //10.4.1.107/DFSRoot -A

./credfile
 Domain=[ENG-DEV] OS=[Windows Server 2003 3790]
Server=[Windows Server 2003 5.2]
 smb: \> ls

.
D        0  Thu Mar 29 12:52:35
2007
..
D        0  Thu Mar 29 12:52:35

2007
Link1
D        0  Thu Mar 29 12:46:43
2007
Link2
D        0  Thu Mar 29 12:52:35
2007

65389 blocks of size 65536. 36670 blocks available

smb: \> showconnect
 //Fileserv-1/DFSRoot


 smb: \>
cd Link1
 smb: \Link1\> ls

.
D        0  Thu Mar 29 12:43:19
2007
..
D        0  Thu Mar 29 12:43:19
2007

List.xls A    25088  Sat
Jan  7 23:03:18 2006

  .
  .
  .



smb: \Link1\> showconnect
//Fileserv-1/FileShare1

smb:
\Link1\> cd ../Link2

smb: \Link2\> ls
.
D        0  Thu Mar 29 12:40:14
2007
..

D        0  Thu Mar 29 12:40:14
2007
abs-guide.pdf  A  2069818  Thu Mar 29 12:39:04
2007
 .
 .
 .

sag.pdf        A
869300  Thu Mar 29 12:40:14 2007



65389 blocks of size 65536. 36659 blocks available

 smb:
\Link2\>
showconnect
 //Fileserv-2/FileShare2
 smb:
\Link2\>


However, problems ensue when I try to connect using the smbc_open and
smbc_opendir functions.
Tracing execution under gdb I see that my authentication callback
function is being called every time I use the smbc_opendir
function (that's good).  I can authenticate without any problems to
the DFS root,but the problem occurs when Samba tries to
traverse the DFS tree. In this case the original server/share (i.e. of
the DFS root) is not the server/share of the DFS link.

When the code follows the path of the link, all the original
authentication information is lost.  My username, password, and
workgroup are all changed to my Unix username and the workgroup that
I've defined in smb.conf.  I'm prompted for a password from
the do_connect function and authentication to the server/share fails.

Using
a simple program to perform a recursive list of the contents under my
DFS root with the libsmbclient interface here's my output:
****
$ ./smblister smb://10.4.1.107/DFSRoot

Opening
(smb://10.4.1.107/DFSRoot)...
Authentication function:
Connection opened with smbc_opendir().
Opening
(smb://10.4.1.107/DFSRoot/Link1
)...
Authentication function:
Password:
tree connect failed: NT_STATUS_ACCESS_DENIED
Unable
to follow dfs referral [//Fileserv-1/FileShare1]
Could not resolve
\Link1\*
Could not open [
smb://10.4.1.107/DFSRoot/Link1] (2:No such
file or directory)
Opening (smb://10.4.1.107/DFSRoot/Link2)...
Authentication function:
tree connect failed:
NT_STATUS_ACCESS_DENIED

Unable to follow dfs referral
[//Fileserv-2/FileShare2]
Could not resolve \Link2\*
Could not
open [smb://10.4.1.107/DFSRoot/Link2] (0:Success) *****

 One

difference between the two scenarios is that in the first case the
cli_cm_set_credentials function is being called in the second case
it's not.  I'm not sure, but should the authentication callback
function be used when resolving a DFS path?  I'm still looking
into where the defaults are set and if it's possible to get
authentication info that's not statically defined.

I also saw that I can define the /etc/samba/smbusers to map a Unix
user name to a Windows login and tried this, but my default
username is still the Unix one.  I also uncommented the username map
line in smb.conf.

Thanks for looking at this...

Regards,
Avinash