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

[L.P.H. van Belle]

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