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

[Rowland Penny]

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