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

On Thu, 06 Jun 2024 13:37:34 -0400
Mark Foley via samba <samba at lists.samba.org> wrote:

> 
> I have no doubt you have said this many times before, but no to me --
> at least not that I can recall.  This is new territory for me.  This
> share started off way-back-when as a Microsoft Sharepoint repository
> which was then migrated to a plain Samba share (I presume this is
> what you are calling "old NT4-style"). That ran for many years
until
> the host was converted to a AD Domain Member about 10 years ago.  All
> I did at the time was make a few minor tweaks to the smb.conf
> (removing guest ok|only, ...) and it continued to work.  Now I have
> needs that apparently extend beyond what the "old-style" can
support.
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:~$ 
> 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'.
> 
> 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.
> 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

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?

Should I create it with 'samba-tool group create' or use ADUC, or does
it
matter?

I assume I'll have to use ADUC to make users as 'Member of' this
group, yes?

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?

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?
> > 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'?
> > 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.

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