Hello Enzo, Sorry for the delay in response. To further clarify the use-case it is not pertaining to the target shares, but concerning the namespace server that we connect to as part of the initial mount for the domain based DFS share. Assume an environment with some N number of DCs where each DC is in their own site, a DFS namespace member for the same namespace, and the domain resolves to each DC in a round-robin. Condition #1 For AD client site members that are in the same subnet as the site local DC, we only ever connect to said DC when mounting a domain based DFS share. Condition #2 For AD client site members that are *not* in the same subnet as the site local DC, we connect to a DC that the domain name resolves to, site local DC, and then the SMB target. We have a 1/N chance of connecting to the site local DC initially which is not desirable. For condition #2, we could be potentially connecting to DCs that could be prohibitively far geographically and incur a non-trivial delay with possible timeout. While certainly the appeal of a domain based DFS mount is the abstraction to know which SMB server to access, condition #2 can yield mount issues when the AD client does not have the capacity/opportunity to add a DC to the subnet for whatever reason. This could include heavily siloed environments, separate teams, or cross vendor interactions. I could see a use-case where should the SMB client want to limit which DCs to connect to, with the intent to exclude non-desirable DCs, a flag be passed that invokes a CLDAP ping to affect such a change. This can already be done with a hacky wrapper script, but I am curious as to what level of interest there would be for a more durable implementation. Hope that helps to clarify the situation and please ask any follow-up questions should you or anyone else have any. Regards, Jacob Shivers On Mon, Jan 8, 2024 at 7:56 PM Enzo Matsumiya <ematsumiya@xxxxxxx> wrote: > > 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 >
