SID History id-mapping

Stefan Metzmacher metze at samba.org
Tue Feb 21 11:08:48 UTC 2017


Am 21.02.2017 um 10:58 schrieb Michael Adam:
> On 2017-02-20 at 15:24 +0100, Stefan Metzmacher wrote:
>> Hi Uri,
>>
>>> We've discovered a bug in idmap_rid, that causes it to "pollute" the
>>> id-mapping cache, due to to SID history. This is probably not only in
>>> idmap_rid. I'd like to consult with the list about the way to solve this.
>>>
>>> The problem
>>> ================
>>> We have DOMA\user with SID-A-RID1. This user is moved to DOMB. It gets a
>>> new objectSID, and becomes DOMB\user, with SID-B-RID2. SID-A-RID1 is
>>> placed in the SID history. However, if you ask a domain controller of
>>> DOMB "Who is SID-A-RID1", he'll say "why, this is DOMB\user!".
>>>
>>> The "pollution" goes like this:
>>> 1. DOMB\user, now with SID-B-RID2, but with SID-A-RID1 in its sIDHistory
>>> logs on.
>>> 2. As part of constructing its UNIX identity, the id-mapper of DOMB is
>>> requested to map SID-A-RID1 (because it's DOMB\user)
>>> 3. In the case of idmap_rid, it maps a SID that it shouldn't be mapping,
>>> and creating an UID1->SID-A-RID1 entry in the cache.
>>>
>>> This can have all sorts of interesting effects, such as failing logon of
>>> a user with SID-B-RID1 (because there's getpwuid() somewhere in the
>>> process).
>>>
>>> Towards fixing - Definition of idmap domain
>>> ==============================================
>>> What do we mean by "idmap config DOMB : backend = y" ?
>>>
>>> It can be either:
>>> 1. SIDs with a prefix equal to DOMB's SID are handled by this backend.
>>>
>>> 2. SIDs resolved to DOMB\xxx are handled by this backend.
>>>
>>> Up until now I (and some of the code) assumed those definitions are
>>> equivalent, but with SID History, they aren't.
>>>
>>> If we go by way of definition #1, it will be the job of the central
>>> winbindd to had the mapping to the correct mapping instance (the one
>>> mapping DOMA). Given Volker's guidelines for avoiding races and not
>>> relying on trust domain cache, it can be something like:
>>>
>>> 1. try smb.conf - something like "idmap config DOMA : sid = <sid>" -
>>> that would be an optional parameter for handling long-gone domains which
>>> are still in the SID history.
>>>
>>> 2. try netsamlogon cache - find an entry with dom_sid equal to the
>>> prefix of the SID we're trying to map. That's the main method that works
>>> in the usual case.
>>>
>>> 3. try mapping <prefix>-512 or some other well-known RID, which is not
>>> likely (?) to be migrated.
>>>
>>> If we go by definition #2, we keep doing what we did up to now, but the
>>> idmap backend will need to ensure it works correctly with SID history
>>> SIDs. idmap_rid for example will simply fail to map SID-A-RID1 - it will
>>> determine its domain SID by way of the netsamlogon cache and refuse to
>>> map sids with a different prefix.
>>>
>>> From the narrow standpoint of idmap_rid, I think definition #1 is
>>> preferred, because it allows us to fully support SID history, but I'm
>>> looking for input on other id-mapping backends and in general - what do
>>> others think about it.
> 
> Great analysis, Uri!
> I was always a little uncertain what we expect to get
> back when asking for the name of a history SID.
> I think they only return the NEW name of the mapped object
> once the old domain has been removed - right? ...
> 
>> I think you should handle the idmap backends internaly only by SID
>> instead of
>> the name.
> 
> Indeed. This was desired since a long time. It would be
> really great to rewrite id-mapping code in theis way.
> 
>> The name in the conf file needs to be resolved when winbindd
>> starts
>> by using some caches (secrets.tdb for our own sam and our primary domain
>> or other tdbs with the available information or asking a dc of our
>> domain as last resort).
>>
>> idmap config DOMA : sid = <sid> could be used to avoid the online lookup,
>> while my original idea was to use "idmap config <sid> : backend" and
>> avoid the name
>> completely.
> 
> Right. Both would work. Uri's approach has a few advantages, I
> think:
> 
> - it is an optional add-on to existing configs
> - hence it's backward compatible
> - we don't force the users/admins to configure with the
>   super-eloquent SIDs. I think they would complain... ;-)
> 
> Of course metze's approach would force us to be more consistent.

My approch would be:

idmap config <sid_or_name> : backend

In case you have some sids in a sid history the admin would not
need to make up a fakename if the domain doesn't exist anymore.
Maybe having the above and also "idmap config DOMA : sid = <sid>"
as valid configurations would be good to have, in order to be
most flexible. But it might also increase the confusion if we have
two ways for the same thing.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170221/21171fcb/signature.sig>


More information about the samba-technical mailing list