Dynamic LDAP groups, groups that are populated with objects found by doing an LDAP search rather than static members. They’re especially useful when you’ve got an application that authorizes access using LDAP groups and the size of those groups starts to get unmanagable (or is unmanageable from the get-go). All LDAP directories support dynamic groups in one shape or form. Implementation differs slightly among products. OpenLDAP and Oracle OID use basically the same model, while Sun Directory uses another.
Dynamic groups are turned on by default in Sun and Oracle. In Sun a query on the group won’t show the group members, while in Oracle it will. The nice thing about the latter type of listing is that apps that are not “dynamic group aware” can use the information without any further effort.
OpenLDAP implements dynamic groups through its overlay feature. The OpenLDAP dynamic groups overlay has been superceded by the dynamic lists overlay. These both basically work the same way, although different objectclasses and attributes can be used to implement them depending upon the final configuration.
The shipping OpenLDAP with Red Hat Enterprise Linux 5 (RHEL5) does not come with overlays turned on by default. To enable them you need to:
1. Install the
2. Uncomment the overlays you want to enable in
slapd.conf (in this case
3. Indicate the location where the overlay libraries can be found (e.g.
modulepath /usr/lib64/openldap for 64-bit systems, “/usr/lib/openldap” for 32-bit).
4. Restart the directory server to effect these changes.
To implement the dynamic lists overlay in particular, you also need to tell the server which objects to treat as dynamic lists by adding the requisite directives to
In my case I wanted to carry over the use of groupOfURLs objects and memberURL attributes we had in our Sun Directory. To do that I had to first modify the
dynlist.schema to replace “top” with “groupofUniqueNames” in the groupOfURLs object class definition. Then I added the following directives to
dynlist-attrset groupOfURLs memberURL uniqueMember
What these directives do is instruct the server to display the results from a search filter in a memberURL attribute in any groupOfURLs object as a uniqueMember value in the group object.
The dynamic group objects I then added to the directory looked something like this:
One word of caution, you can build really big groups using dynamic lists. One that I ported over from a Sun server displayed over 10,000 members. Because of the way the LDAP protocol works the process of listing all those members takes a good amount of time, maybe longer than some applications can manage. Testing the behavior of your apps with dynamic groups enabled is highly recommended. In many cases you may have to adjust timeouts to accomodate the delays that reading some humongous dynamic groups will entail. In others you might want to rethink the composition of some groups — with an eye towards breaking them down into smaller, more reasonably sized objects.