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

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

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

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