From: Jacob Shivers <jshivers@redhat.com>
To: Enzo Matsumiya <ematsumiya@suse.de>
Cc: CIFS <linux-cifs@vger.kernel.org>,
samba-technical <samba-technical@lists.samba.org>
Subject: Re: Linux client SMB and DFS site awareness
Date: Thu, 29 Feb 2024 14:12:26 -0500 [thread overview]
Message-ID: <CALe0_77mahrd+ggWApLYRqCLC0k252r=_89qHW7Oa10RK4D4JA@mail.gmail.com> (raw)
In-Reply-To: <20240109005628.5xbwpkqc75okxmcg@suse.de>
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
>
prev parent reply other threads:[~2024-02-29 19:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-08 16:13 Linux client SMB and DFS site awareness Jacob Shivers
2024-01-08 18:17 ` Enzo Matsumiya
2024-01-08 21:49 ` Jacob Shivers
2024-01-09 0:56 ` Enzo Matsumiya
2024-02-29 19:12 ` Jacob Shivers [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALe0_77mahrd+ggWApLYRqCLC0k252r=_89qHW7Oa10RK4D4JA@mail.gmail.com' \
--to=jshivers@redhat.com \
--cc=ematsumiya@suse.de \
--cc=linux-cifs@vger.kernel.org \
--cc=samba-technical@lists.samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).