[Samba] domain-based DFS ?

Sun Jul 6 23:45:54 MDT 2014

Dear all,
as i mentioned in this thread: since the alpha samba4 has ended it was not possible!!!! anymore to
reach a share, ex.: \\your.samba4domain\share without this errors. I myself think it is bug and it should be covered by the
samba technical. The only workaround I found is to  run a samba3 old style domain and within this domain you have no trouble
with pointing to \\your.samba4domain\share . It could be it is an issue with smb3.

Greetings 
Daniel 

EDV Daniel Müller

Leitung EDV
Tropenklinik Paul-Lechler-Krankenhaus
Paul-Lechler-Str. 24
72076 Tübingen 
Tel.: 07071/206-463, Fax: 07071/206-499
eMail: mueller at tropenklinik.de
Internet: www.tropenklinik.de

"Der Mensch ist die Medizin des Menschen" 

-----Ursprüngliche Nachricht-----
Von: samba-bounces at lists.samba.org [mailto:samba-bounces at lists.samba.org] Im Auftrag von Davor Vusir
Gesendet: Sonntag, 6. Juli 2014 06:14
An: Henrik Langos
Cc: samba at lists.samba.org
Betreff: Re: [Samba] domain-based DFS ?

2014-07-02 18:48 GMT+02:00 Henrik Langos <hlangos-samba at innominate.com>:
> On 07/02/14 09:28, Davor Vusir wrote:
>>
>>
>>>
>>> On our config it treats the domain as the name of the server! 
>>> Anyway, thanks for your time. We can't spend any longer with this as 
>>> we are looking for a solution.
>>> Thanks again,
>>> Steve
>>>
>> Added uid, uidnumber and gidNumber to every account and group.
>> Resulted in access denied to \\vusir.local\dfs\share and home 
>> directory.
>>
>> Commented 'idmap_ldb:use rfc2307 = yes'. No change.
>>
>> Removed uid, uidNumber and gidNumber from relevant accounts and 
>> access groups. No change.
>>
>> Removed uid, uidNumber and gidNumber from all accounts and access 
>> Groups. No change.
>>
>> Reactivated 'idmap_ldb:use rfc2307 = yes'. No change.
>>
>> A couple of restarts of the Windows 7 client, AD DC restarts and a 
>> server reboot. Back in business.
>
>
> Hi Davor,
>
> This pretty much matches my observations with domain based dfs. It's a 
> hit and miss with lots of poking around in the dark.
>
> Occasionally it works and all looks very nice, but then on the next 
> login it might fail again. For me it was mostly failing.
> (But then again I suspect it had to do with my removing one of the AD 
> DCs and downgrading it to a normal member server. I've seen the former 
> AD pop up in one of the DFS tabs as dfs root even though it wasn't a 
> DC any more.)
>
> Once DFS failed in the observed way, there is no point in logout/login 
> cycles.
> The only thing that *sometimes* helps is a complete reboot of the 
> client and hoping for the best.
> This makes debugging the problem a very frustrating and time consuming 
> business.
>
> Also smbclient and windows 7 show very different behavior.
> In smbclient I can always at least see the dfs directory but access to 
> the visible shares will fail.
>
> $ smbclient -U sample12 '\\domain.local\dfs'
> Enter sample12's password:
> Domain=[DOMAIN] OS=[Unix] Server=[Samba 4.1.9-Debian]
> smb: \> ls
>   .                                   D        0  Mon Jun 30 20:53:09 2014
>   ..                                  D        0  Thu Jun 26 13:17:10 2014
>   test2                               D        0  Mon Jun 30 18:08:11 2014
>   test                                D        0  Mon Jun 30 10:20:23 2014
>
>                 64514 blocks of size 32768. 30984 blocks available
> smb: \> ls test
> session setup failed: NT_STATUS_LOGON_FAILURE Unable to follow dfs 
> referral [\shares01\test]
> do_list: [\test] NT_STATUS_PATH_NOT_COVERED
> smb: \>
>
> In Windows 7 I can see the dfs share when I go to \\domain.local\ but 
> changing into that \\domain.local\dfs share results in an error.
>
> In contrast to this, access via \\addchost.domain.local\dfs works 
> reliably from Windows and smbclient alike.
> Using this form I can even use smbclient with Kerberos authentication.
> (which fails for "domain.local" as there is no service principle for 
> cfis/domain.local at DOMAIN.LOCAL in the Kerberos database.)
>
> I'll put that topic away for now.
>
> cheers
> -henrik
>
>
Hi Henrik,
you're right. Eventually it decays to what you describe. Eroding, maybe. It's very annoying, because if it works with the netlogon and sysvol shares, it has to work with a domain-based DFS.

Below are the latest changes I made to smb.conf.

I also configured WINS-server on the client and enabled NetBIOS in the TCP/IP Control Panel.
When I enabled NetBIOS in the TCP/IP Control Panel I got the access error. I can't recall how I fixed that but it might be a good idea to edit ACLs on the DFS share.

And while you're at it, why not add WINS...

I'm wondering how much I'm violating the AD DC...

Perhaps it was the 'allow insecure wide links = yes' that made it work. Well... it's still working.

Regards
Davor

# Global parameters
[global]
        host msdfs = yes
        interfaces = 192.168.1.3/24
        bind interfaces only = yes
        wins support = yes
        wins server = 192.168.1.3
        allow insecure wide links = yes
[files]
        path = /data/files
        comment = "Här finns allt!"
        read only = No
        vfs objects = acl_xattr
        msdfs root = yes
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba