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.
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 ==============================================================================
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.
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.
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.
This issue has been filed against UCS 4.4. UCS 4.4 is out of maintenance and components may have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer versions, please use "Clone this bug" or reopen this issue. In this case please provide information on how this issue is affecting you.