Comment 1 Arvid Requate 2020-05-25 15:20:00 CEST

tl;dr: There's a bug in the content of the UCS Samba/AD idmap.ldb which causes GPO files to get owned by the admin user instead of by the group "Administrators", which is the default on Microsoft Windows systems.


There is a long story to this issue, rooted in the history of Microsoft Windows security settings, UAC, etc. but the fact is this:

If user creates a file on a Microsoft Windows system and the user is either direct or indirect member of the BUILTIN/Administrators group, then the ownership of the new file can default to the SID of the "Administrators" group, instead of the users SID. This happens in case the user process runs with elevated/Administrative rights (i.e. with an unrestricted security token). This happens if the user either uses UAC to raise permissions, *or* if the user connects via network to a share. This is a security feature that has been default since Windows Vista.


This can be shown easily using a Windows client joined into a UCS Samba/AD DC: Create a new account != "Administrator", add it to the "Domain Admins" group and use smbclient to upload a file on the Windows client using that account. The file will be owned by "Administrators" (S-1-5-32-544).

Now use smbclient to create a file on the UCS server and the file will be owned by the user herself instead:

root@master10:~# samba-tool ntacl get --as-sddl  /var/lib/samba/sysvol/test1.txt
O:S-1-5-21-2660895256-1678062113-3852026326-1117G:DUD:(A;;0x001f01ff;;;BA)(A;;0x001200a9;;;SO)(A;;0x001f01ff;;;SY)(A;;0x001200a9;;;AU)

while this would be the expected result:

root@master10:~# samba-tool ntacl get --as-sddl  /var/lib/samba/sysvol/test2.txt
O:BAG:DUD:(A;;0x001f01ff;;;BA)(A;;0x001200a9;;;SO)(A;;0x001f01ff;;;SY)(A;;0x001200a9;;;AU)

Comment 2 Arvid Requate 2020-05-25 15:24:26 CEST

Created attachment 10371 [details]
fix_ID_TYPE_BOTH.patch

This would fix the issue for new installations. For updates we would have to somehow trigger an idmap update for the AD builtin accounts given in the patch. I also had to do a "net cache flush" to enjoy the new correct behavior.

Comment 3 Arvid Requate 2020-05-25 15:42:20 CEST

Quote: "The problem is that on windows a group can own files, this is something 
that cannot happen on Unix, also a group can be a member of another 
group. So, as in this case, a user who is a member of 'Domain Admins' 
ends up creating a file belonging to the 'Administrators' group because 
windows decided it was a good idea!"
    -- Rowland Penny https://lists.samba.org/archive/samba/2015-August/193354.html


* https://serverfault.com/questions/19311/file-ownership-for-new-files-with-administrator-why-is-it-giving-ownership-to

* https://superuser.com/questions/713848/member-of-administrator-group-in-windows-is-displaying-administrators-as-owner

* https://support.microsoft.com/en-us/help/947721/a-group-policy-setting-is-not-available-in-the-security-policy-setting

* https://docs.microsoft.com/de-de/archive/blogs/technet/sfu/how-to-change-the-default-ownership-of-a-newly-created-file-on-windows

* https://community.netapp.com/t5/AFF-NVMe-EF-Series-and-SolidFire-Discussions/Owner-on-newly-created-files-and-folders-default-to-built-in-Administrators/td-p/146645

Comment 4 Arvid Requate 2020-05-25 16:31:04 CEST

Quick local fix per Samba/AD server:

root@master10:~# ldbmodify -H /var/lib/samba/private/idmap.ldb <<%EOF
dn: CN=S-1-5-32-544
changetype: modify
replace: type
type: ID_TYPE_BOTH
%EOF
root@master10:~# net cache flush


Two additional caveats:

1) The parent directory still belongs to the admin user account, but only in the fACLs, not in the NTACLs:

