SID History id-mapping

[Uri Simchoni]

Hi!

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.


Thoughts?

Thanks,
Uri.