Dynamic groups

A dynamic group is defined as a group in which membership is determined using one or more LDAP search expressions. Each time a dynamic group is used by the LDAP server, a user's membership in the group is decided by determining if the user entry matches any of the search expressions. The ibm-dynamicGroup and groupOfURLs object classes each use the multi-valued attribute called memberURL to define the LDAP search expression. These object classes and attribute are always in the LDAP server schema and cannot be modified.

Dynamic groups allow the group administrator to define membership in terms of attributes and allow the directory itself to determine who is or is not a member of the group. For example, members do not need to be manually added or deleted when a person moves to a different project or location.

Alias and referral entries are not processed during the group membership search.

The following simplified LDAP URL syntax must be used as the value of memberURL attribute to specify the dynamic group search expression.
Specifies the DN of the entry from which the search begins in the directory. The dynamic URL is not used if the base entry is not within the same backend as the dynamic group entry. This parameter is required.
Specifies the extent of the search. The default scope is base.
Returns information only about the baseDN specified in the URL.
Returns information about entries one level below the baseDN specified in the URL. It does not include the baseDN.
Returns information about entries at all levels below and including the baseDN.
Is the filter that you want applied to the entries within the scope of the search. See ldapsearch in z/OS IBM Tivoli Directory Server Client Programming for z/OS for additional information about LDAP search filters. The default is "objectclass=*".
Note: As the format above suggests, the host name must not be present in the syntax. The remaining parameters are just like the normal LDAP URL syntax, which is defined in RFC 2255: The LDAP URL Format (except there is no support for extensions in the URL). Each parameter field must be separated by a ?, even if no parameter is specified. Normally, a list of attributes to return would have been included between the baseDN and searchScope. An add or modify operation of a dynamic group entry fails if it contains a memberURL attribute that is not in the correct format. This prevents introducing an improperly formatted memberURL attribute into the LDAP server. If migrating from an Integrated Security Services LDAP server on earlier releases and there are memberURL attribute values that not properly formatted in the directory, they are ignored by the LDAP server.

An entry is considered to be a member of the dynamic group if it falls within the search scope and matches the search filter. Alias entries and referral entries are treated as normal entries during the group membership search; no alias dereferencing or referral processing is performed.

A typical dynamic group entry is the following:
dn: cn=ldap_team_dynamic,o=endicott
objectclass: groupOfURLs
cn: ldap_team_dynamic
memberURL: ldap:///o=endicott??sub?(ibm-group=ldapTeam)

Dynamic group search filter examples

A single entry in which the scope defaults to base and the filter defaults to "objectclass=*":
The "In Flight Systems" team with a scope of one-level and the filter defaults to "objectclass=*":
ldap:///ou=In Flight Systems,ou=Endicott,o=ibm,c=us??one	
A subtree search for all the support staff in Endicott:
A subtree search for all the Garcias or Nguyens whose first name begins with an "A":
A search filter that includes escaped percent signs, question marks, and spaces in the base DN (o=deltawing infosystems) and filter ((&(percent=10%)(description=huh?))):