4.3. Grouping Directory Entries
After creating the required entries, group them for ease of administration. The Directory Server supports several methods for grouping entries:
Groups, as the name implies, are simply collections of users. There are several different types of groups in Directory Server which reflects the type of memberships allowed, like certificate groups, URL groups, and unique groups (where every member must unique). Each type of group is defined by an object class (such as groupOfUniqueNames) and a corresponding member attribute (such as uniqueMember).
The type of group identifies the type of members. The configuration of the group depends on how those members are added to the group. Directory Server has two kinds of groups:
Static groups have a finite and defined list of members which are added manually to the group entry.
Dynamic groups use filters to recognize which entries are members of the group, so the group membership is constantly changed as the entries which match the group filter change.
Groups are essentially lists of user DNs. By default, group membership is only reflected in the group entry itself, not on the user entries. However, there are two plug-ins that can be enabled to show group membership in user entries:
The MemberOf Plug-in automatically scans group entries with a member attribute, traces back all of the user DNs, and creates a corresponding memberOf attribute on the user entry, with the name of the group.
The Linked Attributes Plug-in is like the MemberOf Plug-in in that an attribute with a DN value is checked, and then another attribute is created on that specified DN, pointing back to the original entry. There can be multiple instances of the Linked Attributes Plug-in, however, so that all different types of groups and member attributes can be checked and the corresponding user entries updated with group membership, not just groups that use the member attribute.
Groups are the simplest form of organizing entries in Directory Server. They are largely manually configured and there is no functionality or behavior for them beyond being an organization method. (Really, groups do not "do" anything to directory entries, though groups can be manipulated by LDAP clients to perform operations.)
Roles are a sort of hybrid group, behaving as both a static and a dynamic group. With a group, entries are added to a group entry as members. With a role, the role attribute is added to an entry and then that attribute is used to identify members in the role entry automatically.
Roles effectively and automatically organize users in a number of different ways:
Explicitly listing role members. Viewing the role will display the complete list of members for that role. The role itself can be queried to check membership (which is not possible with a dynamic group).
Showing to what roles an entry belongs. Because role membership is determined by an attribute on an entry, simply viewing an entry will show all of the roles to which it belongs. This is similar to the memberOf attributes for groups, only it is not necessary to enable or configure a plug-in instance for this functionality to work. It is automatic.
Assigning the appropriate roles. Role membership is assigned through the entry, not through the role, so the roles to which a user belongs can be easily assigned and removed by editing the entry, in a single step.
Managed roles can do everything that can normally be done with static groups. The role members can be filtered using filtered roles, similarly to the filtering with dynamic groups. Roles are easier to use than groups, more flexible in their implementation, and reduce client complexity.
Role members are entries that possess the role. Members can be specified either explicitly or dynamically. How role membership is specified depends upon the type of role. Directory Server supports three types of roles:
Managed roles have an explicit enumerated list of members.
Filtered roles are assigned entries to the role depending upon the attribute contained by each entry, specified in an LDAP filter. Entries that match the filter possess the role.
Nested roles are roles that contain other roles.
Roles The concept of activating/inactivating roles allows entire groups of entries to be activated or inactivated in just one operation. That is, the members of a role can be temporarily disabled by inactivating the role to which they belong.
When a role is inactivated, it does not mean that the user cannot bind to the server using that role entry. The meaning of an inactivated role is that the user cannot bind to the server using any of the entries that belong to that role; the entries that belong to an inactivated role will have the nsAccountLock attribute set to true.
When a nested role is inactivated, a user cannot bind to the server if it is a member of any role within the nested role. All the entries that belong to a role that directly or indirectly are members of the nested role have nsAccountLock set to true. There can be several layers of nested roles, and inactivating a nested role at any point in the nesting will inactivate all roles and users beneath it.
4.3.3. Deciding Between Roles and Groups
Roles and groups can accomplish the same goals. Managed roles can do everything that static groups can do, while filtered roles can filter and identify members as dynamic groups do. Both roles and groups have advantages and disadvantages. Deciding whether to use roles or groups (or a mix) depends on balancing client needs and server resources.
Roles reduce client-side complexity, which is their key benefit. With roles, the client application can check role membership by searching the nsRole operational attribute on entries; this multi-valued attribute identifies every role to which the entry belongs. From the client application point of view, the method for checking membership is uniform and is performed on the server side.
However, this ease of use for clients comes at the cost of increased server complexity.
Evaluating roles is more resource-intensive for the Directory Server than evaluating groups because the server does the work for the client application.
While groups are easier for the server, they require smarter and more complex clients to use them effectively. For example, dynamic groups, from an application point of view, offer no support from the server to provide a list of group members. Instead, the application retrieves the group definitions and then runs the filter. Group membership is only reflected on user entries if the appropriate plug-ins are configured. Ultimately, the methods for determining group membership are not uniform or predictable.
One thing that can balance managing group membership is the memberOf Plug-in. Using the memberOf strikes a nice balance between being simple for the client to use and being efficient for the server to calculate.
The memberOf Plug-in dynamically creates memberOf attribute on a user entry whenever a user is added to a group. A client can run a single search on a group entry to get a list of all of its members, or a single search on a user entry to get a complete list of all the groups it belongs to.
The server only has maintenance overhead when the membership is modified. Since both member (group) and memberOf (user) attributes are stored in the database, there is no extra processing required for searches, which makes the searches from the clients very efficient.
