[Samba] GID mappings of built-in groups when addin additional dc

[Rowland Penny]

On Sun, 2 Oct 2016 12:58:53 +0200
Achim Gottinger via samba <samba at lists.samba.org> wrote:

> 
> 
> Am 02.10.2016 um 12:44 schrieb Achim Gottinger via samba:
> >
> >
> > Am 02.10.2016 um 12:24 schrieb Rowland Penny via samba:
> >> On Sun, 2 Oct 2016 11:45:15 +0200
> >> Achim Gottinger via samba <samba at lists.samba.org> wrote:
> >>
> >>>
> >>> Am 02.10.2016 um 08:20 schrieb Trenta sis via samba:
> >>>> Hi,
> >>>>
> >>>> I have a samba 4.4.5 AD domain and is working perfect, but now I
> >>>> need to add a second samba 4 AD, I have found that in
> >>>> https://wiki.samba.org/index.php/Join_an_additional_Samba_DC_to_an_existing_Active_Directory 
> >>>>
> >>>> is detailed the correct steps, my question is about step related
> >>>> with winbind (tdbbackup) builtin groups, appears a message
> >>>> "*NOTE: Only do this if you are running a version of Samba
> >>>> before 4.2.0 or are using the built-in winbind.*" but I'm not
> >>>> sure if in my environment I have to make this step.
> >>>>
> >>>> I have installed and configured samba 4.4.5 from sources and only
> >>>> added
> >>>> https://wiki.samba.org/index.php/Setup_Samba_as_an_AD_Domain_Member#libnss_winbind 
> >>>>
> >>>> https://wiki.samba.org/index.php/Libnss_winbind_links
> >>>>
> >>>> In my environment is needed tdbbackup when you adds second dc?
> >>>>
> >>>> Thanks
> >>> The step "GID mapping of build-in groups" is still required with
> >>> 4.4.5, no matter if you use winbind or winbindd.
> >>>
> >> This is no longer required on any supported version of Samba, you
> >> just need to run 'samba-tool ntacl sysvolreset'
> >>
> >> Rowland
> > We discussed this a while back, back then you did not have the time
> > to compare your rsync setup.
> >
> > It is still required if you do not want to run sysvolreset after
> > each rsync of the sysvol folders
> If the mappings in idmap.tdb are not the same there will always be an 
> small timeframe with incorrect access rights on sysvol.
> If an clients connects in this timeframe it may not have access to
> gpo's and scripts. Or even worse an attacker may have unwanted access
> rights on the sysvol share.
> 
> 

There is some validity in what you say, there is a slight risk, but it
is a small one.
osync has the facilty to run scripts before and after the sync, I
suppose you could run a script before the sync that took the DC
offline, synced sysvol, then ran another script after the sync that
reset sysvol and then puts the DC back on line. That way there would be
no risk at all.

Rowland