The former deployment you have described seems to fall into the class of cases I have labeled (2), (i.e. "with support from a domain server"). The latter one also may fall into this class, but I may not understand the meaning of "Samba is the domain controller". If Samba is the domain controller, then a domain controller exists, which I believe makes this deployment also suitable for association with class (2). The proposed class (3) entails no domain server, or any similar component, only a file server and client. Perhaps some nuance surrounds the implications of a domain controller co-located with the file server, but I believe, not knowing the full details of these systems, that this difference is simply a deployment detail of which software components reside on which hardware nodes, and not one that bears on the distinctions among the classes I have defined. In particular, I believe that one feature of the latter deployment, as well as the former, is that the file server is configured to recognize a domain server as part of the overall deployment. Suppose you wish to configure a client for a file server that has no association with a domain server. Under such circumstances, I believe any use case falls under class (1), which precludes the client creating a multiuser mount. My argument largely centers around the observation that a multiuser mount only may be realized through support for a proposed use-case class (3). On Fri, 2021-10-22 at 21:32 -0700, Aaron C. de Bruyn wrote:> 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. > > > >
On 10/23/21 00:12, Eric Levy via samba wrote:> > In particular, I believe that one feature of the latter deployment, as > well as the former, is that the file server is configured to recognize > a domain server as part of the overall deployment. Suppose you wish to > configure a client for a file server that has no association with a > domain server. Under such circumstances, I believe any use case falls > under class (1), which precludes the client creating a multiuser mount. > My argument largely centers around the observation that a multiuser > mount only may be realized through support for a proposed use-case > class (3). > >Samba can most definitely do what you're trying to do. I think the confusion here has to do with the separation of responsibilities. There are two separate things necessary in order to insure secure filesystem mounts in a multi-user environment: authentication and authorization. They're not the same thing. *Authentication* involves a challenge requiring you to prove that you are indeed the user you're saying you are, and *authorization* is the determination of whether or not this particular user has access to a particular resource. You will agree that both of these are absolutely necessary. You can have erics-top-secret-file on a shared filesystem with permissions locked down so that only eric can view it, but this doesn't do you any good if anyone can pretend to be eric, right? So step 1: you must have a system for authenticating users. OK, how do you do this? Traditionally, in UNIX-like systems there are files on the machine detailing user accounts and what the authentication challenge is that must be met. This works splendidly, but what do you do if you have 100 or more systems and you want the same user names and authentication challenges on all these systems? You can certainly copy the files encoding this information around to all systems, but that can become onerous (pre CMS), as any time you introduce a new user or change a challenge, this information must be updated on all the systems. This is why Sun Microsystems invented NIS. NIS also worked splendidly, but it was low security and structural inflexible. Hence the introduction of LDAP, which Microsoft co-opted as a component of an Active Directory server, and which linux-only systems use in the form of openLDAP, FreeIPA/idM, etc. This is quite a broad overview, but you get the idea: the point of having a Directory is having a single place where you keep track of all authentication information. Could you do this without a server, with all machines somehow sharing credentials in the background? Sure, of course, but why would you want to? Often times when people have physical access to isomorphic authentication files, this affords opportunity to crack the secrets of these files. So if all your machines are sharing physical credential files and one of these machines is compromised, the hacker now has a copy of all your credentials. It's generally better to keep these things locked up behind multiple doors where only a very small number of people have keys. And that, in a nutshell, is what a directory server is. Could you somehow have the authentication system distributed agnostically across all participating machines? Yes, again, but oh, the complications. Think of this like bitcoin: yes, you can have a secure "ledger" without a central authority, but managing this consumes more electricity than the entire country of Argentina! What about authorization? Filesystems have the ability to store metadata about which users (or groups of users) should or shouldn't have access to any particular resource, and what this access means. Is the user eric able to read the our-shared-proposal file? Yes. Should user eric be able to edit or delete the our-shared-proposal file? That's a different question; maybe yes, maybe no. But in any case that's a feature of the filesystem being shared. In particular, if I have a folder on machine A which I share with machine B, when someone on machine B wants to access a file from this share, machine B asks machine A if that user has the appropriate credentials to do so. A's got the metadata, so just ask A before proceeding. One very important detail is that the metadata detailing authorization is stored *numerically*. All the filesystem knows, for example, is that a user with numeric ID 1562224677 is the owner of the file foobar. The association 1562224677 = eric is made using either the aforementioned authentication files or, again, by a directory server. If you're eric with UID 1001 on a different system, guess what? That's a different eric, whether you think so or not. You'd have to tell the system these are the same erics somehos (e.g. Canonical's /etc/subuid|subgid system for containers or NFS's or Samba's idmap). The reason I bring this up is that this technically means if you type `ls -l` in a shared folder context, the name of the owner of each file must be looked up against the directory server. Isn't this going to be terribly slow, say, when listing a folder containing several thousand files for each of which the user owner name must be looked up? And the answer is yes, this is going to be terribly slow, which is why typically the credentials are cached locally on client machines. "Aha!", you now exclaim, "so the credentials are on every machine ANYWAY!" Not exactly: they're share in such a way (i.e. are encrypted) so as to not be useful to anyone with physical access to the machine. The Directory Server is not just handing over a copy of the credentials files, it handing them out with invisible ink and the client system has to use it's own magic lemon juice to see them. tl;dr: yes, you can do this with Samba, but there are other factors involved as well. Thinking about this in terms of authentication and authorization will clear up most confusion.