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

[Stefan Bellon]

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?

Greetings,
Stefan

-- 
Stefan Bellon