Domain DFS implementation in s4 was: Re: Handling in an elegant and efficient way SPN cifs/realm

Tue Apr 27 14:58:50 MDT 2010

I updated this branch !

I'm still lacking the sysvol resolution so for instance it didn't work 
in w7.
But comment on the code is welcomed, it still needs some polish.

On 26/04/2010 01:36, Matthieu Patou wrote:
> Hi all,
>
> I started to code on this :
> http://repo.or.cz/w/Samba/ekacnet.git/shortlog/refs/heads/dfs
>
> For the moment I have the first part right I just need to send the 
> list of the DC.
>
> The code is very raw, it compiles but it's unsafe for the moment to 
> run it as the DC part is half (or 2/3) coded.
>
> I hope to have a working code for simple domain within a couple of days.
> Stay tunned !
>
> Matthieu.
> On 01/09/2009 00:30, Matthieu Patou wrote:
>> Hello,
>>
>> it seems that the interesting part is here:
>>
>>
>>        Referral Process for Domain-based Namespaces
>>
>> The referral process for domain-based namespaces is as follows:
>>
>>   1. A user attempts to access a link in a domain-based namespace, such
>>      as by typing \\Contoso.com\Public\Software in the *Run* dialog box.
>>   2. The client checks its domain cache for an existing domain name
>>      referral for the Contoso.com domain. If this referral is in the
>>      domain cache, the client proceeds to step 3. If no domain name
>>      referral is in the domain cache, the client connects to the IPC$
>>      shared folder of the active domain controller in the context of
>>      the LocalSystem account and sends a domain name referral request
>>      with a null string. The domain controller returns the list of
>>      local and trusted domains to the client.
>>   3. The client checks its referral cache for the longest prefix match
>>      from a previous referral. This might be a root referral
>>      (\\Contoso.com\Public) or a link referral
>>      (\\Contoso.com\Public\Software). If the client finds a valid
>>      entry, it goes to step 5 or 6 depending on the type of the
>>      referral. If not, the client continues to the next step.
>>   4. The client checks its domain cache for an existing domain
>>      controller referral for the Contoso.com domain. If this referral
>>      is in the cache, the client proceeds to step 5. If no domain
>>      controller referral is in the domain cache, the client connects to
>>      the IPC$ shared folder of the active domain controller in the
>>      context of the LocalSystem account and sends a domain controller
>>      referral request containing the appropriate domain name
>>      (Contoso.com). The domain controller returns the list of domain
>>      controllers in the Contoso.com domain. The domain controllers in
>>      the clients site are at the top of the list. If least-expensive
>>      target selection is enabled, domain controllers outside of the
>>      targets site are sorted by lowest cost. If same-site target
>>      selection is enabled, DFS ignores this setting and lists the
>>      remaining domain controllers in random order.
>>   5. The client checks its referral cache for an existing domain-based
>>      root referral. If this referral is in the cache, the client
>>      proceeds to step 6. If no domain-based root referral exists in the
>>      referral cache, the client connects to the IPC$ shared folder of
>>      the active domain controller in the context of the LocalSystem
>>      account and requests a domain-based root referral. The domain
>>      controller determines the clients site and returns a list of root
>>      targets. By default, the root targets in the clients site are at
>>      the top of the list, followed by the remaining root targets in
>>      random order. If least-expensive target selection is enabled, the
>>      remaining root targets are ordered by lowest cost. If same-site
>>      target selection is enabled, only root servers in the clients site
>>      are listed in the referral.
>>   6. The client chooses the first root target in the domain-based root
>>      referral. The client connects to the root server and navigates the
>>      subfolders under the root folder. When a client encounters a link
>>      folder, the root server sends a STATUS_PATH_NOT_COVERED status
>>      message to the client, indicating that this is a link folder that
>>      requires redirection.
>>   7. The client checks its referral cache for an existing link
>>      referral. If this link referral is in the cache, the client
>>      computer connects to the first link target in the list. If the
>>      link referral is not in the cache, the client connects to the IPC$
>>      shared folder of the root server in the context of the LocalSystem
>>      account and requests a link referral from the root server. The
>>      root server returns a list of link targets. At the top of the
>>      target list are the link targets that are in the same site as the
>>      client. The root server puts the remaining link targets in the
>>      target list using one of the following methods:
>>          * By default, the link targets outside of the clients site are
>>            put in random order.
>>          * If same-site target selection is enabled, the root server
>>            does not add out-of-site link targets to the referral.
>>          * If least-expensive target selection is enabled, the root
>>            server checks its site cost cache to determine whether cost
>>            information exists for the connection between the clients
>>            site and the link targets site. If the site cost data is not
>>            in the cache, the root server contacts the domain controller
>>            acting as the Intersite Topology Generator and uses the
>>            DsQuerySitesByCost API to retrieve site cost data. The root
>>            server then sorts the remaining link targets by lowest cost.
>>
>>
>> I checked on a w2k8 box against a w2k3 DC and that's what is 
>> happening the box do not use make a request for the principal 
>> cifs/domainname
>>
>> The only request for cifs that I see is cifs/dcname.domainname
>>
>> I did more tests with an administrator and during login it's one more 
>> time the described process that occurs.
>> When I tried by entrering manually \\msw2k3.tst\ in windows explorer 
>> then it yield a request for cifs/msw2k3.tst principal and this 
>> principal was unknown from the windows 2003 server. I am willing to 
>> conclude that Windows do not support cifs/domainname principal and 
>> that it's up to samba4 to support the whole domain dfs stuff.
>>
>> I activated dfs on the server (host mdfs = yes) and XP started to 
>> request referal on the IPC$ with no supplied filename.
>> Of course Samba4 replied with an error.
>>
>> Looks like there is stuff to do for samba to implement the DFS for 
>> domains, at the end this article explains quite well the whole thing 
>> that we have to 
>> do:http://technet.microsoft.com/en-us/library/cc782417(WS.10).aspx
>>
>>  But at the begining we can less ambitious and just support domain 
>> dfs without being efficient with the site location.
>>
>> Matthieu.
>>
>>
>>
>> On 08/26/2009 04:36 AM, Andrew Bartlett wrote:
>>> On Wed, 2009-08-26 at 01:55 +0400, Matthieu Patou wrote:
>>>> Hello all,
>>>>
>>>> I rediscover that Windows client are time to times looking for 
>>>> cifs/real
>>>> SPN (ie. cifs/smb4.tst or cifs/SMB4.TST). One quick way to avoid this
>>>> problem is to add this SPN to the list of SPN of the DC.
>>>>
>>>> That's an easy trick and maybe it can be done for the moment until we
>>>> have something a bit more efficient ?
>>>>
>>>> The absence of this SPN cause windows to switch to NTLM so still the
>>>> access is possible.
>>> I asked about this on cifs-protocol earlier this year.  If you could
>>> read the responses, and see if you can make more sense of it than I 
>>> did,
>>> then we can implement that properly.
>>>
>>> http://lists.samba.org/archive/cifs-protocol/2009-June/000778.html
>>>
>>> Otherwise, we might need to ask yet again, because I've never really
>>> understood the replies :-)
>>>
>>> Andrew Bartlett
>>>
>>
>