The general workflow for sid->unix id is:
1. resolve the SID into a 'DOMAIN\user'
2. lookup "idmap config DOMAIN:backend" to find the id-mapping backend instance
3. hand over the sid to the backend instance.

Now consider what happens to DOM-A\user which have been moved to to DOM-B:
- it receives a new SID in DOM-B
- the original SID (let's call it S-1-5-21-x-y-z-rid1) moves to sIDHistory
- now, in DOM-B, S-1-5-21-x-y-z-rid1 resolves to DOM-B\user, thus we give the DOM-B id-mapping backend to map a SID whose prefix is not DOM-B prefix.

This in turn can yield wrong results in many configurations. One case is when idmap-rid is being used - it will give a uid which actually belongs to a different SID.

To give a concrete example that fails, suppose the following:

The original SID of DOMAIN1\d1u1 (in DOMAIN1) was S-1-5-21-3293503978-489118715-2763867031-1106
In DOMAIN2, we have a user called d2u2 whose SID is S-1-5-21-1387724271-3540671778-1971508351-1106
DOMAIN1\d1u1 was moved to DOMAIN2. Now it's DOMAIN2\d1u1, and it's sid is S-1-5-21-1387724271-3540671778-1971508351-1115
However, DOMAIN2\d1u1 also has S-1-5-21-3293503978-489118715-2763867031-1106 in its sIDHistory.

Now do the following:
smbclient //<gw-ip>/public -U 'DOMAIN2\d2u2%password' -c 'ls'
smbclient //<gw-ip>/public -U 'DOMAIN2\d1u1%password' -c 'ls'
smbclient //<gw-ip>/public -U 'DOMAIN2\d2u2%password' -c 'ls'

The first two  succeed, the third (which is a repetition of the first) fails. Why? Because:
1. The d1u1 logon created a sid->uid cache entry but also a uid->sid cache entry
2. During the second d2u2 logon, a getpwuid() failed because getpwuid() is really uid->sid followed by querying the user by its SID, and the SID is wrong.

Patch to follow...