A dynamic group defines its members differently than a static group. Instead of listing them individually, the dynamic group defines its members using an LDAP search. The dynamic group uses the structural objectclass groupOfURLs (or auxiliary objectclass ibm-dynamicGroup) and the attribute, memberURL to define the search using a simplified LDAP URL syntax.
ldap:///<base DN of search> ? ? <scope of search> ? <searchfilter>
where:
The search for dynamic members is always internal to the server, so unlike a full ldap URL, a host name and port number is never specified, and the protocol is always ldap (never ldaps). The memberURL attribute can contain any kind of URL, but the server only uses memberURLs beginning with ldap:/// to determine dynamic membership.
Examples
A single entry in which the scope defaults to base and the filter defaults to objectclass=*:
ldap:///cn=John Doe, cn=Employees, o=Acme, c=US
All entries that are 1-level below cn=Employees, and the filter defaults to objectclass=*:
ldap:///cn=Employees, o=Acme, c=US??one
All entries that are under o-Acme with the objectclass=person:
ldap:///o=Acme, c=US??sub?objectclass=person
Depending on the object classes you use to define user entries, those entries might not contain attributes which are appropriate for determining group membership. You can use the auxiliary object class, ibm-dynamicMember, to extend your user entries to include the ibm-group attribute. This attribute allows you to add arbitrary values to your user entries to serve as targets for the filters of your dynamic groups. For example:
The members of this dynamic group are entries directly under the cn=users,ou=Austin entry that have an ibm-group attribute of GROUP1:
dn: cn=GROUP1,ou=Austin objectclass: groupOfURLs cn: GROUP1 memberURL: ldap:///cn=users,ou=Austin??one?(ibm-group=GROUP1)
Here is an example member of cn=GROUP1,ou=Austin:
dn: cn=Group 1 member, cn=users, ou=austin objectclass: person objectclass: ibm-dynamicMember sn: member userpassword: memberpassword ibm-group: GROUP1