Bug 50085

Summary:	GPT.INI NTACL in sysvol doesn't allow "Domain Users" after adding them to GPO security filtering
Product:	UCS	Reporter:	Arvid Requate <requate>
Component:	Samba4	Assignee:	Samba maintainers <samba-maintainers>
Status:	NEW ---	QA Contact:	Samba maintainers <samba-maintainers>
Severity:	normal
Priority:	P5	CC:	damrose, grandjean, heidelberger, jalbani, michelsmidt, peichert, salm, scheinig, zumvorde
Version:	UCS 4.4
Target Milestone:	---
Hardware:	Other
OS:	Linux
See Also:	https://forge.univention.org/bugzilla/show_bug.cgi?id=51352
What kind of report is it?:	Bug Report	What type of bug is this?:	3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?:	3: Will affect average number of installed domains	How will those affected feel about the bug?:	3: A User would likely not purchase the product
User Pain:	0.154	Enterprise Customer affected?:
School Customer affected?:		ISV affected?:
Waiting Support:		Flags outvoted (downgraded) after PO Review:
Ticket number:		Bug group (optional):
Max CVSS v3 score:
Bug Depends on:	49293
Bug Blocks:

Description Arvid Requate

2019-08-29 14:06:23 CEST

During QA for Bug #49293, we found that there is an actual NTACL inconsistency for the GPT.INI file of a GPO, if an Administrator modifies the security filtering for the GPO via GPMC.

This acutally became apparent because the fix of Bug #49293 avoids an exception at an earlier stage, aborting sysvolcheck before it could report this.

Erik created a GPO via MS-GPMC, and adjusted the security filter by removing "Authenticated Users" and adding "Domain Admins" instead. Then he runs "samba-tool ntacl sysvolreset". Then he adjusted the security filtering a second time, removing "Domain Admins" and adding "Domain Users".

After these steps, the GPO.INI of the GPO doesn't have an ACE-Entry for "Domain Users" ("DU"):

========================================================================
root@ucsmaster:~# samba-tool ntacl sysvolcheck --mask-msad-differences

ProvisioningError: DB NTACL of GPO file /var/lib/samba/sysvol/mydomain.intranet/Policies/{8EAD3636-8544-41B5-8A7F-4098353A9232}/GPT.INI does not match value expected from GPO object
FSACL: O:DAG:DAD:ARAI(A;ID;0x001d0156;;;DA)(A;ID;0x001f01ff;;;EA)(A;ID;0x001f01ff;;;SY)(A;ID;0x001200a9;;;ED)
DSACL: O:DAG:DAD:ARAI(A;ID;0x001d0156;;;DA)(A;ID;0x001f01ff;;;EA)(A;ID;0x001f01ff;;;SY)(A;ID;0x001200a9;;;ED)(A;ID;0x001200a9;;;DU)

ProvisioningError: VFS NTACL of GPO file /var/lib/samba/sysvol/mydomain.intranet/Policies/{8EAD3636-8544-41B5-8A7F-4098353A9232}/GPT.INI does not match value expected from GPO object
FSACL: O:DAG:DAD:ARAI(A;ID;0x001d0156;;;DA)(A;ID;0x001f01ff;;;EA)(A;ID;0x001f01ff;;;SY)(A;ID;0x001200a9;;;ED)
DSACL: O:DAG:DAD:ARAI(A;ID;0x001d0156;;;DA)(A;ID;0x001f01ff;;;EA)(A;ID;0x001f01ff;;;SY)(A;ID;0x001200a9;;;ED)(A;ID;0x001200a9;;;DU)
========================================================================

This is not a shortcoming of sysvolcheck, but either a samba bug or a strange behaviour of a Windows 7 client in a Samba/AD domain.

Comment 1 Arvid Requate

2019-08-29 14:08:09 CEST

I quickly checked the behaviour of the same Windows 7 client (reverted) joined with a Windows 2008R2 AD/DC, following the same steps and in the end I see in the sysvol of the AD server that the GPT.INI has the expected new ACE for Domain Users:
==============================================================================
## smbclient //adserver/sysvol -c "showacls; cd ....; ls GPT.INI"
        ACE
                type: ACCESS ALLOWED (0) flags: 0x10 SEC_ACE_FLAG_INHERITED_ACE 
                Specific bits: 0xa9
                Permissions: 0x1200a9: SYNCHRONIZE_ACCESS READ_CONTROL_ACCESS 
                SID: S-1-5-21-2164597659-499232197-2097272722-513
==============================================================================

Comment 2 J Albani 2019-09-24 13:40:54 CEST

Just an Addition to this Problem. After Changes in the Security Filters, Clients can´t read GPOs reliable anymore until a sysvolreset is done. We had Tickets where Teachers could not use their USB-Drives because the GPO that allowed that wasn´t applied. 
The errors where in a different GPO, not the one that managed USB-Drive access.

Comment 3 Arvid Requate

2019-10-01 15:00:25 CEST

Thank you for your comment, I would recommend that you directly open a support ticket if you face this issue again, so we can have a look at your specific situation.

Comment 5 Arvid Requate

2020-05-25 19:46:17 CEST

Re: Comment 4: I don't see the same problem in that output. The only difference I see there between the FSACL and the DSACL is the P vs. PAI vs PAR inheritance flags. See Bug #49293 and rerun with the new sysvolcheck option. The output is also much more readable than the default output.