problem accessing domain-based DFS with kerberos auth

[Stefan Metzmacher]

Hi Aurélien,


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

Can you make a capture of everything the (windows) client does starting
with the boot
from the bios.

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

This would sugguest that the client could use

cifs/ws2016.suse.de/suse.de

But it I don't think that's what is really used.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170111/324384a7/signature.sig>