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

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

On 03/04/2021 23:01, Stefan Bellon wrote:
> On Sat, 03 Apr, Rowland penny via samba wrote:
>
>> What version of Windows are you using ?
> This is Windows Server 2016 Standard 1607.
>
> 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.

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

Where it says:

Having decided which winbind backend to use, you now have a further 
decision to make, the ranges to use with 'idmap config' in smb.conf. By 
default on a Unix domain member, there are multiple blocks of users & 
groups:

  * The local system users & groups: These will be from 0-999
  * The local Unix users and groups: These start at 1000
  * The 'well Known SIDs': ?????
  * The DOMAIN users and groups: ADUC, by default, starts these at 10000
  * Trusted domains: ?????
  * Anything that isn't a 'well Known SID' or a member of DOMAIN or
a
    trusted domain:?????


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.


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

Ah, so it was provisioned as a Samba AD domain, to which you have joined 
further Samba AD DC's, but have you joined the 'Windows Server 2016'
as
a DC ? If so, how ? and if you have somehow managed to join it, your 
domain is now borked ?
>
> 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).

There isn't such a document, probably because the GPO's are not only 
stored in sysvol, they are in AD as well.

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) and I would suggest starting any required uidNumber & 
gidNumber attributes from 10000. 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.

Rowland