On 11 Feb 2022, at 00:51, Thierry Bordaz <tbordaz(a)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/1e88...
https://docs.microsoft.com/en-au/windows/win32/adsi/search-filter-syntax?...
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...
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