samba - May 2020 - Cannot change NTACL for share from Windows

I just joined a freshly installed Linux machine with Samba 4.11.6 to my
Windows AD, as a domain member. Followed the Wiki to a T, domain join
without errors, I can enumerate users/groups, I can create shares and work
with them from Windows (all that matters to me).

Unfortunately, however, I don't seem to be able to change share security
settings, i.e. ACL from Windows. Whenever I do so, I get the error message
that "access is denied". Creating folders within the share and
changing
ACLs for these works without issues, it's just the root folder of the share
I have problems with.

I chose to go with the ad IDMAP backend. Of course, all recommendations are
followed:

- Administrator and Domain Admins have no uidNumber/gidNumer set, all
others do. Though that shouldn't be relevant at this point since I'm
only
accessing the shares from Windows.
- Administrator is mapped to root in user.map
- SeDiskOperatorPrivilege was given to new group "Unix Admins" which
owns
the shares, together with root. Which still shouldn't matter here because
up to now everything was done using the Administrator account, mapped to
root.
- All shares are chmodded to 0770
- Share definitions in smb.conf are just 3 lines, as recommended in the
Wiki: share name, folder location, read only = no

I'm stuck and would appreciate your support. Some configuration details to
follow though it's all really basically just a copy from the Wiki.

[global]
        dedicated keytab file = /etc/krb5.keytab
        disable spoolss = Yes
        kerberos method = secrets and keytab
        load printers = No
        printcap name = /dev/null
        realm = SAMDOMAIN.EXAMPLE.COM
        security = ADS
        template homedir = /home/%U
        template shell = /bin/bash
        username map = /etc/samba/user.map
        winbind refresh tickets = Yes
        workgroup = SAMDOMAIN
        idmap config hq:unix_nss_info = yes
        idmap config hq:range = 10000-999999
        idmap config hq:schema_mode = rfc2307
        idmap config hq:backend = ad
        idmap config * : range = 3000-7999
        idmap config * : backend = tdb
        map acl inherit = Yes
        printing = bsd
        vfs objects = acl_xattr


[myshare]
        path = /srv/samba/EXAMPLESHARE
        read only = No

my user.map:
!root = SAMDOMAIN\Administrator SAMDOMAIN\administrator

getfacl output:
ubuntu at fs1:/srv/samba/$ getfacl EXAMPLESHARE
# file: EXAMPLESHARE
# owner: root
# group: HQ\\unix\040admins
user::rwx
user:root:rwx
group::rwx
group:HQ\\unix\040admins:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:group::r-x
default:group:HQ\\unix\040admins:r-x
default:mask::rwx
default:other::---

Please note that I have the same problem with all shares, not just with
this one.

Thanks,
Viktor

On 31/05/2020 16:37, Viktor Trojanovic via samba wrote:
> I just joined a freshly installed Linux machine with Samba 4.11.6 to my
> Windows AD, as a domain member. Followed the Wiki to a T, domain join
> without errors, I can enumerate users/groups, I can create shares and work
> with them from Windows (all that matters to me).
>
> Unfortunately, however, I don't seem to be able to change share
security
> settings, i.e. ACL from Windows. Whenever I do so, I get the error message
> that "access is denied". Creating folders within the share and
changing
> ACLs for these works without issues, it's just the root folder of the
share
> I have problems with.
>
> I chose to go with the ad IDMAP backend. Of course, all recommendations are
> followed:
>
> - Administrator and Domain Admins have no uidNumber/gidNumer set, all
> others do. Though that shouldn't be relevant at this point since
I'm only
> accessing the shares from Windows.
> - Administrator is mapped to root in user.map
> - SeDiskOperatorPrivilege was given to new group "Unix Admins"
which owns
> the shares, together with root. Which still shouldn't matter here
because
> up to now everything was done using the Administrator account, mapped to
> root.
> - All shares are chmodded to 0770
> - Share definitions in smb.conf are just 3 lines, as recommended in the
> Wiki: share name, folder location, read only = no
>
>
OK, lets start with the obvious, you have:

workgroup = SAMDOMAIN

and:

idmap config hq:backend = ad

Is 'SAMDOMAIN' actually 'HQ' ?

Do all your users have a uidNumber attribute containing a number inside 
10000-999999 ?

Does Domain Users have a gidNumber attribute containing a number inside 
10000-999999 ?

Is Apparmor (or Selinux) running and denying access ?

Rowland

On Sun, 31 May 2020 at 16:04, Rowland penny via samba <samba at
lists.samba.org>
wrote:
> On 31/05/2020 16:37, Viktor Trojanovic via samba wrote:
> > I just joined a freshly installed Linux machine with Samba 4.11.6 to
my
> > Windows AD, as a domain member. Followed the Wiki to a T, domain join
> > without errors, I can enumerate users/groups, I can create shares and
> work
> > with them from Windows (all that matters to me).
> >
> > Unfortunately, however, I don't seem to be able to change share
security
> > settings, i.e. ACL from Windows. Whenever I do so, I get the error
> message
> > that "access is denied". Creating folders within the share
and changing
> > ACLs for these works without issues, it's just the root folder of
the
> share
> > I have problems with.
> >
> > I chose to go with the ad IDMAP backend. Of course, all
recommendations
> are
> > followed:
> >
> > - Administrator and Domain Admins have no uidNumber/gidNumer set, all
> > others do. Though that shouldn't be relevant at this point since
I'm only
> > accessing the shares from Windows.
> > - Administrator is mapped to root in user.map
> > - SeDiskOperatorPrivilege was given to new group "Unix
Admins" which owns
> > the shares, together with root. Which still shouldn't matter here
because
> > up to now everything was done using the Administrator account, mapped
to
> > root.
> > - All shares are chmodded to 0770
> > - Share definitions in smb.conf are just 3 lines, as recommended in
the
> > Wiki: share name, folder location, read only = no
> >
> >
> OK, lets start with the obvious, you have:
>
> workgroup = SAMDOMAIN
>
> and:
>
> idmap config hq:backend = ad
>
> Is 'SAMDOMAIN' actually 'HQ' ?
>
>
Yes

> Do all your users have a uidNumber attribute containing a number inside
> 10000-999999 ?
>
> Yes. It's a fresh AD. 2 users at the moment. And as mentioned, I've
been
only using the Administrator so far.

Does Domain Users have a gidNumber attribute containing a number
inside
> 10000-999999 ?
>
> Yes, 10000.
Is Apparmor (or Selinux) running and denying access ?


No Selinux present. As for Apparmor, it doesn't look like it.

 ubuntu at fs1:/$ sudo apparmor_status
apparmor module is loaded.
9 profiles are loaded.
9 profiles are in enforce mode.
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/snapd/snap-confine
   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /{,usr/}sbin/dhclient
   lsb_release
   nvidia_modprobe
   nvidia_modprobe//kmod
0 profiles are in complain mode.
0 processes have profiles defined.