Groups are a quick way of giving users common access to certain features or functionality within an LDAP directory. The access to directive (cn=config, olcAccess) contains a group specific variant in the <who> clause for just this purpose. The actual rights assigned to the group are also defined in the Access to directive (cn=config, olcAccess). Groups can be configured statically using the groupofnames objectClass. In essence, each member of such groups has to be invidually defined and subsequently maintained if their status or group membership changes. LDAP provides a Dynamic Group feature whereby groups can be created dynamically using an LDAP search. This can be very efficient where memership of groups is extremely large or constantly changing. The Dynamic Group feature is widely implemented by multiple vendors since it meets a major need but is not standardized (there is no RFC).
Dynamic groups typically use the groupOfURLs objectClass.
The following LDIF fragments shows building a group called itpeople who could be given privileges to access or change passwords or configuration parameters in user entries. The group members will be created dynamically through a URL based search. This configuration creates a separate branch called groups under which is placed the itpeople group. The following diagram illustrates this organisation:
# dynlist fragment from slapd.conf ... # required schema for dynamic groups include /etc/openldap/schema/dyngroup.schema ... # example - permanent load of the dynlist overlay # non-absolute format requires modulepath directive # modulepath /usr/libexec/openldap loadmodule dynlist.la # absolute path format # does not require modulepath directive loadmodule /usr/libexec/openldap/dynlist.la ... database bdb ... # if used after a database directive scope is limited # can also appear before any database directive for # global scope overlay dynlist dynlist-attrset groupOfURLs memberURL ...
The above definition indicates that when a groupOfURLs objectClass is encountered by the server it will perform the search defined in the memberURL attribute and return the result set (see dynlist overlay for a full list of parameters and their explanation).
# LDIF fragment to create group branch under root dn: ou=groups,dc=example,dc=com objectclass:organizationalunit ou: groups description: generic groups branch # create the itpeople group entry dn: cn=itpeople,ou=groups,dc=example,dc=com objectclass: groupOfURLs cn: itpeople memberURL: ldap:///ou=people,dc=example,dc=com?cn,sn?one?(ou=it*) ...
The 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.
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.
3 ldap objects
4 install ldap
7 replica & refer
10 ldap api
14 ldap tools
notes & info
rfc's & x.500
This work is licensed under a Creative Commons License.
If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox