[Samba] domain-free multi-user use cases

[Eric Levy]

On Sun, 2021-10-24 at 18:01 +1300, Andrew Bartlett via samba wrote:
> On Sat, 2021-10-23 at 20:31 -0700, Jeremy Allison via samba wrote:
> > On Sat, Oct 23, 2021 at 07:43:01PM -0400, Eric Levy via samba
> > wrote:
> > > It seems the first scenario you describe is simply several users
> > > each
> > > creating their own single-user mount, that is, several
> > > simultaneous
> > > uses in class (1).
> > > 
> > > The second describes a Windows client, and it hasn't been
> > > explained
> > > whether the same concept would transfer to a Linux client.
> > > 
> > > Can a Linux client mount (e.g. as root) a remote Samba share such
> > > that
> > > files on the server owned by user1, user2, and so on, show
> > > correspondingly on the client as owned by user1, user2, and so
> > > on?
> > 
> > man mount.cifs - options:
> > 
> >         multiuser
> >                Map  user  accesses to individual credentials when
> > accessing the
> >                server. By default, CIFS mounts only use a
> > single  set  of  user
> >                credentials (the mount credentials) when accessing a
> > share. With
> >                this option, the client instead creates a new
> > session  with  the
> >                server using the user's credentials whenever a new
> > user accesses
> >                the mount.  Further accesses by that user
> > will  also  use  those
> >                credentials.  Because  the  kernel  cannot prompt
> > for passwords,
> >                multiuser mounts are limited to mounts using
> > sec=  options  that
> >                don't require passwords.
> > 
> >                With this change, it's feasible for the server to
> > handle permis‐
> >                sions enforcement, so this option also implies
> > noperm . Further‐
> >                more,  when  unix extensions aren't in use and the
> > administrator
> >                has not overridden ownership using
> > the  uid=  or  gid=  options,
> >                ownership  of  files  is presented as the current
> > user accessing
> >                the share.
> 
> One could imagine building a solution based on S4U2Proxy (constrained
> delegation) to authorize one server to assert the identity of all the
> users it holds.  That external to Samba tool (no need for us to be
> involved) would just supply normal Kerberos tickets to the server for
> each user, obtained with this protocol extension.
> 
> Of course, in this situation you would need an AD DC, thankfully we
> have one built in!

I am not familiar at this time with these components, but it would seem
that the level of complexity from using such an external tool might
defeat the purpose of seeking to eliminate the need for a domain
server.