On Fri, 10 Sep 2010 12:06:25 +0200
Ralf Haferkamp <rhafer(a)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.
> 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
> 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
> 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 Sorce * Red Hat, Inc * New York