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.
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