root@master:~# ls -ld /var/lib/samba/sysvol/schein.ig/Policies/{5AD34A4C-4A25-4EB2-839C-B94F5708F4D5}/                        
drwxrwx---+ 4 cscheini Domain Admins 4096 Mai 25 16:07 /var/lib/samba/sysvol/schein.ig/Policies/{5AD34A4C-4A25-4EB2-839C-B94F5708F4D5}/

root@master:~# samba-tool ntacl get --as-sddl /var/lib/samba/sysvol/schein.ig/Policies/{5AD34A4C-4A25-4EB2-839C-B94F5708F4D5}/
O:DAG:DAD:PAI(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)

We'd have to research how this comes about and if it has any negative effect. Might require a samba patch in `inherit_new_acl` (source3/smbd/open.c) or so.


2) We also need to adjust the sysvolcheck logic to allow Builtin Admin to own the files even though the DSACLs say the GPO is owned by DA.

root@master:~# samba-tool ntacl sysvolcheck --mask-msad-differences
ProvisioningError: DB NTACL of GPO file /var/lib/samba/sysvol/schein.ig/Policies/{5AD34A4C-4A25-4EB2-839C-B94F5708F4D5}/GPT.INI does not match value expected from GPO object
FSACL: O:BAG:DAD:AI(A;ID;0x001f01ff;;;DA)(A;ID;0x001f01ff;;;EA)(A;ID;0x001f01ff;;;BA)(A;ID;0x001f01ff;;;SY)(A;ID;0x001200a9;;;AU)(A;ID;0x001200a9;;;ED)
DSACL: O:DAG:DAD:AI(A;ID;0x001f01ff;;;DA)(A;ID;0x001f01ff;;;EA)(A;ID;0x001f01ff;;;SY)(A;ID;0x001200a9;;;AU)(A;ID;0x001200a9;;;ED)
ProvisioningError: VFS NTACL of GPO file /var/lib/samba/sysvol/schein.ig/Policies/{5AD34A4C-4A25-4EB2-839C-B94F5708F4D5}/GPT.INI does not match value expected from GPO object
FSACL: O:BAG:DAD:AI(A;ID;0x001f01ff;;;DA)(A;ID;0x001f01ff;;;EA)(A;ID;0x001f01ff;;;BA)(A;ID;0x001f01ff;;;SY)(A;ID;0x001200a9;;;AU)(A;ID;0x001200a9;;;ED)
DSACL: O:DAG:DAD:AI(A;ID;0x001f01ff;;;DA)(A;ID;0x001f01ff;;;EA)(A;ID;0x001f01ff;;;SY)(A;ID;0x001200a9;;;AU)(A;ID;0x001200a9;;;ED)

Optimally sysvolcheck would also check if DA is member of BA and only warn if it is not.

Comment 6 Christina Scheinig 2020-06-11 11:04:38 CEST

The patch works in the customer environment, so the GPO is applied.

samba-tool ntacl sysvolcheck --mask-msad-differences 
still shows ProvisioningError messages.

root@ucs:~# samba-tool ntacl sysvolcheck --mask-msad-differences
ProvisioningError: DB NTACL of GPO file /var/lib/samba/sysvol/schein.ig/Policies/{9A386DD7-E634-4429-9E58-79AF46932FE6}/Machine/Registry.pol does not match value expected from GPO object
FSACL: O:BAG:DAD:AI(A;ID;0x001f01ff;;;DA)(A;ID;0x001f01ff;;;EA)(A;ID;0x001f01ff;;;BA)(A;ID;0x001f01ff;;;SY)(A;ID;0x001200a9;;;AU)(A;ID;0x001200a9;;;ED)
DSACL: O:DAG:DAD:AI(A;ID;0x001f01ff;;;DA)(A;ID;0x001f01ff;;;EA)(A;ID;0x001f01ff;;;SY)(A;ID;0x001200a9;;;AU)(A;ID;0x001200a9;;;ED)
ProvisioningError: VFS NTACL of GPO file /var/lib/samba/sysvol/schein.ig/Policies/{9A386DD7-E634-4429-9E58-79AF46932FE6}/Machine/Registry.pol does not match value expected from GPO object
FSACL: O:BAG:DAD:AI(A;ID;0x001f01ff;;;DA)(A;ID;0x001f01ff;;;EA)(A;ID;0x001f01ff;;;BA)(A;ID;0x001f01ff;;;SY)(A;ID;0x001200a9;;;AU)(A;ID;0x001200a9;;;ED)
DSACL: O:DAG:DAD:AI(A;ID;0x001f01ff;;;DA)(A;ID;0x001f01ff;;;EA)(A;ID;0x001f01ff;;;SY)(A;ID;0x001200a9;;;AU)(A;ID;0x001200a9;;;ED)

