samba - Jun 2024 - How to give AD users group permissions on a Samba share

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

On Sat, 08 Jun 2024 01:43:56 -0400
Mark Foley via samba <samba at lists.samba.org> wrote:



> 
> 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 think there may have been some confusion here, when I said all your
users should be in AD, I was referring to normal users (the ones with
Unix IDs that usually start at '1000') and not system users (the ones
you find in /etc/passwd after a new install).
If you are going to connect to the computer via SSH, you will probably
require at least one local user that isn't in AD, this user can then be
a 'sudo' user just in case something goes wrong with AD.

To put it another way, after you create your first admin user on a new
Unix machine, you then create all other users and groups in AD.
> 
> 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?
It depends on the definition of 'local user', if it is a true 'local
user' i.e it is created locally and is in /etc/passwd, then you just
allow Linux to deal with home directories etc, but if your 'local user'
is actually an AD user that Samba is mapping to a local user, then it
will depend on the idmap backend in use.
> 
> 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?
Define such a user, but SSH will work with AD users.
> 
> 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?
It depends on who the users are, but as I said, Samba will map AD users
to local Unix users, to all intents and purposes the AD users will
appear to the OS as local users:

rowland at devstation:~$ getent passwd rowland
rowland:*:11104:10513:Rowland Penny:/home/rowland:/bin/bash

Does that look familiar ?

But:

rowland at devstation:~$ grep 'rowland' /etc/passwd
rowland at devstation:~$ 

I am not 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?
No, such users are 'system users' (their ID is less than 1000) and as
such, have nothing to do with Samba. Just use them as before.
 
> 
> Probably all webapps files will have to be part of the domain
"ohprs"
> group. Lots of changes there. 
It all depends on what you use the 'ohprs' group for and how you use it.
> 
> 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.
Yes sudo will work and you can actually put the sudo rules in AD.
> 
> Can CUPS admins be domain members? Not a big issue since no one
> prints from the Linux host.
Yes you can have cups admins in AD, remember Samba can map all AD
users & groups to 'local' users & groups.
> 
> All permissions for all files/directories would have to be [re]set
> via Windows.
That is the best way of doing it, all you need are shares that look
like this

[sharename]
   path = /where/ever/you/want
   read only = no

That's it, but see the wikipage for more info.
> 
> 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.
You need to get ahead of the game, Samba is working to totally removing
SMBv1 and when that happens, it is possible that some of the parameters
you are using now will be removed, because they rely on SMBv1.
> 
> 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.
As I said, I think you misunderstood, you do not put everything in AD,
apart from one or two admin users, you put everything with a Unix ID
greater than '1000' in AD and if using the 'ad' idmap backend,
you do
not give any user or group with a RID less than '1000' a uidNumber or
gidNumber.

I hope this helps, but if you still have questions, please ask.

Rowland