Bug 12702 - wrong sid->uid mapping for SIDs residing in sIDHistory
wrong sid->uid mapping for SIDs residing in sIDHistory
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Winbind
4.6.0
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
: 10753 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-03-19 20:41 UTC by Uri Simchoni
Modified: 2017-05-15 16:14 UTC (History)
4 users (show)

See Also:


Attachments
git-am fix for 4.6.next (9.26 KB, patch)
2017-04-23 18:47 UTC, Uri Simchoni
slow: review+
uri: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Uri Simchoni 2017-03-19 20:41:27 UTC
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...
Comment 1 Uri Simchoni 2017-04-23 18:47:49 UTC
Created attachment 13170 [details]
git-am fix for 4.6.next

(Voting not to apply to 4.5.next because it's not a "major issue" if it's gone unnoticed all these years, and I only tested it in 4.6.latest. It applies cleanly to 4.5.latest too though).
Comment 2 Ralph Böhme 2017-04-23 20:17:32 UTC
Reassigning to Karolin for inclusion in 4.6.
Comment 3 Karolin Seeger 2017-04-28 07:04:17 UTC
(In reply to Ralph Böhme from comment #2)
Pushed to autobuild-v4-6-test.
Comment 4 Karolin Seeger 2017-05-02 07:31:32 UTC
(In reply to Karolin Seeger from comment #3)
Pushed to v4-6-test.
Closing out bug report.

Thanks!
Comment 5 Uri Simchoni 2017-05-15 16:14:03 UTC
*** Bug 10753 has been marked as a duplicate of this bug. ***