On Fri, 10 Sep 2010 12:06:25 +0200 Ralf Haferkamp <rha...@suse.de> wrote:
> On Thursday 09 September 2010 18:33:26 Simo Sorce wrote: > > So we have the following scenarios: > > > > 1) If we use rfc2307 classic with memberUid attributes, we can just > > create the fake/expired users and be done with it. > Agreed. > > > 2) If we use rfc2307bis w/o nested groups we can count the number of > > members on the group entry and switch to a full user enumeration if > > the number of members is greater than a defined (potentially user > > defined) threshold. Assuming a threshold value of 100, if we have 10 > > members we just do 10 lookups, while, if we have > 100 member we do > > a full enumeration (it's a single ldap search, and if > > modifyTimestamp is used also highly optimized after the first > > search) so we are sure all users are there with the right name. > I think that's an optimization that could be worth exploring later. > In a first iteration I'd just go for implementing the complete group > lookup by looking up every single user regardless of how large the > group is. (plus the possiblity to completely disable member unrolling > through the configuration) Ok, although performances will suck so much I bet we will have to implement the optimization pretty soon. > > 3) If we use rfc2307bis with nested groups we do the same as in 2, > > but we add an internal user lookup against the cache we just > > populated to determine if some members are groups that need further > > lookups in order to complete the group unrolling operation. > Why do an extra cache lookup? You could issue the addtional LDAP > lookups right when you receive the entries of the group members. > Provided the correct LDAP attributes where requested (i.e. user > attributes + groups attributes). True, it is necessary only when you use the optimization of doing one search for all users. When you lookup each entry individually you just need to keep a list of groups to further search, and simply repeat the operation for each of those groups (need to set a limit to recursion). > > 4) If we use IPA (rfc2307bis + nested groups + unrolled members in > > memberOf attribute), we can do a single search with > > memberOf=groupDN, as IPa's memberOf fully resolves nested groups. > > This would return all and only the users members of the group. > > So if the group has 101 members in a directory of 50k users we do > > not do a full 50k users enumeration just because we have a group > > that is 1 above the threshold. > > > > Do I miss any scenario ? > > > > Simo. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
