cn=Directory Manager

cn=Directory Manager
All about Directory Server

All | Personal | Sun

« Previous day (May 10, 2007) | Main | Next day (May 11, 2007) »

Friday May 11, 2007

Virtual Static Groups in OpenDS

Big static groups (with tens or hundreds of thousands of members, or more) are a problem in many large enterprise directories. Since a static group contains an explicit list of the DNs of its members, the more members it contains, the larger the entry will become. Maintaining these groups can become a management problem and isn't very efficient, and some types of searches involving them can be slow as well. Dynamic groups are much better when the groups contain thousands or millions of members, but the problem is that many client applications don't support them. It's easy to understand why, since the client does have a significant amount of work to do in order to determine whether a given user is a member of a dynamic group, but it's also unfortunate because it leads to a lot of cases in which directories are forced to end up with large static groups just to suit those applications.

OpenDS provides an interesting solution to this problem in the form of virtual static groups. It's a special type of entry that behaves like a static group, but all operations which attempt to determine membership are passed through behind the scenes to another group. In many cases, virtual static groups can give you the management and scalability benefits that dynamic groups provide while still maintaining compatibility with clients that only support static groups.

In order to use virtual static groups, you first need a dynamic group that will provide the membership criteria. For the purposes of this example, let's say that we have the following entry:

dn: cn=Austin Users,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfURLs
cn: Austin Users
memberURL: ldap:///ou=People,dc=example,dc=com??sub?(&(l=Austin)(st=Texas))

This group will automatically include any user with a location of Austin and a state of Texas. It's a much better choice for a dynamic group than a static group because the set of members will be automatically adjusted as new users are added, existing users are removed, or if someone moves from one place to another.

To create a virtual static group that allows clients to interact with the Austin Users group in a static manner, add the following entry:

dn: cn=Virtual Static Austin Users,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
objectClass: ds-virtual-static-group
cn: Virtual Static Austin Users
ds-target-group-dn: cn=Austin Users,ou=Groups,dc=example,dc=com

With this group, uniqueMember will be treated as a virtual attribute (if we had used the groupOfNames instead of groupOfUniqueNames, then the member attribute would have been used instead). The key here is the ds-virtual-static-group auxiliary object class and the corresponding ds-target-group-dn attribute. OpenDS sees this and knows that it should treat the entry like a virtual static group.

Now, consider that the following users exist in the directory:

dn: uid=nawilson,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: nawilson
givenName: Neil
sn: Wilson
cn: Neil Wilson
l: Austin
st: Texas

dn: uid=bowendk,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: bowendk
givenName: Don
sn: Bowen
cn: Don Bowen
l: Peoria
st: Illinois

With thiese entries, the user "nawilson" will be considered a member of the group because he is located in Austin, Texas, whereas user "bowendk" will not. A quick test with ldapsearch confirms this:

$ bin/ldapsearch -b 'cn=Virtual Static Austin Users,ou=Groups,dc=example,dc=com' \
  -s base --countEntries '(uniqueMember=uid=nawilson,ou=People,dc=example,dc=com)' 1.1
dn: cn=Virtual Static Austin Users,ou=Groups,dc=example,dc=com

# Total number of matching entries:  1

$ bin/ldapsearch -b 'cn=Virtual Static Austin Users,ou=Groups,dc=example,dc=com' \
  -s base --countEntries '(uniqueMember=uid=bowendk,ou=People,dc=example,dc=com)' 1.1
# Total number of matching entries:  0

Note that while dynamic groups are very efficient for determining whether a given user is a member, they can be very inefficient when it comes to retrieving the entire set of members. This is also the case with virtual static groups that use dynamic groups to get their membership information. If you were to actually retrieve the uniqueMember attribute to list all of the members, that could be a very expensive operation. OpenDS provides a way to deal with this in the form of the ds-cfg-allow-retrieving-membership configuration attribute. It defaults to "false", which means that queries like those above which try to determine whether a given user is a member of the group will succeed, but the uniqueMember attribute won't be included in the resulting entry even if it's requested by the client. Most well-behaved clients won't ask for the membership attribute anyway, and of those that do many of them don't use it in any way, so this doesn't cause a problem. However, if you do have an application that expects to retrieve the membership attribute and won't behave properly if it isn't returned, then you're probably stuck with a traditional static group.

Also note that there's no requirement that virtual static groups be used only with dynamic groups. You can actually use it with any type of group (other than another virtual static group, to avoid circular references) that OpenDS supports (right now, we've only got static and dynamic groups, but we may add other types in the future). For example, if you've got a static group based on the groupOfUniqueNames object class but your client only supports groups with the groupOfNames class, then you could create a virtual static group with the groupOfNames structural object class and point the ds-target-group-dn attribute at the static group with the groupOfUniqueNames class.

Posted by cn_equals_directory_manager ( May 11 2007, 11:45:17 AM CDT ) Permalink