[Samba] Sysvol permission issue - how to repair permanently?

[Stefan Bellon]

On Tue, 06 Apr, L.P.H. van Belle via samba wrote:

> Im trying to read this threat but whats now the exact problem here.

The actual problem is, that after each change of some GPO from within
RSAT, "samba-tool ntacl sysvolcheck" complains:

root at dc1:~# samba-tool ntacl sysvolcheck
ERROR(<class 'samba.provision.ProvisioningError'>): uncaught exception
- ProvisioningError: DB ACL on GPO
file /var/lib/samba/sysvol/xxx/Policies/{F9E5E9AC-B120-454C-9F5E-AD7A32DF180F}/Machine/Registry.pol
O:BAG:DUD:(A;;0x001d0156;;;DA)(A;;0x001f01ff;;;EA)(A;;0x001f01ff;;;BA)(A;;0x001f01ff;;;SY)(A;;0x001200a9;;;AU)(A;;0x001200a9;;;ED)(A;;0x001200a9;;;DA)
does not match expected value
O:DAG:DAD:PAR(A;OICI;0x001d0156;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001d0156;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)(A;OICI;0x001200a9;;;DA)
from GPO object

Somehow I think, this should not happen, right? One should be able to
have a setup, where - even after changes to GPOs from Windows - a
"sysvolcheck" succeeds, right?

Or am I completely misunderstanding this and a failing "sysvolcheck" is
not a problem at all?

> > This was set up YEARS ago and is in use like this today, so I cannot
> > easily throw this overboard and set up everything differently. Group
> > policies however are not in heavily use, so I could completely
> > rebuild sysvol, if this would be a solution.  
>
> Setup the needed groups as you need to. 

With or without gidNumber in AD?

> Remove all rights from sysvol, recusivly. 

You mean via file share \\xxx\sysvol on Windows? (And then I assume the
same applies to \\xxx\netlogon as well?)

> run sysvolreset, or setup right as shown in my script. 
> re-apply it, goto GPO editor, klik all GPO's once.. if something is
> off in the backgroup, windows will complain, gives screen message,
> klik ok on that. and. Its fixed. 

Ok, I will give it a try.

> > But I assumed this only applies to UNIX domain members. We do not
> > have any UNIX domain members at all: On GNU/Linux all machines are
> > set up to use nslcd and LDAP directly, only Windows and macOS
> > machines are domain members of that domain.  
>
> it applies to anything you use.. just stay out the system range
> UID/GID ranges. 
> 
> cat /etc/adduser.conf and you see the "defaults" for UID/GID's

Yes, I have the vanilla Debian default there on all machines:

FIRST_SYSTEM_UID=100
LAST_SYSTEM_UID=999
FIRST_SYSTEM_GID=100
LAST_SYSTEM_GID=999
FIRST_UID=1000
LAST_UID=59999
FIRST_GID=1000
LAST_GID=59999

And yes, the only "conflicts" are the two groups "core" (gid 50) and
"developers" (gid 100) which are defined in AD (with gidNumber) and are
mapped to "staff" and "users" on GNU/Linux. :-(

> > This will not be possible as we have LOTS of folders and files on
> > shared drives that contain UNIX-style permissions with those gid 50
> > and gid 100 group permissions ... :-(  
> 
> Why is this not possible? 
> 1) you create a new windows group with GID.
> 2) you add local linux users to this group. 
> 3) you add the extra group to the needed folders. 
> 4) you stop useing CHMOD/CHOWN and start useing GETFACL and SETFACL 
> 5) its fixed.. 
> 
> use script around this, i know this works fine because i do these
> these here also. 

Ok, what I meant with "not possible" is rather "a lot of work", because
we used the AD groups to assign permissions in lots of services (some
AD, some LDAP) on one hand, but on the other hand there are lots of
GNU/Linux servers with file shares that also have group permissions
with 50 and 100 used all over the place.

So, in order to decouple "developer" group from gid 100, I either have
to introduce a new group for all AD services and then go through them
one by one and change AD integration to the new group, or I would have
to go through all file shares to find group ownership of gid 100 and
change it to something else.

I had hoped there was an easier solution, like mapping "Domain Users"
not to gid 100, but gid 3000100 or something like that.

Greetings,
Stefan

-- 
Stefan Bellon