11 Directory Server Groups and Roles

The directory information tree organizes entries hierarchically. This hierarchy is a type of grouping mechanism. The hierarchy is not well suited for associations between dispersed entries, for organizations that change frequently, or for data that is repeated in many entries. Directory Server groups and roles offer more flexible associations between entries.

This chapter describes how groups and roles are used by Directory Server to associate entries with each other. This chapter covers the following topics:

Directory Server Groups
Directory Server Roles
Deciding Between Groups and Roles

11.1 Directory Server Groups

A group is an entry that identifies the other entries that are in the group. The group mechanism makes it easy to retrieve a list of entries that are members of a given group.

Although groups may identify members anywhere in the directory, the group definitions themselves should be located under an appropriately named node such as ou=Groups. This makes them easy to find, for example, when defining access control instructions (ACIs) that grant or restrict access when the bind credentials are members of a group.

11.1.1 Static Groups

Static groups explicitly name their member entries. For example, a group of directory administrators would name the specific people who formed part of that group, as shown in the following illustration.

Description of the illustration groups1.png

The following LDIF extract shows how the members of this static group would be defined.

dn: cn=Directory Administrators, ou=Groups, dc=example,dc=com
...
member: uid=kvaughan, ou=People, dc=example,dc=com
member: uid=rdaugherty, ou=People, dc=example,dc=com
member: uid=hmiller, ou=People, dc=example,dc=com

Static groups specify the DN of each member of the group. Static groups use one of the following object class and attribute pairs:

The groupOfNames object class, with a multi-valued member attribute
The groupOfUniqueNames object class, with a multi-valued uniqueMember attribute

The member attribute and uniqueMember attribute contain the DN for every entry that is a member of the group. The uniqueMember attribute value for the DN is optionally followed by a hash, #, and a unique identifier label to guarantee uniqueness.

11.1.2 Dynamic Groups

Dynamic groups specify a filter and all entries that match the filter are members of the group. These groups are dynamic because membership is defined each time the filter is evaluated.

Imagine, for example, that all management employees and their assistants were situated on the 3rd floor of your building, and that the room number of each employee commenced with the number of the floor. If you wanted to create a group containing just the employees on the third floor, you could use the room number to define just these employees, as shown in the following illustration.

Description of the illustration groups2.png

The following LDIF extract shows how the members of this dynamic group would be defined.

dn: cn=3rd Floor, ou=Groups, dc=example,dc=com
...
memberURL: ldap:///dc=example,dc=com??sub?(roomnumber=3*)

Dynamic groups use one of the following object class and attribute pairs:

The groupOfURLs object class, with the memberURL attribute
The groupOfUniqueNames object class, with the uniqueMember attribute

The group members are listed either by one or more filters represented as LDAP URL values of the memberURL attribute or by one or more DNs as values of the uniqueMember attribute.

11.1.3 Nested Groups

Static and dynamic groups can be nested by specifying the DN of another group as a value for the member attribute or uniqueMember attribute. The depth to which nested groups are supported by ACIs is controlled by the nsslapd-groupevalnestlevel configuration parameter. Directory Server also supports mixed groups, that is groups that reference individual entries, static groups, and dynamic groups.

Imagine for example that you wanted a group containing all directory administrators, and all management employees and their assistants. You could use a combination of the two groups defined earlier to create one nested group, as shown in the following illustration.

Description of the illustration groups3.png

The following LDIF extract shows how the members of this nested group would be defined.

dn: cn=Admins and 3rd Floor, ou=Groups, dc=example,dc=com
...
member: cn=Directory Administrators, ou=Groups, dc=example,dc=com
member: cn=3rd Floor, ou=Groups, dc=example,dc=com

Caution:

Nested groups are not the most efficient grouping mechanism. Dynamic nested groups incur an even greater performance cost. To avoid these performance problems, consider using roles instead.

11.2 Directory Server Roles

Roles are similar to groups but work in the opposite way — where a group entry lists the DN of the member entries, the DN of a role entry is listed on each member entry. The role mechanism makes it is easy to retrieve a list of roles that are assigned to an entry.

Each role has members, or entries that possess the role. The role mechanism is managed by the nsRoleDN attribute and the nsRole attribute. The nsRoleDN attribute is used to add an entry to a role. The nsRole attribute is a read-only attribute, maintained by the directory server, that lists the roles to which an entry belongs. The nsRole attribute can be read or searched by clients to enumerate all roles to which an entry belongs. If you do not want to expose role membership, define access controls to read-protect the nsRole attribute.

By default, the scope of a role is limited to the subtree where it is defined. The scope of a role can be extended to other subtrees on the same server instance.

11.2.1 Managed Roles

Managed roles are functionally very similar to static groups. Managed roles explicitly assign a role to each member entry by adding the nsRoleDN attribute to the entry. The value of this attribute is the DN of the role definition entry.

The role definition entry only defines the scope of the role in the directory. Members of the role are entries that lie within the scope of the role definition, and that identify the role definition entry with their nsRoleDN attributes.

11.2.2 Filtered Roles

Filtered roles are equivalent to dynamic groups. Entries are assigned a role if they match a specified search filter. The value of the search filter is defined by the nsRoleFilter attribute. When the server returns an entry in the scope of a filtered role, that entry contains the generated nsRole attribute that identifies the role.

11.2.3 Nested Roles

Nested roles are equivalent to nested groups. Nested roles enable you to create roles that contain other roles and to extend the scope of existing roles. A nested role can itself contain another nested role. Up to 30 levels of nesting are supported

A nested role lists the definition entries of other roles and combines all the members of their roles. If an entry is a member of a role that is listed in a nested role, then the entry is also a member of the nested role.

