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

[Rowland penny]

On 04/04/2021 12:51, Stefan Bellon wrote:
> 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#Configuring_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)
>
> - this Samba AD manages the Windows domain where Windows clients have
>    joined the domain
>
> - 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
>
> - 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
>
> - 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
>
> 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.
>
>> 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.
>
>> 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. :-/
>
>> 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?
>
> 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 ... :-(
>
>> 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.
>
> Is this mixed AD/LDAP setup uncommon? 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?


I wish I had a time machine, I could go back in time and tell you that 
using mapped ID's in this way was a bad idea.

Using nslcd at that time wasn't a bad idea, though unnecessary. You 
could easily change to Unix domain members, except for the ill advised 
group ID's and you could probably work around them.

Do you have this line in the Samba DC's smb.conf : idmap_ldb:use 
rfc2307  = yes

If you do, comment it out (using a ';' or '#') and see if that helps, it 
will make the DC's only use idmap.ldb and ignore any uidNumber & 
gidNumber attributes in AD.

Rowland