title: Enabling dynamic groups in OpenLDAP link: https://onemoretech.wordpress.com/2011/01/06/enabling-dynamic-groups-in-openldap/ author: lembobro description: post_id: 86 created: 2011/01/06 11:02:43 created_gmt: 2011/01/06 11:02:43 comment_status: open post_name: enabling-dynamic-groups-in-openldap status: publish post_type: post

Enabling dynamic groups in OpenLDAP

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 openldap-servers-overlays package;

2. Uncomment the overlays you want to enable in slapd.conf (in this case moduleload dynlist.la);

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 slapd.conf.

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 slapd.conf:

overlay dynlist 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:

dn: cn=Contractors,ou=Groups,dc=example,dc=com objectclass: top objectclass: groupofUniqueNames objectclass: groupofURLs cn: Contractors memberURL: ldap:///ou=people,dc=example,dc=com??sub?(title=*Contractor*)

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.

Copyright 2004-2019 Phil Lembo