https://bugs.openldap.org/show_bug.cgi?id=9402
Issue ID: 9402 Summary: Add support for LDAP_MATCHING_RULE_IN_CHAIN (1.2.840.113556.1.4.1941) Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: vdanjean.ml@free.fr Target Milestone: ---
Hi,
The memberof overlay add support for memberOf attributes. But, when using nested groups, user group membership must be handled on each ldap client. The current implementation allows one to only retrieve direct group ownership. Nested group membership must be done by client recursive lookup.
Microsoft Active Directory provides a way to do the recursive lookup at server side: https://ldapwiki.com/wiki/LDAP_MATCHING_RULE_IN_CHAIN It would be really useful if openldap (slapd) was also able to do the same.
Regards, Vincent
PS: I set the component to overlays in this bugs report, but I'm not sure it should be implemented into the overlays memberof itself.
https://bugs.openldap.org/show_bug.cgi?id=9402
--- Comment #1 from Howard Chu hyc@openldap.org --- (In reply to Vincent Danjean from comment #0)
Hi,
The memberof overlay add support for memberOf attributes. But, when using nested groups, user group membership must be handled on each ldap client. The current implementation allows one to only retrieve direct group ownership. Nested group membership must be done by client recursive lookup.
Microsoft Active Directory provides a way to do the recursive lookup at server side: https://ldapwiki.com/wiki/LDAP_MATCHING_RULE_IN_CHAIN It would be really useful if openldap (slapd) was also able to do the same.
Regards, Vincent
PS: I set the component to overlays in this bugs report, but I'm not sure it should be implemented into the overlays memberof itself.
Based on the description you linked, it looks like this provides the same functionality as the dnSubtreeMatch extended matching rule in OpenLDAP. I don't see much reason to add this M$-specific extension.
https://bugs.openldap.org/show_bug.cgi?id=9402
--- Comment #2 from Vincent Danjean vdanjean.ml@free.fr --- Hi,
It is very difficult to find documentation about dnSubtreeMatch. Based on what I read and try, it seems to allows one to match an entire subtree (i.e. all entries below a specific dn).
I do not see how it relates to LDAP_MATCHING_RULE_IN_CHAIN but I would be very pleased to be wrong.
My ldap database has nested groups. Here is a very small example: ldapsearch [options] '(|(uid=mylogin)(cn=g-mygroup)(cn=mymachine))' cn uid member memberof [...] # mylogin, people, Home, example.org dn: uid=mylogin,ou=people,ou=Home,dc=example,dc=org cn: My Login uid: mylogin memberOf: cn=mylogin,ou=groups,ou=Home,dc=example,dc=org memberOf: cn=g-mygroup,ou=groups,ou=UsersGroups,ou=ControlAccess,dc=example,dc=org [...]
# g-mygroup, groups, UsersGroups, ControlAccess, example.org dn: cn=g-mygroup,ou=groups,ou=UsersGroups,ou=ControlAccess,dc=example,dc=org cn: g-mygroup member: uid=mylogin,ou=people,ou=Home,dc=example,dc=org memberOf: cn=mymachine,ou=groups,ou=Machines,ou=ControlAccess,dc=example,dc=org [...]
# mymachine, groups, Machines, ControlAccess, example.org dn: cn=mymachine,ou=groups,ou=Machines,ou=ControlAccess,dc=example,dc=org cn: mymachine member: cn=g-mygroup,ou=groups,ou=UsersGroups,ou=ControlAccess,dc=example,dc=org [...]
So mylogin is in group g-mygroup that itself is in group mymachine.
Selecting users that (transitively) are in mymachine could be done with LDAP_MATCHING_RULE_IN_CHAIN with: ldapsearch [options] '(&(uid=mylogin)(memberOf:1.2.840.113556.1.4.1941:=cn=mymachine,ou=groups,ou=Machines,ou=ControlAccess,dc=example,dc=org))'
And it will work *whatever the number of nested group there is* (there is probably a limit on the server).
Is it possible to do the same with dnSubtreeMatch?
I've read lots of question about managing nested groups with ldap. On internet, I only saw people telling about LDAP_MATCHING_RULE_IN_CHAIN when using MS software or people implementing the recursive research in software (ldap client side) when using openldap. If a solution based on dnSubtreeMatch exists, I would be very please (and also lots of other people).
Regards, Vincent
https://bugs.openldap.org/show_bug.cgi?id=9402
--- Comment #3 from Howard Chu hyc@openldap.org --- (In reply to Vincent Danjean from comment #2)
Hi,
It is very difficult to find documentation about dnSubtreeMatch. Based on what I read and try, it seems to allows one to match an entire subtree (i.e. all entries below a specific dn).
I do not see how it relates to LDAP_MATCHING_RULE_IN_CHAIN but I would be very pleased to be wrong.
The description you linked says this feature matches the values of a DN-valued attribute against all its superiors, all the way up to the root of the DIT.
That means it's used to ascend the DIT hierarchy. It says nothing about behavior with nested groups. If you have an official M$ document defining how it is used with nested groups, please provide a link.
I've read lots of question about managing nested groups with ldap. On internet, I only saw people telling about LDAP_MATCHING_RULE_IN_CHAIN when using MS software or people implementing the recursive research in software (ldap client side) when using openldap. If a solution based on dnSubtreeMatch exists, I would be very please (and also lots of other people).
Regards, Vincent
https://bugs.openldap.org/show_bug.cgi?id=9402
--- Comment #4 from Vincent Danjean vdanjean.ml@free.fr --- (In reply to Howard Chu from comment #3)
The description you linked says this feature matches the values of a DN-valued attribute against all its superiors, all the way up to the root of the DIT.
That means it's used to ascend the DIT hierarchy. It says nothing about behavior with nested groups. If you have an official M$ document defining how it is used with nested groups, please provide a link.
The document talks about "ancestry" and not "superiors". I find https://support.citrix.com/article/CTX237210 that itself refer to https://docs.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax (official MS doc) It is clear in the doc that the traversal is done through the group hierarchy (defined by the matched attribute) and not through the LDAP tree.
Regards, Vincent
https://bugs.openldap.org/show_bug.cgi?id=9402
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #5 from Howard Chu hyc@openldap.org --- (In reply to Vincent Danjean from comment #4)
(In reply to Howard Chu from comment #3)
The description you linked says this feature matches the values of a DN-valued attribute against all its superiors, all the way up to the root of the DIT.
That means it's used to ascend the DIT hierarchy. It says nothing about behavior with nested groups. If you have an official M$ document defining how it is used with nested groups, please provide a link.
The document talks about "ancestry" and not "superiors". I find https://support.citrix.com/article/CTX237210 that itself refer to https://docs.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax (official MS doc) It is clear in the doc that the traversal is done through the group hierarchy (defined by the matched attribute) and not through the LDAP tree.
OpenLDAP 2.5 already supports nested groups using the dynlist overlay. Closing this ITS.
https://bugs.openldap.org/show_bug.cgi?id=9402
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=9402
--- Comment #6 from Vincent Danjean vdanjean.ml@free.fr --- (In reply to Howard Chu from comment #5)
OpenLDAP 2.5 already supports nested groups using the dynlist overlay. Closing this ITS.
dynlist seems indeed a great feature. I would say that it seems to lack a bit of documentation/examples, but, from what I read, it allows one to do powerfull things. With respect to nested groups, it is possible that, for reader LDAP client (ie most applications using ldap for authentication), dynlist (and autogroup) would be a good solution (I'm not sure that it will work with dynlist object refering to other dynlist as the slapo-dynlist(5) manpage says "No recursion is allowed, to avoid potential infinite loops." I will need to do tests). However, using this feature requires writer LDAP clients (at least fusiondirectory in my case) to support this new feature (new attribute to handle, different way to create groups, etc.) So less software to patch, but still software to patch to support nested groups.
My point is just to say that dynlist/autogroup overlay and my initial request are not the same things. That said, if dynlist allows one to create recursive nested groups, I fully understand that you do not want to support an alternative (that would probably be less efficient).
But, for my use case, as fusiondirectory does not (yet) support dynlist (it should in the next version), I will write scripts that duplicate nested groups in another ldap branch by flatening them, so that reader LDAP client that do not support nested groups can be told to look into this alternative hierarchy.
Many thanks for your feedback and the pointers to dynlist/autogroup. I will look at them with attention.
-
openldap-its＠openldap.org