Univention Bugzilla – Bug 39674
Inconsistent sysvol ACLs
Last modified: 2023-03-25 06:51:01 CET
In a customer setup the POSIX ACLs were only set for the first GPO folder for example after adding a group to the GPO in the security filtering. All subfolders and the GPT.INI file didn't change the POSIX ACLs. samba-tool ntacl sysvolreset changed the POSIX ACLs for all folders like expected. The customer uses UCS 3.2-7.
As a first workaround, I've written a Listener module which resets the ACLs. If the connector/s4/mapping/gpo/ntsd is set to false, the following steps are required: wget http://updates.software-univention.de/download/temp/samba-gpo-acl-reset/msGPOSecurityDescriptor.py chmod +x msGPOSecurityDescriptor.py ./msGPOSecurityDescriptor.py --write2ucs # wait until the connector has finished ucr set connector/s4/mapping/gpo/ntsd='true' /etc/init.d/univention-directory-listener restart Afterwards, the listener module can be activated: wget http://updates.software-univention.de/download/temp/samba-gpo-acl-reset/reset-sysvol-acls.py cp reset-sysvol-acls.py /usr/lib/univention-directory-listener/system/ /etc/init.d/univention-directory-listener restart The tool can also be used to reset the ACLs for one GPO in the filesystem: ./reset-sysvol-acls.py -g E989AD1F-680A-45B2-91EE-688979A5FC8
Created attachment 7237 [details] reset-sysvol-acls.py
Created attachment 7238 [details] msGPOSecurityDescriptor.py
Ticket #2014042221007541
This happend again at Ticket#2016041121000224
It should be added in UCS 4.1.
(In reply to Stefan Gohmann from comment #0) > In a customer setup the POSIX ACLs were only set for the first GPO folder > for example after adding a group to the GPO in the security filtering. All > subfolders and the GPT.INI file didn't change the POSIX ACLs. We've discussed it again internally and we are not sure if we checked all Samba DCs in the customer environment. It is possible that the GPO tool did the LDAP changes on one DC and the filesystem change on a different DC. The listener module should only be executed on a system with the S4 connector and the reset should be performed in listener postrun.
The listener module has been added: r70616 + r70617 + r70618 YAML file: r70619 The listener module can also be used to reset the POSIX file ACLs of one GPO, for example: root@master411:~# /usr/lib/univention-directory-listener/system/reset-sysvol-acls.py -g 6AC1786C-016F-11D2-945F-00C04FB984F9 18.11.15 12:59:38.279 DEBUG_INIT 18.11.15 12:59:38.913 LISTENER ( PROCESS ) : Setting ACLs for: /var/lib/samba/sysvol/deadlock41.intranet/Policies/{6AC1786C-016F-11D2-945F-00C04FB984F9} root@master411:~#
The postitive things first, this works: * normal listener handler for new/modified GPO * listener-ctrl resync * handler only runs on S4-Connector host (defined by connector/s4/autostart=yes) * also works in case samba itself is not running currently * manual use as script (on any Samba/AD DC) BUT: Unfortunately this interferes destructively with sysvol-sync. I thought about the following to two cases. Experimenting with it showed that the first one is uncritical but the second one reverts GPO changes as can be seen in the second example below: 1. New GPO is created: No problem Assume an MS Client creates a GPO in Samba/AD and the corresponding files in sysvol on some DC that is not running the S4-Connector. The files have timestamp t0. Then the listener postrun resets the NTACLs (plus facls) on the S4-Connector host at time t1, about 15 seconds later (order of magnitude). If sysvol-sync has not run in the mean time, then the listener-modules will have not effect. This can be seen like this: root@backup11:~# samba-tool gpo create GPO3 -U Administrator%univention GPO 'GPO3' created as {23C166A9-E17A-443B-9477-33572B634921} results in these messages in the listener.log on the Master: ============================================================================= 23.11.15 22:12:55.859 LISTENER ( INFO ) : running postrun handlers 23.11.15 22:12:55.859 LISTENER ( INFO ) : postrun handler: nfs-homes (prepared=0) 23.11.15 22:12:55.859 LISTENER ( INFO ) : postrun handler: reset-sysvol-acls (prepared=-1) 23.11.15 22:12:56.007 LISTENER ( WARN ) : Policy not found: /var/lib/samba/sysvol/ar41i1.qa/Policies/{23C166A9-E17A-443B-9477-33572B634921} ============================================================================= That's probably not a problem, because sysvol-sync will fix it later. 2. An existing GPO ACL is modified: Problem: If the MS Client tool also changes something about the GPO content, and the files are modified on a sysvol share on some DC "B" that is not running the S4-Connector at t0, and the sysvol-sync does not happen by chance before the listener postrun resets the sysvol acls of that GPO, then the files will probably have an mtime of t1>t0 and this would probably cause sysvol-sync to overwrite the files on DC "B" with the old versions as found on the S4-Connector host. Like this: ============================================================================ root@backup11:~# sed -i 's/Version=0/Version=1/' /var/lib/samba/sysvol/ar41i1.qa/Policies/\{23C166A9-E17A-443B-9477-33572B634921\}/GPT.INI; echo -e "dn: CN={23C166A9-E17A-443B-9477-33572B634921},CN=Policies,CN=System,DC=ar41i1,DC=qa\nchangetype: modify\nreplace: versionNumber\nversionNumber: 1" | ldbmodify -H /var/lib/samba/private/sam.ldb Modified 1 records successfully root@backup11:~# cat /var/lib/samba/sysvol/ar41i1.qa/Policies/\{23C166A9-E17A-443B-9477-33572B634921\}/GPT.INI [General] Version=1 root@backup11:~# LANG=C stat /var/lib/samba/sysvol/ar41i1.qa/Policies/\{23C166A9-E17A-443B-9477-33572B634921\}/GPT.INI File: `/var/lib/samba/sysvol/ar41i1.qa/Policies/{23C166A9-E17A-443B-9477-33572B634921}/GPT.INI' Size: 22 Blocks: 16 IO Block: 4096 regular file Device: fd00h/64768d Inode: 784904 Links: 1 Access: (0770/-rwxrwx---) Uid: ( 2002/Administrator) Gid: ( 5000/Domain Admins) Access: 2015-11-23 22:38:43.588425801 +0100 Modify: 2015-11-23 22:37:40.899499529 +0100 Change: 2015-11-23 22:37:40.899499529 +0100 Birth: - ============================================================================ Then the listener resets the NTACLs: ============================================================================ root@master10:~# LANG=C stat /var/lib/samba/sysvol/ar41i1.qa/Policies/\{23C166A9-E17A-443B-9477-33572B634921\}/GPT.INI File: `/var/lib/samba/sysvol/ar41i1.qa/Policies/{23C166A9-E17A-443B-9477-33572B634921}/GPT.INI' Size: 22 Blocks: 16 IO Block: 4096 regular file Device: fd00h/64768d Inode: 527036 Links: 1 Access: (0770/-rwxrwx---) Uid: ( 2002/Administrator) Gid: ( 5000/Domain Admins) Access: 2015-11-23 22:38:47.432000000 +0100 Modify: 2015-11-23 22:38:02.304000000 +0100 Change: 2015-11-23 22:38:02.304000000 +0100 Birth: - ============================================================================ Then, a couple of minutes later sysvol-sync runs and overwrites the changes made on the GPO files in the sysvol of the "other" DC: ============================================================================ root@backup11:~# LANG=C stat /var/lib/samba/sysvol/ar41i1.qa/Policies/\{23C166A9-E17A-443B-9477-33572B634921\}/GPT.INI File: `/var/lib/samba/sysvol/ar41i1.qa/Policies/{23C166A9-E17A-443B-9477-33572B634921}/GPT.INI' Size: 22 Blocks: 16 IO Block: 4096 regular file Device: fd00h/64768d Inode: 784909 Links: 1 Access: (0770/-rwxrwx---) Uid: ( 2002/Administrator) Gid: ( 5000/Domain Admins) Access: 2015-11-23 22:40:48.483183861 +0100 Modify: 2015-11-23 22:38:02.000000000 +0100 Change: 2015-11-23 22:40:48.483183861 +0100 Birth: - root@backup11:~# cat /var/lib/samba/sysvol/ar41i1.qa/Policies/\{23C166A9-E17A-443B-9477-33572B634921\}/GPT.INI [General] Version=0 ============================================================================ This is a major issue, because not only the changes get reverted but also all other clients will reject the existing GPO because the GPO container version in Samba/AD LDAP now is "1" but the corresponding GPT.INI has Version=0 again.
The more I think about it, the more I think that we might need to consider restricting GPO changes to one Samba AD/DC only in some way. The only other option, that comes to my mind currently, is to add a "postexec" to the sysvol share definition which somehow detects GPO file changes and fixes the NTACLs. Sounds ugly and might depend on the behaviour of the MS Client. As a reminder: Why do we *think* we need to fix anything here at all? As far as I recall, network traces in the customer environment indicated that the Windows client did not *even* attempt to modify NTACLs at all in the sysvol share. Maybe we can identify the situation better? When the Windows client connects to the //domain.name/sysvol share it goes through two indirections: 1. domain.name is resolved via DNS which round robin returns one of the set of registered Samba AD/DCs. 2. The Windows Client connects to the sysvol DFS share on that IP and the special DFS handling code for the sysvol returns a randomized address. From the top of my head I currently don't know if this is still the case, as there is an smb.conf parameter "msdfs shuffle referrals" now which defaults to "no". Possibly our network trace analysis was not complete and there was another DC? Or maybe even just an obsolete second IP address registered? I know, that's not very convincing yet..
(In reply to Arvid Requate from comment #9) > This is a major issue, because not only the changes get reverted but also > all other clients will reject the existing GPO because the GPO container > version in Samba/AD LDAP now is "1" but the corresponding GPT.INI has > Version=0 again. Excellent catch. That is indeed a serious problem. I've removed the patches (r70906 + r70907). (In reply to Arvid Requate from comment #10) > Possibly our network trace analysis was not complete and there was another > DC? Or maybe even just an obsolete second IP address registered? Yes, I guess we need to reproduce the original error. I'll try to get more information from the customer systems.
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4. If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
This issue has been filed against UCS 3.2. UCS 3.2 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen this issue. In this case please provide detailed information on how this issue is affecting you.