Comment 7 Arvid Requate 2020-06-11 17:06:05 CEST

Nice, ok then the next step after merging the patch in the product would be to imporove samba-tool ntacl sysvolcheck. That patch could possibly also be good for upstreaming, we should just quickly confirm again that the O:DA vs O:BA difference is also normal in MS AD, then the Samba-Team would welcome the patch.

Comment 12 Arvid Requate 2022-01-11 14:33:13 CET

Maybe we should make all groups "XID_TYPE_BOTH" in idmap.ldb
in addition to the change proposed in Comment 2.

In a quick experiment it gave this difference for a GPO created
by "Administrator" (i.e. this differs a bit from the original bug report):

1.After creation via GPMC as Administrator:
root@master60:~# ls -lrt /var/lib/samba/sysvol/ucs447pt1.dev/Policies/
[...]
drwxrwx---+ 4 *root*          Domain Admins 4096 Apr 14 12:56 {A5BBD83A-2913-499D-87CA-67F057012E69}

root@master60:~# samba-tool ntacl get --as-sddl /var/lib/samba/sysvol/ucs447pt1.dev/Policies/\{A5BBD83A-2913-499D-87CA-67F057012E69\}/
O:*DA*G:DAD:PAI(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)

2. After subsequent sysvolreset:
root@master60:~# ls -lrt /var/lib/samba/sysvol/ucs447pt1.dev/Policies/
[...]
drwxrwx---+ 4 *Administrator* Domain Admins 4096 Apr 14 12:44 {A5BBD83A-2913-499D-87CA-67F057012E69}

root@master60:~# samba-tool ntacl get --as-sddl /var/lib/samba/sysvol/ucs447pt1.dev/Policies/\{A5BBD83A-2913-499D-87CA-67F057012E69\}/
O:*LA*G:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)

3. After setting XID_TYPE_BOTH for "Domain Admins" I create a new GPO:
root@master60:~# ls -lrt /var/lib/samba/sysvol/ucs447pt1.dev/Policies/
[...]
drwxrwx---+ 4          *5000* Domain Admins 4096 Apr 14 12:57 {B151E40F-54B6-494C-8F76-33D14DA36525}

root@master60:~# samba-tool ntacl get --as-sddl /var/lib/samba/sysvol/ucs447pt1.dev/Policies/\{B151E40F-54B6-494C-8F76-33D14DA36525\}/
O:*DA*G:DAD:PAI(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)

4. After sysvolreset: No change

Also, "samba-tool gpo aclcheck" is not printing an error message in this case.


Please note that I'm talking about the permissions of the top GPO *directories*.
The files and directories below it seem to be just fine (at least in this case,
where the Administrator created the GPOs), as they are owned by "Administrator",
i.e. by RID 500, or "O:LA" for short straight away after creation via GPMC and
this doesn't seem to change when running sysvolreset.

I tested this with  4.4-8 errata1146 but also errata1087 (i.e. prior to the
November 2021 Samba security update) showed the same behavior.

Comment 13 Arvid Requate 2023-06-15 11:19:45 CEST

We should adjust the "--mask-msad-differences" option patch to also cover this.