[SSSD] [PATCHES] Support for multiple LDAP search bases

Stephen Gallagher sgallagh at redhat.com
Mon Oct 3 19:04:48 UTC 2011


On Mon, 2011-10-03 at 14:51 -0400, Stephen Gallagher wrote:
> These patches add support for multiple search bases for users and groups
> in both direct-lookup and enumeration modes.
> 
> Addresses https://fedorahosted.org/sssd/ticket/868
> 
> Some notes: There is no patch adding multiple search base support for
> group lookups in RFC2307bis because it's meaningless right now. Since
> the group memberships are direct DNs, we do all of our searches as base
> searches, ignoring group_search_base. There is a separate ticket,
> https://fedorahosted.org/sssd/ticket/960 that will need to address this,
> taking advantage of the multiple search base features.
> 
> Also, while working through this, I opened
> https://fedorahosted.org/sssd/ticket/1006 as I noticed that we are using
> far too many separate transactions while processing RFC2307bis (which is
> likely the cause of the extreme slowdown that some of our users were
> reporting with AD).
> 
> These patches don't really work separately, but they've been broken up
> to make review much easier.
> 
> 
> Patch 0001: Remove some unused options in a struct
> 
> Patch 0002: Fix size return for split_on_separator()
> It was returning the size of the array, rather than the number of
> elements. (The array was NULL-terminated). This argument was only
> used in one place that was actually working around this odd return
> value.
> 
> Patch 0003: Make sdap_get_id_specific_filter() more strict
> Just makes it take const char * instead of char *.
> 
> Patch 0004: Add parser for multiple search bases
> As discussed on the list, this will the ldap_*_search_base options in
> the form of:
> search_base[?scope?[filter][?search_base?scope?[filter]]*]
> This is backwards-compatible (just use a search base)
> 
> Patch 0005: Add support for multiple search bases for users
> 
> Patch 0006: Add support for multiple search bases for netgroups
> 
> Patch 0007: Add support for multiple search bases for RFC2307 groups
> 
> Patch 0008: Add support for multiple search bases for initgroups (user
> portion)
> 
> Patch 0009: Add support for multiple search bases for initgroups
> (RFC2307 group portion)
> 
> Patch 0010: Add support for multiple search bases for initgroups
> (RFC2307 group portion)
> This patch I'm not 100% sure of. It may need more processing. With
> RFC2307, it was safe to have duplicate groups in the list, because only
> the group name is important (and we guarantee that the name list has
> only unique values before saving it). With RFC2307bis, I'm not sure if
> it's safe to add two groups that may have the same name. Comments
> welcome.
> 
> Patch 0011: Update manpages with multiple search base information
> 
> Patch 0012: Convert ldap_*_search_filter
> Instead of making this a global option for all user lookups, make it
> only used if the search base is passed without an explicit filter. The
> idea here is to deprecate the old separate ldap_user_search_filter and
> ldap_group_search_filter options in favor of the new representation
> (which is closer to the traditional nss_ldap representation).
> 
> Patch 0013: Add support for multiple search bases for user enumeration
> 
> Patch 0014: Add support for multiple search bases for group enumeration
> This changes our behavior slightly with regard to handling direct
> lookups that return more than one entry. In the old code, we had a bug
> that would cause SSSD to treat this as an enumeration (instead of a
> direct lookup). This was a bug and has been fixed incidentally as part
> of this modification.

For the record, because I forgot to mention it in my first email: I
tried to reproduce the issue jzeleny saw in the earlier thread without
success. Either I inadvertently fixed it with the changes I made or it
was caused by other changes in his environment (possibly the memberOf
work).

I tested it with exactly the same users and groups, using SSSD speaking
to a FreeIPA server (in both rfc2307bis mode and ipa backend).



His original comment:

So NACK after all. Following test failed:

I tried following membership structure. I have 3 groups: topgroup,
middlegroup 
and bottomgroup and 2 users:  user1 and user2

The relationship is following:
topgroup -> middlegroup, user1
middlegroup -> user2, bottomgroup
bottomgroup -> user1


getent group topgroup gives me result with no members, the same test on
master 
returns the expected result.
-------------- 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/20111003/644b2a70/attachment.sig>


More information about the sssd-devel mailing list