[Samba] Access denied on GPO after "ntacl sysvolreset"

[Klaas TJEBBES]

Hi.

To give more context.

I have only one DC.

Appart from being member of Domain Admins, Administrator is not mapped 
with UID=0 (unix root), it is not mapped with any unix UID at all.

# smb.conf :

[global]
   realm = DOM.LAN
   workgroup = DOM
   netbios name = ADDC
   disable netbios = yes
   smb ports = 445
   map acl inherit = Yes
   store dos attributes = Yes
   winbind separator = /
   server role = active directory domain controller
   server services = -dns
   tls enabled = yes
   tls keyfile = /var/lib/samba/private/tls/key.pem
   tls certfile = /var/lib/samba/private/tls/cert.pem
   tls cafile =
   usershare max shares = 0
   restrict anonymous = 2
   interfaces = 192.168.0.30

# Domain Admins has a GID
root at addc:~# id domain\ admins
uid=3000004(DOM/domain admins) gid=3000004(DOM/domain admins) 
groupes=3000004(DOM/domain admins)

So after running 'samba-tool ntacl sysvolreset' I can no longer modify 
GPO from RSAT. After a bit of digging, I came with a solution that 
partially works :


file=/home/sysvol/DOM.lan/Policies/
chown -R DOM/domain\ admins ${file}
chown -R DOM/domain\ admins ${file}
setfacl -Rbk ${file}
setfacl -Rm user::rwx ${file}
setfacl -Rm user:NT\ Authority/system:rwx ${file}
setfacl -Rm user:NT\ Authority/authenticated\ users:r-x ${file}
setfacl -Rm user:DOM/enterprise\ admins:rwx ${file}
setfacl -Rm user:NT\ Authority/enterprise\ domain\ controllers:r-x ${file}
setfacl -Rm group::rwx ${file}
setfacl -Rm group:NT\ Authority/system:rwx ${file}
setfacl -Rm group:NT\ Authority/authenticated\ users:r-x ${file}
setfacl -Rm group:DOM/domain\ admins:rwx ${file}
setfacl -Rm group:DOM/enterprise\ admins:rwx ${file}
setfacl -Rm group:NT\ Authority/enterprise\ domain\ controllers:r-x ${file}
setfacl -Rm mask::rwx ${file}
setfacl -Rm other::--- ${file}
setfacl -Rdm user::rwx ${file}
setfacl -Rdm user:NT\ Authority/system:rwx ${file}
setfacl -Rdm user:NT\ Authority/authenticated\ users:r-x ${file}
setfacl -Rdm user:DOM/domain\ admins:rwx ${file}
setfacl -Rdm user:DOM/enterprise\ admins:rwx ${file}
setfacl -Rdm user:NT\ Authority/enterprise\ domain\ controllers:r-x ${file}
setfacl -Rdm group::--- ${file}
setfacl -Rdm group:NT\ Authority/system:rwx ${file}
setfacl -Rdm group:NT\ Authority/authenticated\ users:r-x ${file}
setfacl -Rdm group:DOM/domain\ admins:rwx ${file}
setfacl -Rdm group:DOM/enterprise\ admins:rwx ${file}
setfacl -Rdm group:NT\ Authority/enterprise\ domain\ controllers:r-x ${file}
setfacl -Rdm mask::rwx ${file}
setfacl -Rdm other::--- ${file}


I say "partially" because after running those commands, Windows RSAT 
tells me :
"The permissions for this GPO inthe SYSVOL foder are inconsistent with 
those in Active Directory. It is recommended that those permissions be 
consistent. To Change the SYSVOL permissions to those in Active 
Directory, Click OK.".

After clicking OK and making a diff between before/after, I see no 
differences on ACLs (getfacl -R), but I see this (getattr -R) :
[extract] :
root at addc:~# diff 1.attr 2.attr
6c6
< 
user.SAMBA_PAI=0sAgSADQAOAAABZAAAAAAC/////wABZAAAAAAAwMYtAAABwMYtAAAAwcYtAAABwcYtAAAAwsYtAAABwsYtAAAAw8YtAAABw8YtAAAAyMYtAAAByMYtAAABZAAAAAAC/////wABZAAAAAAAwMYtAAMAwMYtAAMBwMYtAAMAwcYtAAMBwcYtAAMAwsYtAAMBwsYtAAMAw8YtAAMBw8YtAAMAyMYtAAMByMYtAA==
---
 > 
