[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