Full_Name: Christopher Klinge Version: 2.4.44 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.193.142.51) As of right now, dynlist can be used to expand one level of nesting: overlay dynlist dynlist-attrset parentGroup childGroup dn: cn=Parent Group,ou=Groups,dc=example,dc=com objectClass: parentGroup cn: Parent Group childGroupURL: ldap:///cn=Child Group,ou=Groups,dc=example,dc=com?member?sub? dn: cn=Child Group,ou=Groups,dc=example,dc=com objectClass: childGroup cn: Child Group member: cn=User A,ou=People,dc=example,dc=com member: cn=User B,ou=People,dc=example,dc=com member: cn=User B,ou=People,dc=example,dc=com Querying the parent group will return: dn: cn=Parent Group,ou=Groups,dc=example,dc=com objectClass: parentGroup cn: Parent Group childGroupURL: ldap:///cn=Child Group,ou=Groups,dc=example,dc=com?member?sub? member: cn=User A,ou=People,dc=example,dc=com member: cn=User B,ou=People,dc=example,dc=com member: cn=User C,ou=People,dc=example,dc=com If cn=Child Group were to be a parent group itself, no further expansion would take place. I propose enabling dynlist recursion and adding a new configuration directive: dynlist-rec-attrset <group-oc> [<URI>] <URL-ad> <rec-ad> [[<mapped-ad>:]<member-ad>] Except for rec-ad, all parameters behave exactly like those of dynlist-attrset. The attribute rec-ad is mandatory. It is a comma separated list of attributes for which dynlist recursion is enabled. By adding a new directive, backwards compatibility is guaranteed. I suggest using a depth counter to prevent infinite loops. A configurable threshold with a fairly small default value is both light weight and sufficiently rigorous. Logging a suitable warning message upon reaching the threshold would inform the administrator about possible loops.
moved from Incoming to Software Enhancements
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>I have encountered some scepticism regarding the benefits of nesting within OpenLDAP itself. Some have argued, that applications should resolve nested groups or that nested groups should be created using automation instead. Here, I'd like to respond to these two objections.</div> <div> </div> <div>1. applications should be responsible resolve nested groups</div> <div>First, I disagree from a philosophical point of view. The identity management system and thus the user directory is the central point of knowledge regarding group membership. For the sake of maintainability, all of the information as to why any given user is member of any of its groups, should be present at this central location. Whether a user is a direct member of a group or whether he is member of a sub-group, may interest applications, but what matters most, is that the user is in fact part of both the sub-group and all of its ancestors.</div> <div> </div> <div>Secondly, some applications simply don't have nested group support. It is a fairly common feature, but it just isn't part of every piece of software out there. Implementing nesting in the directory removes the need for support on the application side entirely. In the (from my curent point of view unlikely) event that some application demands to resolve nesting itself, aliasing can be used to deactivate dynlist for the given application.</div> <div> </div> <div>2. automation instead of nesting</div> <div>Automation comes with two caveats which I would like to address individually:</div> <div> </div> <div> <div>2.a additional software</div> <div>This may come as a no brainer for most, but I'd like to point out that automation requires some form of additional software, be it diy scripts or an application. This increases complexity both due to operation of this software and its interaction with the user directory.</div> <div> </div> </div> <div>2.b divergent center of information</div> <div>Instead of maintaining nesting information within the user directory, the software used most likely stores its data outside of the directory. Worst case, it is hardcoded into some scripts. Thus, the information as to which groups are related is likely stored outside of the actual directory itself. This point may be void if the automation system stores nesting information on the group objects inside of the user directory.<br/> </div> <div>Sincerely,</div> <div>Christopher Klinge</div></div></body></html>
Nested group support implemented as a part of issue#9121 *** This issue has been marked as a duplicate of issue 9121 ***