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: Using groups Using roles 4.3.1. About Groups 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 be 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 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.) 4.3.1.1. Listing Group Membership in User Entries Groups are essentially lists of user DNs. By default, group membership is only reflected in the group entry itself, not on the user entries. The MemberOf Plug-in, however, uses the group member entries to update user entries dynamically, to reflect on the user entry what groups the user belongs to. The MemberOf Plug-in automatically scans group entries with a specified 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. Group membership is determined by the member attribute on the group entry, but group membership for all groups for a user is reflected in the user's entry in the memberOf attribute. The name of every group to which a user belongs is listed as a memberOf attribute. The values of those memberOf attributes are managed by the Directory Server. Note It is possible, as outlined in Section 6.2.1, "About Using Multiple Databases" , to store different suffixes in different databases. By default, the MemberOf Plug-in only looks for potential members for users who are in the same database as the group. If users are stored in a different database than the group, then the user entries will not be updated with memberOf attributes because the plug-in cannot ascertain the relationship between them. The MemberOf Plug-in can be configured to search through all configured databases by enabling the memberOfAllBackends attributes. A single instance of the MemberOf Plug-in can be configured to identify multiple member attributes by setting the multi-valued memberofgroupattr in the plug-in entry, so the MemberOf Plug-in can manage multiple types of groups. 4.3.1.2. Automatically Adding New Entries to Groups Group management can be a critical factor for managing directory data, especially for clients which use Directory Server data and organization or which use groups to apply functionality to entries. Groups make it easier to apply policies consistently and reliably across the directory. Password policies, access control lists, and other rules can all be based on group membership. Being able to assign new entries to groups, automatically, at the time that an account is created ensures that the appropriate policies and functionality are immediately applied to those entries - without requiring administrator intervention. The Automembership Plug-in essentially allows a static group to act like a dynamic group. It uses a set of rules (based on entry attributes, directory location, and regular expressions) to assign a user automatically to a specified group. There can be instances where entries that match the LDAP search filter should be added to different groups, depending on the value of some other attribute. For example, machines may need to be added to different groups depending on their IP address or physical location; users may need to be in different groups depending on their employee ID number. Automember definitions are a set of nested entries, with the Auto Membership Plug-in container, then the automember definition, and then any regular expression conditions for that definition. Figure 4.13. Regular Expression Conditions Note Automembership assignments are only made automatically when an entry is added to the Directory Server. For existing entries or entries which are edited to meet an automember rule, there is a fix-up task which can be run to assign the proper group membership. 4.3.2. About Roles 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. Note 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 the specified 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.

Commands: