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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
> 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