samba - Apr 2021 - Sysvol permission issue - how to repair permanently?

Hai,

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

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Stefan Bellon
via
> samba
> Verzonden: zondag 4 april 2021 13:51
> Aan: Rowland penny via samba
> Onderwerp: Re: [Samba] Sysvol permission issue - how to repair
> permanently?
> 
> On Sun, 04 Apr, Rowland penny via samba wrote:
> 
> > Why is that users Unix group ID '50', that is the ID for the
group
> > 'staff' on Debian, you might want to read this:
> >
> >
> https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member#Confi
> guring_Samba
> 
> Ok, perhaps I have to explain a few decisions "of the past":
> 
> - somebody else set up the Samba 4.2 AD DC at a time when this was the
>   current version in Debian stable (at that time, years ago)
Yes, 2 out of 3 of my DC's originated from start and are still running 4.1.x
was my first DC2's, my last added DC started with 4.13.4
> 
> - this Samba AD manages the Windows domain where Windows clients have
>   joined the domain
Yes
> 
> - the GNU/Linux clients did not join as "domain members" but got
nslcd
>   configured and use LDAP to connect to the Samba AD and authenticate
>   users
No NSLCD is used anywhere in my lan. 
i followed the wiki and just winbind to join, but if its only about rights, 
Then this is not your problem.
> 
> - user / group management on the other hand is the same for Windows
>   and GNU/Linux, so all users/groups have Windows attributes as well
>   as UNIX attributes
Yes, same here.
(* i use a windows 7 pc to manage it mostly.) 
> 
> - GNU/Linux default groups "staff" (gid 50) and "users"
(gid 100) were
>   (ab)used and two groups in AD map to them with their gidNumber
>   attribute
I partly do this. This is a one way direction. 
this works fine    : WinUser with UID => can go into => Linux group 
this does not work : LinuxUser with UID => can NOT go into => windows
group
> 
> 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. 
Remove all rights from sysvol, recusivly. 
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. 

Now check the rest of your GPO's. 
> 
> > As you can see from the above, you shouldn't set either the
'*' or
> > 'DOMAIN' ranges to start at 999 or less, as they would
interfere with
> > the local system users & groups. You also should leave a space for
> > any local Unix users & groups, so starting the 'idmap
config' ranges
> > at 3000 seems to be a good compromise.
> 
> 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
> 
> > I hope you can see that using a number less than '10000' for
any
> > uidNumber or gidNumber attribute in AD isn't really a good idea.
> 
> Ok, I understood that now. However the two groups
> 
> developers (AD) <-> users (UNIX, gidNumber 50)
> core (AD) <-> staff (UNIX, gidNumber 100)
> 
> are in heavily use throughout different services since years and not
> easily changed. :-/
Create new groups, new GIDS, add the new group next to the old groups
Yeah, but of work but when its done.. its done.. 
> 
> > I 'think' it is happening because the uidNumber and gidNumber
> > attributes in AD appear to be too low. The RFC2307 attributes are
> > only used by Unix, Windows ignores them, but yours seem to be
> > interfering with the Unix system ID's.
> 
> I was expecting that only UNIX clients (which are not domain members but
> using LDAP directly) are using gidNumber (and other UNIX attributes) and
> Windows/macOS clients (which are domain members) are ignoring gidNumber
> (and the other UNIX attributes).
> 
> > > I however have not set up the original Samba 4.2 server which
> > > initially provisioned the domain and to which I joined.
> >
> > Ah, so it was provisioned as a Samba AD domain,
> 
> Yes, exactly - years ago.
> 
> > to which you have joined further Samba AD DC's,
> 
> Exactly, just now, two weeks ago.
> 
> > but have you joined the 'Windows Server 2016' as a DC ?
> 
> No, I only have Samba AD DCs (the old 4.2 and now two new 4.13.5), no
> Windows AD DCs at all. The Windows Server 2016 is just a domain member,
> not a DC.
> 
> > If so, how ? and if you have somehow managed to join it, your domain
> > is now borked ????
> 
> I hope not!
> 
> > > But actually, I could completely wipe the sysvol folder and setup
it
> > > from scratch with the proper permissions without too much effort.
I
> > > just don't see any guide anywhere of how to start the sysvol
folder
> > > from scratch (and especially what to look out for, not to end up
in
> > > the same situation again).
> >
> > There isn't such a document, probably because the GPO's are
not only
> > stored in sysvol, they are in AD as well.
> 
> But as I understand it, the values in AD and the permissions in sysvol
> have to be in sync, and the fact that they are not in sync here, is my
> problem.
> 
> Or am I misunderstanding?
No, correct, IDMAP needs to be copied.
> 
> So, my question is this: Can I freely choose whether I fix the IDs in
> AD or whether I fix the permissions in sysvol, so they match again -
> and stay that way? Or there some fixed requirement, that AD internally
> has to have certain IDs (so that I have to fix sysvol) or the other way
> round, that sysvol has some requirements (so that I have to adjust AD)?
> 
> > I suggest you start by fixing any 'low' uidNumber &
gidNumber
> > attributes in AD. Remove any that are set for the Well Known SID's
> > (except for Domain Users)
> 
> The Well Known SIDs do *NOT* have any gidNumber (or uidNumber)
> attribute set. Only users and groups that we created have them set (see
> "developers" and "core" above).
> 
> That is part of why I don't understand how the permissions can get in a
> broken state if I edit GPOs with a Domain Admins user.
> 
> > and I would suggest starting any required uidNumber & gidNumber
> > attributes from 10000.
> 
> 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.
> 
> > Note: you only need these ID's if you have Unix domain members
using
> > the winbind 'ad' backend. If you are not using the
'ad' backend, you
> > can remove all uidNumber & gidNumber attributes.
> 
> I do not even have any UNIX domain members at all, see above.
well, maybe you should setup one, what is the reason your not using a
"domain joined" member?

All my servers are AD-domain joined. 
> 
> Is this mixed AD/LDAP setup uncommon? 
Not uncommon but in 90% of the cases not needed, and winbind is the way then.
> The hope from the past was, that
> this will make things easier than joining UNIX members to the domain.
> Perhaps this was a wrong decision?
yeah, been there, done that.. 

what i would suggest, setup a VM, clone a AD/LDAP server into the VM
Use that as test server to migrate from ldap to AD-winbind 

> 
> Greetings,
> Stefan
> 
> --
> 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

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