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

[Rowland Penny]

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.

> 
> > > I want a like restriction with this vfs_acl_xattr.
> > > I supposed I can use group 'Domain Users' since all domain users
> > > will be able to access this, and I don't have to create a new
> > > group.  So question #1: should I change all files/directories in
> > > this share to group 'Domain Users' before proceeding further?
> >
> > You do not need to use 'Domain Users', use the Domain group 'ohprs'.
> 
> Probably creating a new domain group is a good idea, but technically,
> I wouldn't have to, right? I could just make this share's group
> 'Domain Users'?

Well yes, but then every domain users would get access, do yo really
want this ?

> 
> > > mini question(s) -- can I still use the following for this share
> > > in smb.conf:
> > > 
> > > store dos attributes = no   # this one might be an issue, but I
> > > can explain 
> >
> > Why do you have that line, the default for that parameter is 'yes'
> > and you shouldn't need to change it.
> 
> OK, I'll try to keep this short. Windows users have an app for
> scanning documents, Foxit PDF Editor. If they scan a new document to
> this share, no problem. If they scan/append to an existing document
> the file is left with the DOS hidden attribute on and the document
> essentially disappears from the user's share view. It took a while to
> figure this out, but setting 'store dos attributes = no' was the only
> solution I came up with. Possibly, this isn't a problem with the
> vfs_acl_xattr mechanism? Maybe some expermentation is needed on this.

Does it work okay if the share is on a Windows machine, if so, it
should be okay on a Samba machine set up correctly using the acl_xattr.

> 
> Note that this phenomenon just started happening when I upgraded from
> Samba 4.8.2 to Samba 4.18.9. It wasn't a problem on the old Samba. No
> version change on Foxit.
> 
> > > hide dot files = yes
> >
> > Yes, you can set that.
> >
> > > 
> > > BTW, for the wiki command:
> > > 
> > > # chown root:"Domain Admins" /srv/samba/Demo/
> > > 
> > > I could not make that work unless I added the domain:
> > > 
> > > # chown root:"hprs\Domain Admins" /srv/samba/Demo/
> >
> > Ah, if you add 'winbind use default domain = yes' to global, you
> > will not have to add 'hprs\' (the NetBIOS domain name, aka
> > workgroup).
> >
> > Rowland
> 
> Did that! Thanks. Perhaps that tip might be worth a mention in
> https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member
> in the "Setting up a Basic smb.conf File" section.
> 
> Thanks --Mark
> 

I thought it was there (or somewhere else), will look into it ;-)

Rowland