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(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
_______________________________________________
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