[Samba] How to give AD users group permissions on a Samba share

[Mark Foley]

On Fri Jun  7 01:39:06 2024 Rowland Penny via samba <samba at lists.samba.org> wrote:
>
> On Thu, 06 Jun 2024 23:58:18 -0400
> Mark Foley via samba <samba at lists.samba.org> wrote:
>
> > On Thu Jun  6 14:28:46 2024 Rowland Penny <rpenny at samba.org> wrote;
> > >
> > > On Thu, 06 Jun 2024 13:37:34 -0400
> > > Mark Foley via samba <samba at lists.samba.org> wrote:
> > >
> > > > [snip]
> > >
> > > Basically, the old NT4-style domains relied on setting permissions
> > > in the share part of the smb.conf file, but, by using
> > > vfs_acl_xattr, you can set finer control from Windows and these
> > > acls are stored Extended Attributes (EAs).
> > >
> > > > 
> > > > So. I've followed the procedures in your referenced link. and am
> > > > at the section titled: "Setting Share Permissions and ACLs". I am
> > > > setting this up on a test system. Before proceeding further I have
> > > > some questions that don't seem immediately addressed in the wiki.
> > > > 
> > > > This section in the wiki is giving an example for setting the
> > > > share to 'Everyone', 'Full Control' and 'Domain Users'. 
> > > > 
> > > > As I've described, all files in this folder are currently set to
> > > > Unix group "ohprs'.  
> > >
> > > That is one of the old-overs you don't need, if set up correctly,
> > > Samba can make the domain group 'ohprs' into the Unix group group
> > > 'ohprs'.
> > >
> > > I created a group called 'ohprs' in my AD and:
> > >
> > > rowland at devstation:~$ getent group ohprs
> > > ohprs:x:13603:
> > >
> > > So it appears to the local system as a Unix group, but if I look in
> > > /etc/group it isn't there:
> > >
> > > rowland at devstation:~$ grep 'ohprs' /etc/group
> > > rowland at devstation:~$ 
> > 
> > Questions here ... Do I first have to remove that group from
> > /etc/group before creating it in AD?
>
> Yes
>
> > 
> > Should I create it with 'samba-tool group create' or use ADUC, or
> > does it matter?
>
> Either will do the job.
>
> > 
> > I assume I'll have to use ADUC to make users as 'Member of' this
> > group, yes?
>
> You could do it that way, or use 'samba-tool group addmembers', see
> 'samba-tool group addmembers --help' for more information.
> There is one benefit of using AD groups over local Unix groups, you can
> add other domain groups to domain groups.
>
> > 
> > Do I have to change the current group (chgrp) for these
> > files/directories to the AD 'ohprs' group, or will that be
> > "automatic" once I create the ohprs AD group and make users members
> > therof?
>
> Yes, your AD group will be get a new Unix ID.
>
> > 
> > Current Unix permissions are rwxrws---. I know how to set Windows
> > permissions from experience and from the "Setting Share Permissions
> > and ACLs" section of the wiki, but there are non-AD users accounts on
> > this host that need to access these files/folders for running cron
> > jobs to transmit enrollment files, etc. No problem with Unix groups
> > as I just did the 'usermod -a -G' to give these users group priv. Is
> > something like that possible with this scheme for non-AD user access?
>
> There you go again, that is the 'old' way of doing things, you
> shouldn't really have any 'non-AD' users, they should all be in AD
> (which is the whole idea behind AD, one place of management), Create
> all your 'non-AD' users in AD and Samba will make them Unix users as
> well. Once your users are AD users (and Unix users), you just add them
> to the required groups and AD will do the rest.

Wowser! So, *ALL* user accounts on this host should be AD users? That raises
more questions (not requesting answers to these at this time): 

I presume for local users I'll have to use ADUC (or samba-tool) to specify home
directories (which I did on the 4.8.2 Samaba system). Will that still work with
the tdb backend?

There are accounts that aren't "real users", but rather used for batch (crontab)
processing which need r/w access to this share (files/directories physically located
on this server). They do sftp to remote hosts at governmental and health
provider locations. Will the .ssh/known_host / id_rsa.pub mechanism still work
for authentication?

Likewise, remote sftp clients need access to this system.  Will the id_rsa.pub
authentication mechanism still work (since they'll have to connect as an AD
user) and if so, will they all have to change their login credentials?

What about email? Can the mutt/mailx/sendmail apps be used for local domain
users to create mailboxes in /var/spool/mail without an entry in /etc/passwd?

What about special users like tomcat, daemon, etc.  The tomcat user, for
example, accesses all the webapps JSP files, and domain users can access these
files for editing in MS Expression (like FrontPage).  The webserver programs are
run as the apache and tomcat users/groups.  The daemon user runs sendmail alias
scripts which need access to these Share files.  Will that all work if these are
converted to domain users? Can they even be converted?

Probably all webapps files will have to be part of the domain "ohprs" group. 
Lots of changes there. 

What about sudo and /etc/suauth? sudo might work, but /etc/auth (uses pam) might
not as it requires the user to be part of the wheel group.

Can CUPS admins be domain members? Not a big issue since no one prints from the
Linux host.

All permissions for all files/directories would have to be [re]set via Windows.

I'm not asking you to answer these questions. I can find out the answers by
experimenting on my test platform.

This host is the "workhorse" of the organization with web hosting, and batch
processing for all the business functions of the org. The daily work files used
by users are on this Share.

The original purpose of sharing this directory on a Domain Member was so that
users did not have to authenticate mapping the Share with additional credentials
(stored in /etc/passwd) and could just get automatic authentication, regardless
of from which workstation they logged in. 

I've wanted to move more in the direction of vfs_acl_xattr because I wanted the
Boss to have exclusive access to his own personal folder, shared by his
assistant. That was the impetus for this thread. Otherwise, things worked just
fine with the old-style NT4 config.

The proposition of setting all users, directories and files to utilize this 
vfs_acl_xattr mechanism is not an immediate thing I can do without lots of
up-front experimentation and configuration.

I'll have to do this experimentation and weigh the benefits of such a major
change on this host. 

I will have to ascend the mountain and contemplate this AD Universe, and
experiment. At the conclusion of this spiritual journey I will share my
enlightenment, if any.

Thanks for all your help --Mark