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