Authentication problems using libsmbclient to traverse DFS links

[rbrowne at estreet.com]

Hi,

This was posted this morning on the general Samba list
this morning, but I was advised
to post it here too.  I'm adding a
little more info ...
 
 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,
 
 Rich