Thank you William for diving into that RFE with as always very good points. I will try to answer.
You are right it is a requirement coming from IPA where future IPA instance will have to support MS client issuing In chain requests. I am not convince it will be very frequent req. It is even possible that this RFE is a kind of supported MR we need for conformity reasons.
The request triggers a set of recursive read operations. So it differs from memberof plugin that, does the reads and also update the target entry with memberof values. So it will be by far (I hope) faster than memberof plugin. The drawback is that the result of the computation is lost (not written) so there is no way to benefit from previous req.
The problem with memberof is that it updates the target entry. So it is beneficial only if you later search 'memberof'. If you do not it is a waste of time. Also memberof is very demanding, you need to keep the plugin always enabled to trust the result. We have seen many cases where memberof was disabled during some admin tasks then reenabled/fixup. So it is not comparing a bad 'in chain' solution vs a perfect 'memberof' solution, both have benefits/drawbacks.
Finally I have to admit, may be I auto convinced myself ;), that this matching rule provides a quite elegant membership processing without requiring plugins/config. For example with a same MR you can lookup both sides of the memberships (toward the members or toward the groups). (memberof:inChainMatch:=cn=bar) will give all the members of group 'cn=bar' while (member:inChainMatch:=uid=foo) will give all the groups foo is memberof.
best regards theirry
On 2/10/22 11:47 PM, William Brown wrote:
On 11 Feb 2022, at 00:51, Thierry Bordaz tbordaz@redhat.com wrote:
Hello,
I started looking at this RFE (new matching rule) and pushed the design https://www.port389.org/docs/389ds/design/matching-rule-in-chain.html
It is in a preliminary state but I hope covers major part of the RFE. Feedbacks are welcome :)
This RFE relies on another RFE (https://github.com/389ds/389-ds-base/issues/5156) that I will start to look at.
Is there a really compelling reason to implement this?
memberOf can already do nested groups, and populate those on leaf entries. So why do we need the IN_CHAIN behaviour?
My senses are telling me this is some IPA/AD related shenanigans, because in chain is how AD does memberOf expansion of nested groups. See:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1e889ad... https://docs.microsoft.com/en-au/windows/win32/adsi/search-filter-syntax?red...
However it's widely known that this operation is EXTREMELY SLOW on AD:
https://stackoverflow.com/questions/40024425/1-2-840-113556-1-4-1941-ldap-ma...
This article links to multiple other sites documenting the performance issues of this matching rule.
So I have significant concerns about:
- What is the problem this feature is required to solve? Is there a better way that we could consider by having a definition of the problem, rather than "the solution"?
- The performance impact of this RFE given operational experience of MS AD
- Why this RFE needs to exist at all given our memberOf capabilities that already fulfils nested group capabilities
Thanks,
-- Sincerely,
William Brown
Sesion Software Engineer, Identity and Access Management SUSE Labs, Australia _______________________________________________ 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