[Samba] BUILTIN not mapping on DC

[steve]

On Tue, 2014-04-29 at 18:27 +0200, Achim Gottinger wrote:
> Am 29.04.2014 10:28, schrieb steve:
> > On Tue, 2014-04-29 at 01:32 +0200, Achim Gottinger wrote:
> >> Am 29.04.2014 01:13, schrieb steve:
> >>> On Tue, 2014-04-29 at 00:54 +0200, Achim Gottinger wrote:
> >>>> Am 29.04.2014 00:30, schrieb steve:
> >>>>> On Mon, 2014-04-28 at 22:39 +0100, Rowland Penny wrote:
> >>>>>
> >>>>>>>> 3000000 ---> CN=S-1-5-32-544
> >>>>>>>> 3000001 ---> CN=S-1-5-32-549
> >>>>>>>> 3000002 ---> CN=S-1-5-18
> >>>>>>>> 3000003 ---> CN=S-1-5-11
> >>>>>>>>
> >>>>>>>> now open idmap.ldb on the second DC and carry out the search with the
> >>>>>>>> second set of numbers:
> >>>>>>>>
> >>>>>>>> 3000000 ---> CN=S-1-5-32-544
> >>>>>>>> 3000012 ---> CN=S-1-5-11
> >>>>>>>> 3000022 ---> CN=S-1-5-32-549
> >>>>>>>> 3000023 ---> CN=S-1-5-18
> >>>>>>>>
> >>>>>>>> and a bit more searching finds out that:
> >>>>>>>>
> >>>>>>>> CN=S-1-5-32-544 ---> Administrators
> >>>>>>>> CN=S-1-5-32-549 ---> Server Operators
> >>>>>>>> CN=S-1-5-18 ---> Local System
> >>>>>>>> CN=S-1-5-11 ---> Authenticated Users
> >>>>>>>>
> >>>>> It's unfortunate that we can't use AD for rfc2307 for these objects as
> >>>>> we can with domain equivalents. I think the OP wants consistent values
> >>>>> across DC's without having to run sysvol reset after syncing, in which
> >>>>> case his copying idmap.ldb to the other DC method from the master seems
> >>>>> like the only way to do it.
> >>>>>
> >>>>> Have we got that right? This thread is aiming at:
> >>>>>
> >>>>>>>> 3000000 ---> CN=S-1-5-32-544
> >>>>>>>> 3000001 ---> CN=S-1-5-32-549
> >>>>>>>> 3000002 ---> CN=S-1-5-18
> >>>>>>>> 3000003 ---> CN=S-1-5-11
> >>>>> for all DCs?
> >>>>> Cheers,
> >>>>> Steve
> >>>> The OP has found that BUILTIN groups do not resolve on the unix side at
> >>>> his ADDC. If they'd resolve using rsync -A would work with different
> >>>> idmap.ldb mappings because rsync and for example nfs3 would be able to
> >>>> do uid(source)->name(source)->name(target)->uid(target) mappings for
> >>>> copy operations. Without an proper uid->name mapping the uid's are used
> >>>> unodified.
> >>>> Having identical mappings on all dc's is an workaround for the not
> >>>> resolving issue.
> >>>>
> >>> OK. So we want identical uid mappings on all DCs for e.g. users, but not
> >>> for BUILTIN\x ??
> >>>
> >> If the idmap_autorid backend would work for BUILTIN we'd get identical
> >> mappings.
> >>
> > As we would with the ad backend if the schema allowed uidNumber with
> > BUILTIN objects.
> Indeed having the freedom to choose would be nice, guess it's an MS 
> restriction not to allow uid/gidNumber for BUILTIN objects samba just 
> inherits.
> On a sidenote i noticed roland and you seem to use the idmap_ad backend 
> on ADDC's. I did not configure the backend after classic upgrade 
> provisioning and use the default idmap_tdb.
> Is the idmap_ad backend an requirement because you are using sssd?
> 
Hi
After the classic upgrade you will have uid and gid numbers for your
users so it makes sense to use the information that you already have in
AD rather than extracting it into yet another database. Retaining the
attributes in one place makes replication much simpler: the uid:gid pair
is the same everywhere in the domain. If we had to use winbind we'd
choose idmap_ad but as we use sssd we use its ad backend instead.

The problem with the BUILTIN groups is that they are schema specified as
groups and so we cannot specify a uid for them.
HTH
Steve