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.