[SSSD] DESIGN: Multiple LDAP search bases

Simo Sorce simo at redhat.com
Mon Sep 12 15:00:18 UTC 2011


On Mon, 2011-09-12 at 10:39 -0400, Stephen Gallagher wrote:
> 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.

I do not like this approach, especially if done for a single option
among many other similar one, it makes the configuration file very odd.

Besides this is for feature parity with nss_ldap and there admins are
already use to something like ldap_<map>_search_base = a?b?c
I think we should maintain the convetion (I do not like it too much, but
it is a convention).

> > 
> > 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.

I do not think there is much to validate here.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list