[SSSD] [PATCHES][PRELIMINARY] Add support for Active Directory objectSID mappings

Stephen Gallagher sgallagh at redhat.com
Fri Apr 20 18:41:51 UTC 2012


On Fri, 2012-04-13 at 12:18 +0200, Jakub Hrozek wrote:
> On Thu, Apr 12, 2012 at 09:53:18PM -0400, Stephen Gallagher wrote:
> > Patch 0006: The meat of the work. This patch will almost certainly be
> > broken up into multiple patches before formal review, but right now it's
> > late and I'm tired.
> > 
> > This patch initializes the idmap context, reading the LDB for existing
> > mappings so that we guarantee that they end up in the same slice. It
> > also implements the logic for adding a new domain to the context, using
> > an algorithmic approach to pick the slice to use. This algorithm is
> > based on murmurhash3 + modulus to limit the result to the available
> > number of slices. If the hashing ends up colliding with an existing
> > entry, it will take the next available slice.
> > 
> > This is somewhat improved over the basic autorid algorithm in the common
> > case, because autorid simply always assigns the next slice in order to
> > each domain that is added. With this algorithm, a significant portion of
> > the time (when two domains don't hash to the same slice), we have a
> > simple and repeatable algorithm. The worst-case situation would be for
> > every domain in the network to hash to the same value, in which case it
> > becomes identical to autorid.
> > 
> > This patch does not USE the automatic creation yet. I used
> > sdap_save_user() as a test example and pre-loaded my cache file with a
> > domain mapping to prove that it is working. If my above algorithm is
> > approved, I will move on to implementing that (and group support)
> > immediately.
> > 
> > The catch with using this new algorithm is that we will most likely end
> > up needing to propose it as a winbind idmap plugin as well, so as to
> > minimize differences on systems in the network using winbind instead of
> > SSSD. I don't think this is a sufficient negative to give up on this
> > algorithm, however.
> > 
> > I'd like to hear some feedback on the algorithm and approach, please.
> 
> The approach sounds good to me.
> 
> For the winbind case, would it be possible to add an option to fall back
> to autorid algorithm which would be set in mixed environments?


Well, this approach is autorid-*compatible* already. The autorid
algorithm just always starts at slice zero with the first domain that it
sees and just goes up from there.

It's possible to make my algorithm behave the same way, but it still
doesn't mean that winbind and SSSD will come up with the same results
(because it's entirely dependent on the order in which the first entry
in each slice is seen).

In the winbind case, I think they configure one domain that is ALWAYS
slice 0, and then after that it's order of seeing. So I suppose I could
implement something like that, so we always reserve slice 0. That way
the default domain will at least be consistent.

I'll add an option ldap_id_mapping_default_domain, which will default to
the SSSD domain name if it's not explicitly set, and we'll always
reserve this domain as slot 0. Sound good?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120420/aaeb5bfa/attachment.sig>


More information about the sssd-devel mailing list