samba - Nov 2022 - several offices: home dirs, local resources, ...

Hi Michael,

Location-specific DFS might help you: an UNC path looks the same across
all offices from the Windows client side, but it is resolves specific
for the office it is being accessed from.

The concept is explained in Microsoft terms here:
https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/dfs-overview
.

Concluding from a different mail thread, you are working on AD sites
reflecting different offices. Once you have that working - site-specific
AD-DCs in the various offices of your company, it will not be a big step
to get site-specific "Folder Targets" (in Microsoft terms)
implemented.
E.g. \\your.domain.fqdn\profiles\userA will point to a share hosted in
the office of that user, or even \\your.domain.fqdn\profiles could be
site-specific. Technically on the samba DC it's just a matter of a few
entries in smb.conf plus symbolic links in the file system of the DC.

I tried to get DFS running with Samba DCs a few years ago. I was not
successful, and because it was not important for my use case I did not
try for long and gave up. In theory it should work, and maybe one or the
other bug might have been resolved in the meantime.

Maybe that helps?

And BTW, thank you for all your hard work for the Debian samba packages!
You're doing a big favour to the samba community.

Regards, Norbert

On 17.11.2022 15:24, Michael Tokarev via samba wrote:
> Hello!
>
> This is not exactly a samba question, but maybe someone here have some
> input.
>
> Historically, we had several geographically spread offices, with
> local servers in each location, and local resources.? All had
> their own DNS domain (a subdomain of the main domain), and local
> short names like "fs" (for file server), "mail" etc.?
So far so
> good.? (We even had DFS working once when the load to one file
> server was too high).
>
> Home directories for the users are kept on local servers, including
> the roaming profiles.? When they log in to a machine in another office,
> their home dir in that office is used. So effectively, these aren't
> exactly roaming, in the sense that they're not being copied between
> the offices automatically - it's done on demand only.
>
> The local LAN is fast obviously, inter-office connectivity is
> dramatically slower and isn't always available, so keeping local
> resources is vital.
>
> This has always worked with NT4-style domains, worked quite well.
> For over 20 years.
>
> Now, I'm trying to switch to a Samba-based AD.? One office has been
> switched, but an attempt to include another office immediately
> stuck with quite some issues which I don't know how to solve.
>
> First, the home server for the users. I want their home dirs to
> be stored in *local* site (local for the computer they're logging
> at).? I can't seem to find a way to make it to work, - I can configure
> home server for each user in the AD, but I can't make it *different*
> servers depending on the location. I can force a machine to grab
> roaming profiles from a fixed server (this overrides per-user setting)
> but this way, local user (eg, a local administrator account used for
> rescue purposes) does not work well anymore, it too tries to store
> their home dir on that server.
>
> Second, the short names like "fs" - it should be different
"fs" for
> each location. I forced windows clients to use local DNS suffix
> before the main domain suffix. But when this is about a file server,
> the main domain suffix is always used despite that this name
> exists in local subdomain too, which should be searched before.
>
> Users are used to the short names in many years, they have lots
> of shortcuts/links to these names, and I can't seem to find a
> way how to make the same name to point to a different server in
> each location.
>
> How it is usually done?
>
> Thanks!
>
> /mjt
>

Another (potentially simpler, but less secure?) way of dealing with this
might be some sort of split-horizon DNS:

* Point your clients at a different (internal, per site) DNS Server (DNS-A)
* Have this DNS Server (DNS-A) refer samdom.tld requests to your AD-DC, and
all others upstream.
* Configure specific CNAME overrides and redirections on DNS-A, i.e.
fs.samdom.tld to site1-fs.samdom.tld

This way, your DC only handles AD-related DNS queries, but requests to
fs.samdom.tld should never get that far.

I've done this with site-specific fileshares, and also routing traffic over
a VPN instead of over the public internet.

Kris Lou
klou at themusiclink.net

>

18.11.2022 02:25, Norbert Hanke via samba wrote:
> Hi Michael,
> 
> Location-specific DFS might help you: an UNC path looks the same across
> all offices from the Windows client side, but it is resolves specific
> for the office it is being accessed from.
> 
> The concept is explained in Microsoft terms here:
>
https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/dfs-overview
> .
> 
> Concluding from a different mail thread, you are working on AD sites
> reflecting different offices. Once you have that working - site-specific
> AD-DCs in the various offices of your company, it will not be a big step
> to get site-specific "Folder Targets" (in Microsoft terms)
implemented.
> E.g. \\your.domain.fqdn\profiles\userA will point to a share hosted in
> the office of that user, or even \\your.domain.fqdn\profiles could be
> site-specific. Technically on the samba DC it's just a matter of a few
> entries in smb.conf plus symbolic links in the file system of the DC.
Hi Norbert!  That seems like a very interesting way.  I just configured
[profiles] share on a DC, with msdfs root enabled, and created a folder
in it with `mjt' username, pointing to the right file server.

Now I wonder how to configure shares like \\domain.tld\profiles to work?
And should it work with the short name (\\domain\profiles) ?

> I tried to get DFS running with Samba DCs a few years ago. I was not
> successful, and because it was not important for my use case I did not
> try for long and gave up. In theory it should work, and maybe one or the
> other bug might have been resolved in the meantime.
Do you mean the microsoft-tool-manageable DFS, like described in the
doc you pointed to above?  I don't think I really need this so far, it
is easy enough to crate the symlinks :) (btw, these names in the DFS
root really act and shown as symlinks by windows).

What I really want is a short fileserver name (FS) - which the users
are used to, - to point to a site-specific server - this is the main
goal, to register "FS" name local to each site.

A seems-to-be-easier goal is to provide local (site-specific) storage
for user profiles, but that one might be a bit easier since it can
be configured in a single place which is not directly used by the
users (so users wont have to reconfigure all their shortcuts for
example).

> And BTW, thank you for all your hard work for the Debian samba packages!
> You're doing a big favour to the samba community.
You are welcome :)

Thank you!

/mjt