[Samba] domain-free multi-user use cases

[Aaron C. de Bruyn]

Maybe I'm completely misunderstanding what you're getting at, but Samba
definitely supports more use-cases than that, and from what I can tell it
supports what you're describing as the "third option".

I have a ~30-server deployment where Linux or FreeBSD boxes are domain
members and users access their files (via group policy redirected documents
and various file shares via mapped drives) after they sign into Windows.
That's one user per workstation accessing multiple central servers each
using their own domain creds.

I also have another client with a ~20 server deployment across multiple
sites where Samba is *the* domain controller for the domain.  No Windows
Domain Controllers involved anywhere.  Management is done from a Windows 10
VM with RSAT tools installed.
Users are pulling NETLOGON/SYVOL as well as their redirected documents and
a few mapped shares after they sign in to Windows.  This client also has a
bunch of RDS servers users sign in to remotely.
That's a handful of central RDS servers (with multiple users on each
server) accessing shares on multiple Samba servers each with their own
permissions.

Perhaps you could go into a bit more detail and help me understand what I'm
missing?

Thanks,

-A

On Fri, Oct 22, 2021 at 9:22 PM Eric Levy via samba <samba at lists.samba.org>
wrote:

> I have browsed documentation and previously engaged this group, trying
> to resolve a means toward a deployment with specific characteristics.
>
> Through such investigation, it has become apparent to me that the set
> of use cases presently supported by Samba generally fall into one of
> the following two classes:
>
>    1. Single-user mounts of a server share on a client, without support
>       from any third node.
>    2. Mounts of a server share on a client, often multiuser, with support
>       from a domain server or equivalent kind of node.
>
> I might easily call these two classes of use case the single-user cases
> (1) and the domain-server cases (2).
>
> Two observations about this dichotomy are striking. One is that in
> practical use, many desired configurations will fall easily into one of
> these classes. The other observation is the ease with which someone may
> imagine a valuable use case not within either class.
>
> The many combinations of needs for various deployments indicate a wide
> gap between these two classes. I might suggest this gap represents a
> third class, which I might call the domain-free multi-user cases. With
> the convergence of technologies, and with deployments entering
> increasingly diverse environments, it may seem that these use cases are
> becoming increasingly important.
>
> In my earlier conversation in this group, I described my needs as
> follows:
>
>    What I want is multiple users on the client accessing the same mount
>    but with different permissions enforced for each. I want the
>    permissions to reflect the permissions for the corresponding users
>    on the NAS.
>
>    It seems by now it has been made clear that it is impossible to
>    achieve this result without some kind of domain server...
>
> Support for such functionality without a domain server would require
> development of new components on the client and server to handle
> certain functions currently available only through the domain server.
> Such augmentation would call for good design, but is doubtless
> feasible, at least in principle.
>
> Naturally, one of the nice things about being Microsoft is that after
> you sell licenses for a few clients and a file server, you also can
> sell a license for a domain server. The profit-focused designs of
> software system offered by Microsoft and other companies might
> represent a more narrow range of options than is useful generally. The
> Samba project might benefit from designs expanded to serve a more
> inclusive variety of user needs, with fewer constraints inherited from
> commercial models.
>
> I realize that new support of the kind I am describing is a substantial
> undertaking. I am interested in learning how these thoughts might be
> received considering the current state of development and future
> ambitions.
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>