Chapter 6 OpenLDAP dynlist overlay
The Dynlist overlay allows a specific attribute of a specific objectClass (both identified in the overlay parameters) to be expanded into a search when results are returned. Thus, when an entry (DN) is addressed explicitly, or encountered during a search, which contains the identified objectClass it will return the results of the URL search defined in its identified attribute. The most common use of this feature is to create what are called Dynamic Groups. Unlike static groups defined using groupOfMembers a dynamic group is created typically using groupOfURLs objectClass with the search parameter being defined in the memberURL attribute which contains a standard LDAP search URL. Dynamic Groups are a non-standard (not defined in an RFC) LDAP feature which is widely implemented. Dynamic Groups may be used casually to find specific subsets of a DIT or specifically to create groups which can then be assigned permissions and access rights (using an access to directive).
There appears to be (April 2012) active work ongoing to standardize Dynamic Groups, consequently significant changes may occur when this work is completed. Various documents recommend the current implementation not be used for production soley as a consequence of this lack of standarization. Nevertheless, Dynamic Groups can be incredibly useful (if not essential in certain environments) and are, consequently, widely used.
Configuration
Dynlist is implemented in OpenLDAP as an overlay and is configured as shown in the slapd.conf fragment below:
...
# include the dyngroup schema required for dynlist
include dyngroup.schema
...
# required if the overlay is built dynamically
# the following will require a modulepath directive
# if not in the normath PATH
loadmodule dynlist.la
# OR
loadmodule dynlist.so
...
database bdb
suffix "dc=example,dc=com"
...
# invokes dynlist for this DIT only
# but can be placed in the global section
# in which case it will apply to all DITs
overlay dynlist
dynlist-attrset dyn-objc [URI] url-attr [[map-dn:]member-attr]
...
# other overlay directives or
# next database directive
The following describe each parameter of dynlist-attrset:
dyn-objc
Mandatory. Defines the objectClass that will be used to trigger the dynamic expansion. Typically this will be the groupOfURLs objectClass. When used with this objectClass an entry of the following form would be created in the DIT:
# create the dyngroup group entry
dn: cn=dyngroup,ou=groups,dc=example,dc=com
objectclass: groupOfURLs
cn: dyngroup
memberURL: ldap:///ou=people,dc=example,dc=com?cn,sn?one?(ou=it*)
In this case when a DN of cn=dyngroup, ou=groups, dc=example, dc=com is supplied or encountered in a search operation it triggers the dynamic group feature in the LDAP server.
URI
To be supplied
url-attr
Mandatory. Defines the attribute within the entry containing the objectClass defined in dyn-objc which contains the search URL that will be used to return the results. When used with the groupOfURLs objectClass this is typically the memberURL attribute. an example of such a memberURL attribute is shown below:
memberURL: ldap:///ou=people,dc=example,dc=com?cn,sn?one?(ou=it*)
In this case the LDAP search URL will create a search on the local server (the /// syntax signifies this) from a base of ou=people,dc=example,dc=com to one level below only (one), returning the cn and sn attributes for any entry which has an ou (organizationalUnitName) attribute starting with, or only containing, "it" (case insensitive search). Members of this group (those returned from the search) can then be allocated specific privileges using access to (cn=config, olcAccess) directives.
While the examples illustrate the use of a local search, that need not be the case. For instance the following shows a valid LDAP URL for a remote server:
memberURL: ldap://ldap.example.net/ou=people,dc=example,dc=com?cn,sn?one?(ou=it*)
Depending on the speed of communications and the volumes returned significant time overheads could result from such a search.
map-dn
To be supplied.
member-attr
Optional. When member-attr is present the dynamic group behaves differently. In this case the search returns the DNs of all entries which satisfy the search criteria in the defined attribute (which must be present in the entry which contains the 'trigger' objectClass and which must be of type 'distinguishedName'). Assuming the trigger objectClass is groupOfURLs two attributes 'owner' and 'seeAlso' allow DN attribute types. When used with member-attr the attribute list of the LDAP search URL should be empty. The following snipets show this style of configuration in use:
# slapd.conf fragment
...
overlay dynlist
dynlist-attrset groupOfURLs memberURL owner
...
# create a dyngroup group entry
dn: cn=dyngroup,ou=groups,dc=example,dc=com
objectclass: groupOfURLs
cn: dyngroup
# empty attribute list in search URL
memberURL: ldap:///ou=people,dc=example,dc=com??one?(ou=it*)
In this case the DN of all the entries that satisfy the search will be returned in the attribute owner.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
