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

On 03/04/2021 10:26, Stefan Bellon via samba wrote:
> Hi all,
>
> I decided to split this topic away from my other thread with the
> subject "Failed to prepare gensec:
NT_STATUS_INVALID_SERVER_STATE"
> because I really think, I should focus on the Sysvol permissions first.
>
> Also I am focussing on DC1 now, without rsync/unison replication because
> first of all, it has to work smoothly on DC1 alone.
>
> After a "sysvolreset" I have a structure where
"sysvolcheck" succeeds
> and where a "Test Policy" GPO e.g. has the following permissions:
>
>
> And as a consequence, "sysvolcheck" fails with:
>
> 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;;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:P(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

What version of Windows are you using ?

If you look closely at the above , you will see that it is expected that 
the ownership will be ' O:DAG:DA', but you have 'O:BAG:DU'

'O' = owner

'G' = group

'DA' = Domain Admins'

'BA' = BUILTIN\Administrators

'DU' = Domain Users

I seem to remember that you have given Domain Admins a gidNumber, this 
will stop the group owning anything.
> ID mapping is as follows:
>
> ID '3000000' Has SID 'S-1-5-32-544' with the name
'BUILTIN\Administrators 4'
> ID '3000001' Has SID 'S-1-5-32-549' with the name
'BUILTIN\Server Operators 4'
> ID '3000002' Has SID 'S-1-5-18' with the name 'NT
AUTHORITY\SYSTEM 5'
> ID '3000003' Has SID 'S-1-5-11' with the name 'NT
AUTHORITY\Authenticated Users 5'
> ID '3000004' Has SID
'S-1-5-21-37643267-2172530850-1818422998-520' with the name
'DS\Group Policy Creator Owners 2'
> ID '3000006' Has SID
'S-1-5-21-37643267-2172530850-1818422998-519' with the name
'DS\Enterprise Admins 2'
> ID '3000008' Has SID
'S-1-5-21-37643267-2172530850-1818422998-512' with the name
'DS\Domain Admins 2'
> ID '3000010' Has SID 'S-1-5-9' with the name 'NT
AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS 5'

The above are all 'Well Known SID's'

see here: 
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab
> ID '100' Has SID
'S-1-5-21-37643267-2172530850-1818422998-1118' with the name
'DS\developers 2'

This is interesting, '100' is the Unix ID for the 'users' group
and is
usually mapped to Domain Users in idmap.ldb, I take it you created 
'developers', but did you give it a gidNumber attribute ?
>
> I really don't understand what I am seeing there.

Fairly simple, the 'ID' is the Unix ID, the SID, is well the objects 
domain SID , finally the 'name' is the objects name.
> What do I have to change in my setup in order to be able to edit GPOs
> from Windows RSAT without breaking permissions on the Sysvol share?

Not sure, because I don't know how you got in this position in the first 
place, have you got any notes on how you installed the DC's, if so, send 
me a copy and I will see if there is something wrong.

Rowland

>
> Any help is greatly appreciated.
>
> Greetings,
> Stefan
>

On Sat, 03 Apr, Rowland penny via samba wrote:
> What version of Windows are you using ?
This is Windows Server 2016 Standard 1607.
> If you look closely at the above , you will see that it is expected
> that the ownership will be ' O:DAG:DA', but you have
'O:BAG:DU'
> 
> 'O' = owner
> 
> 'G' = group
> 
> 'DA' = Domain Admins'
> 
> 'BA' = BUILTIN\Administrators
> 
> 'DU' = Domain Users
> 
> I seem to remember that you have given Domain Admins a gidNumber,
> this will stop the group owning anything.
I think this is a misunderstanding. I did not give the "Domain Admins"
group a gidNumber. One of the users who is in the group "Domain
Admins"
has a gidNumber (but 50, not 100). For the tests here, I used another
user from the "Domain Admins" group who does not have a gidNumber
attribute.
> > ID '100' Has SID
'S-1-5-21-37643267-2172530850-1818422998-1118'
> > with the name 'DS\developers 2'  
> 
> This is interesting, '100' is the Unix ID for the 'users'
group and
> is usually mapped to Domain Users in idmap.ldb, I take it you created 
> 'developers', but did you give it a gidNumber attribute ?
Yes, "developers" is a group in our AD which happens to have gidNumber
100, however I don't understand why this is appearing here. The user
(of group "Domain Admins") that I used to perform the change in the
Test Group Policy is not a member of group "developers".
> > I really don't understand what I am seeing there.  
> 
> Fairly simple, the 'ID' is the Unix ID, the SID, is well the
objects
> domain SID , finally the 'name' is the objects name.
Yes, sorry, what I meant is not that I don't understand UIDs, SIDs and
cleartext names, but that I don't understand how and why the
"developers" (gidNumber 100) are appearing here.
> > What do I have to change in my setup in order to be able to edit
> > GPOs from Windows RSAT without breaking permissions on the Sysvol
> > share?  
> 
> Not sure, because I don't know how you got in this position in the
> first place, have you got any notes on how you installed the DC's, if
> so, send me a copy and I will see if there is something wrong.
Basically, I *really* followed the setup procedure explained here:
https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory

I however have not set up the original Samba 4.2 server which initially
provisioned the domain and to which I joined.

After I joined the domain with the new Samba 4.13.5 instances, I backed
up the idmap.db on the Samba 4.2 and copied it over to the two new DCs
("tdbbackup -s .bak /var/lib/samba/private/idmap.ldb").

Also, I rsync'ed the /var/lib/samba/sysvol from the old 4.2 instance to
the two new ones ("rsync -XAavz --delete-after").

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

Greetings,
Stefan

-- 
Stefan Bellon