[Samba] idmap & migration to rfc2307
rowlandpenny241155 at gmail.com
Sun Nov 8 20:34:34 UTC 2015
On 08/11/15 20:01, Michael Adam wrote:
> On 2015-11-08 at 20:34 +0100, buhorojo wrote:
>> On 07/11/15 19:57, Michael Adam wrote:
>>> On 2015-11-07 at 17:47 +0000, Jonathan Hunter wrote:
>>>> On 7 November 2015 at 17:01, Michael Adam <obnox at samba.org> wrote:
>>>>> Also, for all I know, the DC always has local unix user and group
>>>>> IDs, and does NOT use the rfc2307 attributes for this. (Unless
>>>>> this has changed recently, but I can't imagine how.) So there is
>>>>> nothing wrong with samba not using the rfc ids on the DC -- this is
>>>>> how it works by design.
>>>> Thanks Michael. I will see if I can use winbind locally instead of
>>>> sssd later this evening, now that I have fully switched to rfc2307
>>>> rather than algorithmic mappings.
>>>> One question on this, though - how is file ownership managed on the DC
>>> >from the samba side? I know DCs aren't "supposed" to be used as file
>>>> servers in the samba view of things (which is another story
>>>> altogether), but I can't understand why sometimes the ID mapping comes
>>> >from the rfc2307 attributes and then later on not.
>>> I don't understand that yet.
>>> As explained in my previous mail, what can happen is that
>>> a user first (before given a rfc unixID) gets its uid from the
>>> idmap.ldb, but as soon as there is a unixid in the rfc
>>> attributes in his ldap object, that should always be used.
>>> This is a per-user thing.
>>> It is not surpsising that an externally configured sssd
>>> (configured to use rfc in a ad, and hence behaving more like
>>> a domain member) possibly gives different results, and also
>>> consistently uses the rfc attrs, since that one does not
>>> have the fallback to idmap.ldb that samba has.
>> sssd's uses its own implementation of winbind
> I repeat: sssd does not implement winbind.
> It implements some parts of the winbind protocol.
> It is not a drop-in replacement for winbind(d).
> And the ad-dc forcefully uses winbindd anyways,
> so sssd is not at all an option.
>> and _always_ retrieves the same id from AD. Repeat, _always_.
>> Currently it and nslcd are the only way to obtain full rfc2307
>> and consistent ids on DCs. Neither winbind nor
>> winbindd can do so.
> Sure. winbindd can do it. use the idmap_ad module :-)
> The only problem exists in the ad/dc setup due to
> the fallback (that I proposed to remove).
>>> The mapping should indeed be consistent for a user on the DC,
>>> so it should not intermittently switch between idmap.ldb and
>>> the rfc attributes. That would be a bug that we need to
>>> One step as written in a previous mail would be to change
>>> the dc code to _never_ fall back to idmap.ldb when configured
>>> with "idmap_ldb:use rfc2307 = yes".
>> It has to fall back as uid is undefined for builtin objects.
> As someone else has already said: builtin are different.
> These are machine-local anyways.
> We were talking about the main user DB, subordinate
> to the domain SID. And for _that_, it should not fall back.
> Fallback is a bug here as elaborated ealier...
> Cheers - Michael
The problem was the old 'winbind' on the DC, it did not map (for want of
a better word) the builtin users & groups to names, you just got
numbers. With Samba now using the separate 'winbindd' it doesn't matter
that BUILTIN\Administrators (for instance) has a different GID on
different machines, it still shows as BUILTIN\Administrators.
As far as I can see, the only problem remaining is the use of the
unixHomeDirectory & loginShell attributes, you can set these with
template lines in smb.conf on the DC, but it would be nice if they could
be obtained from AD :-)
More information about the samba