SID History id-mapping

Michael Adam obnox at samba.org
Tue Feb 21 09:58:47 UTC 2017


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.

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170221/0d96a1cb/signature.sig>


More information about the samba-technical mailing list