[SSSD] DESIGN: Multiple LDAP search bases

Stephen Gallagher sgallagh at redhat.com
Mon Sep 12 14:39:15 UTC 2011


On Mon, 2011-09-12 at 10:07 -0400, Dmitri Pal wrote:
> On 09/12/2011 08:41 AM, Stephen Gallagher wrote: 
...
> > === Enumeration ===
> > For enumeration, we will need to iterate through ALL search bases to
> > retrieve users, groups, etc. For each search base, we need to examine
> > each entry retrieved and compare it against the entries received from
> > earlier search bases. If there are conflicts, we will discard the
> > conflicting value from the later search base. (Therefore the entry in
> > the earlier search bases will always win.
> 
> I am not sure we should pre-match anything and sort duplicates.
> We should put fetched data into the cache right away as a result of
> one search and then do the second search following the same logic and
> so on.
> If we encounter a duplicate i.e. a full duplicate of a user we just
> updated (same user) we should just skip it. If we find a collision
> meaning we found a user with same id but different name or vice verse
> (same with group) we should report and skip. This is a
> misconfiguration and admin should sort his domain out. 
> 

Unless I'm missing something, that's the same behavior I'm describing,
except less efficient. We always hold off on saving data to the cache
until the very end (to avoid both inconsistent cache state and excess
writes to the disk).

The only difference between your approach and mine is that you would do
an extra check to make sure they were the same and would just not report
it if so. In my version, I'd always report duplicate names, even if they
ultimately turn out to have the same data.

You do make a good point that I forgot to put in my initial analysis
that we probably need to ensure that there are no GID conflicts either.
That means a second lookup table.

> > == Implementation ==
> > We will extend the ldap_*_search_base options to support behavior
> > similar to that of nss_base_passwd and nss_base_group from nss-ldapd.
> 
> Is it a literal * or it is a placeholder?
> In either case I do not like an approach. IMO the key names should be
> predefined.
> 
> May be use:
> 
> ldap_search_base_multi = triplet, triplet, triplet
> 

We cannot do this, because search bases have commas in them. It wouldn't
be possible to parse them safely. However, your idea below might work.

> > The standard search base (ldap_search_base will be left alone as a
> > single value with scope "subtree".
> > 
> > The new ldap_*_search_base options will include a new delimiter, '?'. If
> > this is present, we will divide the string up into triples as follows:
> > 
> > search_base?scope?filter[?search_base?scope?filter...]
> > 
> 
> Alternatively you can add sub sections to the ldap provider (we alread
> yuse this approach with domains and providers, I do not see why we
> should deviate in this case too)
> 
> ldap_search_base_multi = section1, section2, section3
> 
> [.../default/ldap_search/section1]
> ldap_search_base = x
> ldap_search_filter = y
> ldap_search_scope = z
> 
> [.../default/ldap_search/section2]
> ldap_search_base = x
> ldap_search_filter = y
> ldap_search_scope = z
> 

I assume you mean [domain/DOMAINNAME/ldap_search/sectionN]

If so, this might be a decent approach. It might be a little tricky to
add this to the SSSDConfig API, but the resulting interface will
probably be cleaner, so I'll think about this carefully.

> 
> It will be easier to parse, more structured and readable and with such
> organization you can extend the current search filter leaving it (if
> specified) to be the first search filter to use.
> In addition if the grammar validation is ever implemented we would be
> able to apply the rules to such config. If we go with the original
> proposal the ini validation would not be usable.

This is probably a good plan. Thanks for the suggestion!

-------------- 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/20110912/892bf744/attachment.sig>


More information about the sssd-devel mailing list