[Samba] BUILTIN not mapping on DC
Rowland Penny
rowlandpenny at googlemail.com
Tue Apr 29 10:39:01 MDT 2014
On 29/04/14 17:27, 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.
I think the problem is that in AD the object is either a user or a
group, but on Linux you can have user AND a group with the same name.
What this means is that whilst I am fairly sure that you could add a
gidNumber to a lot of the builtins because they have a group
objectClass, you cannot add a uidNumber because they do not have the
user objectClass.
> 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.
The reason that I use the ad backend is to use the uidNumber's &
gidNumber's stored in ad, I find it easier to store all my users in the
same place.
> Is the idmap_ad backend an requirement because you are using sssd?
>
No, sssd will work without the uidNumber's & gidNumbers (provided you
set sssd correctly) but you will end up with some very large uidNumbers etc
Rowland
More information about the samba
mailing list