[Samba] sysvolreset doesn't reset all ACLs

[Sven Schwedas]

Time to take a step back: My original problem is that clients can no
longer read or update their GPOs.


gpupdate fails on the default domain policy, claiming it can't read some
files. If I open said file via Explorer on the same user account, it
works – with \\domain\sysvol\… as well as when browsing every single DC
individually via \\foo-dc\sysvol\…

It's hard to tell (I'm running tail -f on 4 different DCs in parallel on
a production domain, so lots of noise), but as far as I can see, even at
debug level 8 there's no error message when running gpupdate on clients.
I get debug log info indicating that the machines log in successfully,
nothing else.


On one client (my personal Windows 7 VM, logged in with a domain admin)
I don't even get that far, and get an "user could not be resolved" error
instead (paraphrased, German Windows 7).


sysvolreset, as mentioned, doesn't work, neither on a blank directory
(fails with file not found), nor on a full directory (no error, but no
effect either). Restoring permissions via GPMC snap-in doesn't give an
error either, and is no longer offered, apparently there's no
inconsistency it can detect.

Domain Admins used to have a gid set, this was corrected before my last
attempt to restore permissions via GPMC. (A dummy `Unix Domain Admins`
group was added to take over the NIS members.)

Enterprise Admin used to have a gid set, too. By the time I realized it,
GPMC no longer complained about wrong permissions, and I can't request
it to fix the permissions.


Testparm output is attached.


Out of sheer boredom I ended up trying a modified script to change POSIX
ACLs:

> #! /bin/bash
> chown -R root:root sysvol
> setfacl -bR sysvol
> 
> setfacl -Rm  'g:Domain Users:rX' sysvol
> setfacl -Rm  'g:Domain Computers:rX' sysvol
> setfacl -Rm  'g:Unix Domain Admins:rwX' sysvol
> 
> setfacl -dRm 'g:Domain Users:rX' sysvol
> setfacl -dRm 'g:Domain Computers:rX' sysvol
> setfacl -dRm 'g:Unix Domain Admins:rwX' sysvol

After running this, regular clients can now run GPOs, *despite* all DCs
running with `acl_xattr:ignore system acls = yes` on sysvol!


This obviously makes no bloody sense whatsoever, but it works.


Only remaining stubborn client is my VM, which still can't find…
something. I'm not sure if it's even related to this issue, or an
unrelated trust relationship issue.

-- 
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
Mail/XMPP sven.schwedas at tao.at | Skype sven.schwedas
TAO Digital | Lendplatz 45 | A8020 Graz
https://www.tao-digital.at | Tel +43 680 301 7167
-------------- next part --------------
[global]
	realm = AD.TAO.AT
	workgroup = AD
	dns forwarder = 85.214.20.141
	ldap server require strong auth = No
	ldap ssl ads = Yes
	logging = syslog
	disable spoolss = Yes
	load printers = No
	printcap name = /dev/null
	kerberos method = system keytab
	passdb backend = samba_dsdb
	server role = active directory domain controller
	tls cafile = /usr/local/share/ca-certificates/tao-ad-ca.crt
	tls certfile = /etc/ssl/certs/graz-dc.ad.tao.at.crt
	tls keyfile = /etc/ssl/private/graz-dc.ad.tao.at.key
	template homedir = /home/%U
	template shell = /bin/zsh
	rpc_server:tcpip = no
	rpc_daemon:spoolssd = embedded
	rpc_server:spoolss = embedded
	rpc_server:winreg = embedded
	rpc_server:ntsvcs = embedded
	rpc_server:eventlog = embedded
	rpc_server:srvsvc = embedded
	rpc_server:svcctl = embedded
	rpc_server:default = external
	winbindd:use external pipes = true
	dsdb:schema update allowed = true
	idmap_ldb:use rfc2307 = yes
	idmap config * : backend = tdb
	map archive = No
	map readonly = no
	store dos attributes = Yes
	include = /etc/samba/site.conf
	printing = bsd
	vfs objects = dfs_samba4 acl_xattr


[homes]
	msdfs proxy = \\graz-file\homes
	msdfs root = Yes


[netlogon]
	path = /var/lib/samba/sysvol/ad.tao.at/scripts
	read only = No
	acl_xattr:ignore system acls = yes


[sysvol]
	path = /var/lib/samba/sysvol
	read only = No
	acl_xattr:ignore system acls = yes