11.2.4 Limitations on Using Roles

When you use roles to support your directory service, be aware of the following limitations.

Filtered Roles cannot use CoS generated attributes

The filter string of a filtered role cannot be based on the values of a CoS virtual attribute. However, the specifier attribute in a CoS definition may reference the nsRole attribute generated by a role definition. For information about CoS, see Chapter 12, "Directory Server Class of Service".

Extending the scope of roles

You can extend the scope of roles to different subtrees but they must be on the same server instance. You cannot extend the scope of roles to other servers.

Searches on the nsRole attribute

The nsRole attribute can be used in any search filter with any of the comparison operators. When you search on nsRole attribute, consider the following points:

Searches on the nsRole attribute can take a long time because all roles must be evaluated before the entries can be filtered.
Directory Server is optimized for equality searches on membership in managed roles. For example, this search will be nearly as fast as a search on real attributes.
```
(&(nsRole=cn=managersRole,ou=People,dc=example,dc=com)
 (objectclass=person)
```
The nsRoleDN attribute is indexed by default in all suffixes. Optimizations for searching the membership of managed roles are lost if indexing is disabled for the nsRoleDN attribute.
Searches for entries that contain a filtered role involve an internal search with the role filter. This internal operation will be fastest if all attributes that appear in the role filter are indexed in all suffixes in the scope of the role.

11.3 Deciding Between Groups and Roles

The functionality of the groups and roles mechanisms overlap somewhat. Both mechanisms have advantages and disadvantages. Generally, the roles mechanism is designed to provide frequently required functionality more efficiently. Because the choice of a grouping mechanism influences server complexity and determines how clients process membership information, you must plan your grouping mechanism carefully. To decide which mechanism is more suitable, you need to understand the typical membership queries and management operations that are performed.

11.3.1 Advantages of the Groups Mechanism

Groups have the following advantages:

Static groups are the only standards-based grouping mechanism. Static groups are therefore interoperable with most client applications and LDAP servers.
Static groups are preferable to roles for enumerating members.

If you only need to enumerate members of a given set, static groups are less costly. Enumerating members of a static group by retrieving the member attribute is easier than recovering all entries that share a role. In Directory Server, significant performance improvements have been made for large multi-valued attributes. Equality matching and modify operations on these attributes are greatly improved, specifically in relation to static groups. Membership testing for group entries has also been improved. These improvements remove some of the previous restrictions on static groups, specifically the restriction on group size.

Directory Server also provides group membership directly in user entries, with the isMemberOf operational attribute. This feature applies to static groups only but includes nested groups. For more information, see Managing Groups in Administrator's Guide for Oracle Directory Server Enterprise Edition.
Static groups are preferable to roles for management operations such as assigning and removing members.

Static groups are the simplest mechanism for assigning a user to a set or removing a user from a set. Special access rights are not required to add the user to the group.

The right to create the group entry automatically gives you the right to assign members to that group. This is not the case for managed and filtered roles. In these roles, the administrator must also have the right to write the nsroledn attribute to the user entry. The same access right restrictions also apply indirectly to nested roles. The ability to create a nested role implies the ability to pull together other roles that have already been defined.
Dynamic groups are preferable to roles for use in filter-based ACIs.

If you only need to find all members based on a filter, such as for designating bind rules in ACIs, use dynamic groups. Although filtered roles are similar to dynamic groups, filtered roles trigger the roles mechanism and generate the virtual nsRole attribute. If your client does not need the nsRole value, use dynamic groups to avoid the overhead of this computation.
Groups are preferable to roles for adding or removing sets into or from existing sets.

If you want to add a set to an existing set, or remove a set from an existing set, the groups mechanism is simplest. The groups mechanism presents no nesting restrictions. The roles mechanism only allows nested roles to receive other roles.
Groups are preferable to roles if flexibility of scope for grouping entries is critical.

Groups are flexible in terms of scope because the scope for possible members is the entire directory, regardless of where the group definition entries are located. Although roles can also extend their scope beyond a given subtree, they can only do so by adding the scope-extending attribute nsRoleScopeDN to a nested role.

11.3.2 Advantages of the Roles Mechanism

Roles have the following advantages:

Roles are preferable to dynamic groups if you want to enumerate members of a set and find all sets of which a given entry is a member. Static groups also provide this functionality with the isMemberOf attribute.

Roles push membership information out to the user entry where this information can be cached to make subsequent membership tests more efficient. The server performs all computations, and the client only needs to read the values of the nsRole attribute. In addition, all types of roles appear in this attribute, allowing the client to process all roles uniformly. Roles can perform both operations more efficiently and with simpler clients than is possible with dynamic groups.
Roles are preferable to groups if you want to integrate your grouping mechanism with existing Directory Server functionality such as CoS, Password Policy, Account Inactivation, and ACIs.

If you want to use the membership of a set "naturally" in the server, roles are a better option. This implies that you use the membership computations that the server does automatically. Roles can be used in resource-oriented ACIs, as a basis for CoS, as part of more complex search filters, and with Password Policy, Account Inactivation, and so forth. Groups do not allow this kind of integration.

11.3.3 Restricting Permissions on Roles

Be aware of the following issues when using roles:

The nsRole attribute can only be assigned by the roles mechanism. While this attribute cannot be assigned or modified by any directory user, it is potentially readable by any directory user. Define access controls to keep this attribute from being read by unauthorized users.
The nsRoleDN attribute defines managed role membership. You need to decide whether users can add or remove themselves from the role. To keep from modifying their own roles, you must define an ACI to that effect.
Filtered roles determine membership through filters that are based on the existence or the values of attributes in user entries. Assign the user permissions of these attributes carefully to control who can define membership in the filtered role.