On 2/16/22 12:33 AM, William Brown wrote:
Hi,
Twenty years that I work in LDAP area and twenty years that I see debate on the best way to look for group membership ! -;) And simply because there is no universal answer: ismemberof is typically better than the standard lookup if a user belongs to few large groups and that is the opposite if user belongs to lots of small groups.
I disagree, there is only one answer, and it's to pre-compute those values into memberOf. There is no way that dynamic calculation could ever be faster than pre-building this information.
If I understand your point I have to say it has some limits. Managing link attribute has a cost, in term of updates, index computation, admin task to properly configure the components (plugin) that will manage the attribute. For example, if we implement InChain MR and want to support SRCH like '(manager:1.2.840.113556.1.4.1941:=uid=foo)' using a pre-compute value 'managedBy', that mean configuring a membor_manager like plugin, RI_manager plugin,... have a significant overload on updates and db size, for an attribute that we may never use (if no application will lauch a InChain 'manager').
What I find elegant on this MR is that whatever the server configuration is, you get the result. Even if, I agree with your proposal, internally the server translates a '(member:1.2.840.113556.1.4.1941:=cn=bar)' into '(memberof=cn=bar)' and get benefit of memberof/RI plugins.
regards thierry
So IMHO debating whether ismemberof is better than the chaining matching rules has not much interest. As I perceive things the chaining matching rule has the advantage of being faster than the standard lookup because there is less overhead So IMHO having both ismemberof ans chain matching rule makes sense (even if only one of these mechanism should be deployed)
Well, it is because applications don't adapt based on what's best for the LDAP server - applications just want "group info" and *we* need to make decisions and design choices that impact the performance of these different cases.
As above - applications in AD land have become accustomed to asking for the chain style rule to get nested groups. We can not assume an application will "do what's best for us". We have to assume worst cases, and what impact that will have.
(Sorry I fumbled my previous answer and unwillingly sent the answer that was in progress)
A few other points.
- We should be careful to check that we have the right to access the groups (otherwise there will be security issues)
Yes, this is true. If we used my suggestion of chaining consuming memberOf, then we could inherit that information naturally.
- We should only support the matching rule if it is indexed. ( so no need to have a specific control to accept it or not)
Yes, if we are evaluating it in the manner as documented by the AD implementation then we should only allow indexed searches.
Regards Pierre
--
389 Directory Server Development Team
--
389 Directory Server Development Team _______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- Sincerely,
William Brown
Sesion Software Engineer, Identity and Access Management SUSE Labs, Australia