problem accessing domain-based DFS with kerberos auth

[Aurélien Aptel]

Hi,

I have an AD running Windows Server 2016 on domain suse.de, it has a
domain-based DFS nameserver so that

  \\suse.de\dfs3 -> \\ws2016.suse.de\dfs3 (same machine, same ip)

This DFS nameserver has a link:

  \\suse.de\dfs3\link -> \\ws2012.suse.de\dfstarget

On a Windows client joined to the domain, I can simply navigate in
\\suse.de\dfs3 in the explorer to reach the final target.

On a linux box joined to the domain, be it with cifs.ko or smbclient I
cannot authenticate on suse.de.

  # kinit Administrator
  Password for Administrator at SUSE.DE: 
  # smbclient //suse.de/dfs3 -k
  ads_krb5_mk_req: smb_krb5_get_credentials failed for cifs/suse.de at SUSE.DE (Server not found in Kerberos database)
  cli_session_setup_kerberos: spnego_gen_krb5_negTokenInit failed: Server not found in Kerberos database
  session setup failed: SUCCESS - 0

Looking at the network trace we can see that the Windows client directly
makes the Tree Connect to \\WS2016.suse.de\dfs3, whereas smbclient makes
it on \\suse.de\dfs3.

This means the Windows machine somehow resolves the suse.de to
ws2016.suse.de before making the tree connect but even after looking at
the trace I couldn't find how (LDAP? DNS? Kerberos? something
encrypted?).

The workaround I found was to add the Service Principal Name smbclient
is using (cifs/suse.de) to the list of authorized for ws2016.

On the AD:
 
    setspn -s cifs/suse.de ws2016
    
After this, smbclient works. Unfortunately I have a customer that says

> the workaround doesn't not work for multiple servers 
>
> spn -s cifs/<domain> <dfs server 1>
> spn -s cifs/<domain> <dfs server 2>
> spn -s cifs/<domain> <dfs server 3>

I don't know how "multiple servers" DFS work. Can you even have
multiple nameservers handling the same dfs share?

If these are multiple identical data shares the nameserver points to,
how come I could use the data share on ws2012 without adding
cifs/suse.de to its the ws2012 account?

Microsoft docs says:

"How Clients Compose a Service's SPN"
https://msdn.microsoft.com/en-us/library/ms676924(v=vs.85).aspx

> The client can retrieve components of the SPN from sources such as a
> service connection point (SCP) or user input. For example, the client
> can read the serviceDNSName attribute of a service's SCP to get the
> "<host>" component.

seems to point to DNS, but no traces of it in my capture. I only see a
query for the A entry of domain ws2012.suse.de where the actual data is
served. Could the query to ws2016 have been made when I logged on the
machine and be cached?

There is a bug report about this here:

"mount.cifs cannot mount a DFS share when using Kerberos authentication"
https://bugzilla.samba.org/show_bug.cgi?id=7257

That points to this discussion here:

https://lists.samba.org/archive/linux-cifs-client/2008-August/thread.html#3348
https://lists.samba.org/archive/linux-cifs-client/2008-August/003357.html

That seems to indicate using the principal provided by the server is
"insecure and should be removed from smbclient" and it is not actually
used by Windows.

On Sun, 2008-08-24 at 23:58 -0400, simo wrote:
> On Sun, 2008-08-24 at 23:49 -0400, simo wrote:
> > On Mon, 2008-08-25 at 02:38 +0100, Love Hörnquist Åstrand wrote:
> > > 25 aug 2008 kl. 02.25 skrev Jeff Layton:
> > > 
> > > > Everything I've read does say that windows clients don't use the
> > > > contents of the MIC field. The idea was that this would be useful for
> > > > allowing kerberos auth in situations where clients and servers have
> > > > differing ideas about the hostname of the server (either broken DNS or
> > > > maybe trying to mount a CNAME).
> > > 
> > > Semi modern windows servers doesn't put a hostname there, so it wont  
> > > be much use either.
> > > 
> > > Windows just assume if you can look up the name, the same name will be  
> > > in the SPN in the ldap.

Yet it seem to work on Windows without DNS somehow.

So, is there a better fix to solve this problem than implementing the
insecure thing or adding a new principal name to the machine account?

-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)