Handling in an elegant and efficient way SPN cifs/realm

[Matthieu Patou]

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
>
>