SID History id-mapping

[Stefan Metzmacher]

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.

I think you should handle the idmap backends internaly only by SID
instead of
the name. 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.

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/20170220/0c9bea5c/signature.sig>