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

Tue Apr 6 09:42:07 UTC 2021

> -----Oorspronkelijk bericht-----
> Van: Stefan Bellon [mailto:bellon at axivion.com]
> Verzonden: dinsdag 6 april 2021 10:26
> Aan: L.P.H. van Belle via samba
> CC: L.P.H. van Belle
> Onderwerp: Re: [Samba] Sysvol permission issue - how to repair
> permanently?
> 
> 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;;;D
> A)
> does not match expected value
> O:DAG:DAD:PAR(A;OICI;0x001d0156;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x0
> 01f01ff;;;CO)(A;OICI;0x001d0156;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001
> 200a9;;;AU)(A;OICI;0x001200a9;;;ED)(A;OICI;0x001200a9;;;DA)
> from GPO object

> Somehow I think, this should not happen, right? 
No this should not happen. 
... well, yes and no, but both are correct, even with that error. 

my current DC's, running 4.13.7 also give that result. Also a sysvolcheck outout below here.. 

ERROR(<class 'samba.provision.ProvisioningError'>): uncaught exception - ProvisioningError: DB ACL on GPO file /var/lib/samba/sysvol/internal.dom.tld/Policies/{3D56BB7F-D514-4A28-95CE-EC2D35BD7471}/User/Registry.pol O:BAG:DUD:(A;;0x001f01ff;;;DA)(A;;0x001f01ff;;;EA)(A;;0x001f01ff;;;BA)(A;;0x001f01ff;;;SY)(A;;0x001200a9;;;AU)(A;;0x001200a9;;;ED) does not match expected value O:DAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) from GPO object

but that GPO is working fine. 
samba-tool expects values on some points that not needed to check in general, simple because you can setup in multiple ways. 

> One should be able to have a setup, where - even after changes to GPOs 
> from Windows - a "sysvolcheck" succeeds, right?

No, its not really needed, but if you really want to fix it, i would do it like this. 

samba-tool ntacl get --as-sddl \  /var/lib/samba/sysvol/internal.dom.tld/Policies/{3D56BB7F-D514-4A28-95CE-EC2D35BD7471}/User/Registry.pol

samba-tool ntacl set \
"O:DAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)" FOLDER2APPLY_HERE

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

well, offcourse it depends a bit on how you use it, but in general its 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?
With if you need the from "linux" accounts on the system also. 
Without if do dont need these groups from within linux. 
!!! but, keep in mint, your desiding this "per group" for ALL servers. 

ok, this is bit different for me compaired to about everyone else. 
My Domain Admins group does have a GID assigned. 
* NOTE, its NOT recommended todo this.. this totaly depends now how you setup.. 

> 
> > 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?) 

yes, correct, its same folder. 
Now, what i did years ago to fix this. 

copy sysvol to sysvol2 
setup the share sysvol2. 
configure sysvol exactly confirm how the microsoft documentation says it needs to. ( or, look at a windows server and copy the settings ) and re-apply that from within windows. 

> 
> > 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. :-(

No, anything below 59999 "can" conflict. 

samba atm starts with 10000 its within its default system range, so, 
All my net setups, as from Debian Bullseye 
(* applieing to new networks setups only) 
will use 60000-99999 for all samba "*" ranges 
100000-2000000 for Domain ranges. 

> 
> > > 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.
Yes, i know its is a lot of work. 

Now, this might help you to reduce the work, setup an other server.
its a tempairaly server, or, create a new share on the old server and start from that point. 

Get the old data/right from the folders, change these, re-apply on test server, and script around it. 

> 
> 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.

Yes both basicly, but i dont know how your network design is. 
I would split up this group developer, since it looks like your using 2 ways. 

for example, how my group names are. 
group_developer-users
group_developer-services

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

well, to help a hand here.. what i did, after moving all my data from a 13y old samba LDAP server to AD-domain. 

i suggest read these scripts what used for commands and why. 
https://github.com/thctlo/samba4/blob/master/samba-setup-share-folders.sh

https://github.com/thctlo/samba4/blob/master/samba-fix-userhome-recursive.sh 

Now think in finding you old groupnames and/or GIDS, i think you can use the
find command for that. 
and with the info from the script i showed you can collected the data, and re-apply it with a script. 

sure, its work but once its done, its done. 

and you will be more happy for years to come.. 

i hope this helps a bit. 

Greetz, 

Louis