Hi Jacob, On 01/08, Jacob Shivers wrote:
Hello Enzo, Thank you for the response!
Thanks for elaborating.
I failed to mention the initial aspect that is specific to mounting a domain based DFS share. This would contact a random domain controller instead of a DC local to the calling client's site, should it exist. A CLAP ping like that used by SSSD[0] could be used to identify the nearest domain controller prior to initiating a subsequent mount request. This is where the DNS discovery for a ldap entry would be applicable. Hope that helps to clarify the use case.
This is pretty much what I had in mind, but I still see it as a server-side situation, both from the spec side, as from a personal POV. The DC the client connects to should have all the info in-place and ordered (either by site location or by cost) to return to the client, where it will contain the highest priority target as the first entry on the list (that will probably not be itself, see below). On Windows Server, you can create a registry key [0] on the DC to force to put the logon server (the server the client is authenticated to) as the topmost entry on the DC referrals list. This behaviour is disabled by default, and the reason (as I understand), just like your proposal, is because it would defeat the transparency that DFS offers; the client would be "forced" (either by manual input or by discovery) to know beforehand where it's connecting to, where MS-DFSC shows that the client shouldn't be aware of such details. I haven't tested, but I would expect the DC I'm connecting to to offer the closest targets, no matter if on the same domain, different domain/same forest, or even in a forest-forest (with a trust relationship) scenario. Do you have a practical test case where this doesn't happen? OS type and version, along with an overview of the DFS setup would be helpful to analyze as well. [0] add/set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\PreferLogonDC (DWORD) to 1 Cheers, Enzo