user.SAMBA_PAI=0sAgScDAANAAABxMYtAAAC/////wAAxMYtAAABxMYtAAAAx8YtAAABx8YtAAAAwsYtAAABwsYtAAAAw8YtAAABw8YtAAAA3MYtAAAB3MYtAAAC/////wABxMYtAAMAxMYtAAMBxMYtAAMAx8YtAAMBx8YtAAsAxMYtAAMAwsYtAAMBwsYtAAMAw8YtAAMBw8YtAAMA3MYtAAMB3MYtAA==
9a10
 > 
user.SAMBA_PAI=0sAgSMDAANAAABxMYtAAAC/////xAAxMYtABABxMYtABAA3MYtABAB3MYtABAAx8YtABABx8YtABAAw8YtABABw8YtABAAwsYtABABwsYtAAAC/////xMAxMYtABMBxMYtABMA3MYtABMB3MYtABMAx8YtABMBx8YtABMAw8YtABMBw8YtABMAwsYtABMBwsYtAAsBxMYtABsAxMYtAA==
12a14
 > 
user.SAMBA_PAI=0sAgSMDAANAAABxMYtAAAC/////xAAxMYtABABxMYtABAA3MYtABAB3MYtABAAx8YtABABx8YtABAAw8YtABABw8YtABAAwsYtABABwsYtAAAC/////xMAxMYtABMBxMYtABMA3MYtABMB3MYtABMAx8YtABMBx8YtABMAw8YtABMBw8YtABMAwsYtABMBwsYtAAsBxMYtABsAxMYtAA==
15a18

[the rest of the diff is all about "user.SAMBA_PAI"]




Le 11/04/2025 à 13:12, Rowland Penny via samba a écrit :
> On Fri, 11 Apr 2025 11:27:21 +0200
> Havany via samba <samba at lists.samba.org> wrote:
> 
>> Hi Klaas,
>>
>> Luis may have been referring to bug 14213 (Windows Explorer crashes
>> on S-1-22-* Unix-SIDs when accessing the Security tab), fixed in
>> version 4.21.4. This bug also causes gpedit to crash.
>>
>> You may have a mapping issue with your IDmap on domain controllers.
>>
>> I wrote a script to display the mapping in a readable form (see the
>> end of this post).
>>
>> To reset the mapping on all DCs, here's what I do (note! You need to
>> adapt it to your configuration; this is for FreeBSD with a ZFS
>> dataset for Sysvol and NFS4ACL) (inspired by the migration of the
>> RFC2703 schema to TDB of Tranquil IT:
>> https://samba.tranquil.it/doc/en/samba_config_server/samba_rfc_to_tdb.html):
> 
> That, in my opinion, isn't actually migrating the RFC2307 schema, the
> RFC2307 schema is actually part of the standard AD schema.
> 
> There are a few other ways around this problem:
> 
> Do not use 'idmap_ldb:use rfc2307  = yes' in the DCs smb.conf , this
> will lead to only using the '3000000' xidNumber attributes from
> idmap.ldb being used on Samba AD DCs instead of any uidNumber or
> gidNumber attributes in AD. This will negate any uidNumber or gidNumber
> attributes in AD.
> 
> Do not give Domain Admins a gidNumber attribute, you can create another group similar to Domain Admins (I used to use a group called Unix Admins), give that group a gidNumber and use that group on Unix instead of Domain Admins.
> 
> Do not use RFC2307 attributes and use the rid or autorid idmap backends on Unix domain members.
> 
> If you do use RFC2307 attributes, then you only really need to give the Domain Users group a gidNumber, along with any groups you create that you want to be visible on Unix domain members.
> 
> As the idmap_ldb backend found on Samba AD DCs is an allocating backend and different IDS can be allocated to users and groups depending on when they first come to the DCs notice, you need to sync idmap.ldb between all DCs, however this doesn't need to be done regularly as the changes that matter only really happen when a DC first runs.
> 
> Rowland
>   
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- Klaas TJEBBES
- Pôle Logiciel Libre (EOLE)
- DSI
- Dijon

~~~~~~~~~~~~~~~~~~~~~~~~~~~~