Linux client SMB and DFS site awareness

Linux client SMB and DFS site awareness

[Jacob Shivers]

Hello,

I have a use-case for a Linux SMB client to mount DFS replicated
shares, with a preference for sites that are closer geographically.
DNS site discovery/awareness exists within DFS[0], but I have not read
of any work currently under investigation.

Is anyone actively working on this issue in any capacity? If so, would
they like help in some capacity whether testing/coding?

If this issue is not being actively engaged is there a reason for
this, e.g. low priority, technical complexity/implementation issues,
or some other reason?


I had searched through mailing list archives and found no prior
mention, but I do apologize if this has been discussed and is a
broadly known discussion point.

Thanks for any feedback,

Jacob Shivers

[0] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/7fcdce70-5205-44d6-9c3a-260e616a2f04?redirectedfrom=MSDN

Re: Linux client SMB and DFS site awareness

[Enzo Matsumiya]

On 01/08, Jacob Shivers wrote:
>Hello,
>
>I have a use-case for a Linux SMB client to mount DFS replicated
>shares, with a preference for sites that are closer geographically.
>DNS site discovery/awareness exists within DFS[0], but I have not read
>of any work currently under investigation.

DFS supports referral responses based both on site location and site costing,
which are done on the _server_ (MS-DFSC 3.2.1.1 and 3.2.1.2).

For site location, the targets are sorted with targets on the same site as
the client first, in random order, and then targets outside of client's site
are appended, also in random order.

If supported and enabled, referral responses based on site cost will, practically,
sort the targets from lowest to highest cost (relative to the client,
and in random order if same cost).

On either case, the client will try to connect to the targets in order
it was received.

>[0] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/7fcdce70-5205-44d6-9c3a-260e616a2f04?redirectedfrom=MSDN

I don't see how the info on that link would apply to this particular
scenario, as doing such discovery on the client would be redundant since
the server, if properly implemented, already did it.

Please clarify if you think I misunderstood your case.


Cheers,

Enzo

Re: Linux client SMB and DFS site awareness

[Jacob Shivers]

Hello Enzo,

Thank you for the response!

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.

Thanks again for the response.


[0] https://docs.pagure.org/sssd.sssd/design_pages/active_directory_dns_sites.html

On Mon, Jan 8, 2024 at 1:22 PM Enzo Matsumiya <ematsumiya@suse.de> wrote:
>
> On 01/08, Jacob Shivers wrote:
> >Hello,
> >
> >I have a use-case for a Linux SMB client to mount DFS replicated
> >shares, with a preference for sites that are closer geographically.
> >DNS site discovery/awareness exists within DFS[0], but I have not read
> >of any work currently under investigation.
>
> DFS supports referral responses based both on site location and site costing,
> which are done on the _server_ (MS-DFSC 3.2.1.1 and 3.2.1.2).
>
> For site location, the targets are sorted with targets on the same site as
> the client first, in random order, and then targets outside of client's site
> are appended, also in random order.
>
> If supported and enabled, referral responses based on site cost will, practically,
> sort the targets from lowest to highest cost (relative to the client,
> and in random order if same cost).
>
> On either case, the client will try to connect to the targets in order
> it was received.
>
> >[0] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/7fcdce70-5205-44d6-9c3a-260e616a2f04?redirectedfrom=MSDN
>
> I don't see how the info on that link would apply to this particular
> scenario, as doing such discovery on the client would be redundant since
> the server, if properly implemented, already did it.
>
> Please clarify if you think I misunderstood your case.
>
>
> Cheers,
>
> Enzo
>

Re: Linux client SMB and DFS site awareness

[Enzo Matsumiya]

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

Re: Linux client SMB and DFS site awareness

[Jacob Shivers]

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@suse.de> 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
>