Directory Server Groups (People)

draft-piket-groups-of-people-00.html

MACE-Dir-Groups

Todd Piket - Michigan Technological University

DRAFT Revision 1.1, July 17, 2001

 

Introduction

 

The concept of grouping people together is not unique.  However, a directory server is tremendously flexible and grouping people in it the "correct way" can be extremely difficult.  This begs the obvious question "What is the correct way"?

 

The following things need to be considered when grouping data in a directory server:

 

Group Member Management

 

Who is in the group?  Management of the groups and the members therein is key.  Without good management, chaos will quickly destroy a system of groups no matter how well thought out it is.

 

A key to good management is in the tools used to do the managing.  The tools should be some sort of application that interacts directly with the server containing the groups, most likely a web application of some sort.  This application should rely on the same grouping model that will be used for everyone else.  So, the first group that should be created is a super administrators group.  Within this group are the people that can give out access to any other group, including the super administrator group.  This group can also create subordinate administrative groups to dole out responsibility of group member management to the departments/sections/whatever that best know how to dole out access for their own people.  So, a hierarchical order is established with varying security levels (figure 1).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Groups in Groups

 

Grouping people together is extremely useful, but to make this mechanism more powerful, and in this writer's opinion viable, the concept of groups within groups MUST be supported.  While an immensely powerful concept, implementing this causes a couple of problems.

 

How is this achieved without creating a large performance hit on the directory server?  This depends on the directory server.  If your directory server vendor doesn't support groups within groups, it is up to us to badger that vendor until they do.  If that vendor doesn't support groups at all, then that vendor really needs some badgering.  Meanwhile, the directory server of choice should have an API of some sort that allows one to write a plugin.  If your directory server vendor doesn't provide an API, once again badgering will be necessary.

 

One other problem created with groups in groups is the possibility of an infinite loop when resolving the members.  For instance, if Group A contains Group B and Group B contains Group A then an infinite loop occurs when the member resolution is attempted.  So, if your vendor supports groups in groups it is a MUST that they handle the possibility of an infinite loop.  If they do not and you are writing a plugin, make sure to handle this possibility.

 

Referential Integrity

 

Yet another obstacle created with groups is the concept of referential integrity.  Referential integrity watches certain attributes and makes sure that if something causes one to change, then that change is propagated to all other appropriate locations in the directory server.

 

Let's say you have a user named Bob, for example, and this user is in Group A, Group B, and Group D.  Bob is retiring from the company and when he does his person entry is deleted from the directory server.  Without referential integrity Bob will still be in Group A, Group B, and Group D until someone notices this and removes the invalid entry from the groups.  With referential integrity Bob will be removed from these groups automatically when his entry is deleted.  Similarly, if Bob were a group, then referential integrity would remove the group from all other groups it is in.

 

Some directory server vendors provide referential integrity.  If not, one will have to decide on writing a plugin to handle it within the server, or having the management tools perform the referential integrity checks.

 

Search performance

 

Putting one's groups in a directory server will, most likely, introduce a large performance hit to that directory server.  As a result, the performance of searching for and through these groups MUST be taken into account and every effort MUST be made to reduce the load introduced to the directory server.

 

There are, generally, two types of DIT models within a directory server, tall and spiky, or flat and bushy.  Any directory deployment guide will show these models and discuss in depth for those that wish to know more about them.  The two can coexist in one directory server, though it would be a rare sight to see.  Figure 1 above depicts the access control associated with administrative groups in a tall and spiky model.  However, this representation does NOT and, in this writer's opinion, SHOULD NOT manifest itself in the structure of the DIT.  The hierarchical access control can be achieved by means of Access Control Lists (ACLs) and Access Control Instructions (ACIs) within the directory server.  The actual DIT should be as flat as possible (flat and bushy) to provide better search performance.

 

If writing a plugin to handle groups and/or groups in groups one needs to take a good look at the vendor's API.  If the API is done correctly there should be internal operations (i.e., operations that don't have the overhead of logging, ACI resolution, etc.) that would be used to resolve members of groups and/or groups that contain other groups.  The internal operations are necessary to reduce the load this resolution would cause on the directory server.  If the vendor's API does not have internal operations, that vendor should be contacted right away.

 

Schema/Directory Information Tree (DIT)

 

Until now, this writer hasn't put too many constraints on the DIT of one's directory server.  The attitude of this writer is to try to accommodate any DIT out there by minimizing the need to conform to any particular structure.  However, a couple of things are required for this model to work.

 

Most of all, the model requires the use of the objectclass groupOfUniqueNames as well as the attribute uniqueMember.  The uniqueMember attribute uses the Distinguished Name (DN) syntax and so its value MUST be a DN.  The DN value MUST be the DN of a person in the directory server.

 

The groups in groups implementation will require an extension to the groupOfUniqueNames objectclass or a new objectclass altogether in order to support the uniqueGroupMember attribute using the DN syntax.  In this writer's opinion, the attribute for group DNs should be separate from those for user DNs for human readability as well as programmatic simplicity.