8.2. Using Roles

Roles are an entry grouping mechanism that unify the static and dynamic groups described in the previous sections. Roles are designed to be more efficient and easier to use for applications. For example, an application can get the list of roles of which an entry is a member by querying the entry itself, rather than selecting a group and browsing the members list of several groups.

8.2.1. About Roles

Red Hat has two kinds of groups. Static groups have a finite and defined list of members. Dynamic groups used 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. (Both kinds of groups are described in Section 8.1, “Using Groups”.)
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.
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.
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.
When a role is created, determine whether a user can add themselves or remove themselves from the role. See Section 8.2.10, “Using Roles Securely” for more information about roles and access control.

Note

Evaluating roles is more resource-intensive for the Directory Server than evaluating groups because the server does the work for the client application. With roles, the client application can check role membership by searching for the nsRole attribute. The nsRole attribute is a computed attribute, which identifies to which roles an entry belongs; the nsRole attribute is not stored with the entry itself. From the client application point of view, the method for checking membership is uniform and is performed on the server side.
Considerations for using roles are covered in the Red Hat Directory Server Deployment Guide.

8.2.2. Creating a Managed Role

Managed roles have an explicit enumerated list of members. Managed roles are added to entries by adding the nsRoleDN attribute to the entry.

8.2.2.1. Creating a Managed Role in the Console

  1. In the Directory Server Console, select the Directory tab.
  2. Browse the tree in the left navigation pane, and select the parent entry for the new role.
  3. Go to the Object menu, and select New > Role.
    Alternatively, right-click the entry and select New > Role.
  4. Click General in the left pane. Type a name for the new role in the Role Name field. The role name is required.
  5. Enter a description of the new role in the Description field.
  6. Click Members in the left pane.
  7. In the right pane, select Managed Role. Click Add to add new entries to the list of members.
  8. In the Search drop-down list, select Users from the Search drop-down list, then click Search. Select one of the entries returned, and click OK.
  9. After adding all of the entries, click OK.

8.2.2.2. Creating Managed Roles through the Command Line

Roles inherit from the ldapsubentry object class, which is defined in the ITU X.509 standard. In addition, each managed role requires two object classes that inherit from the nsRoleDefinition object class:
  • nsSimpleRoleDefinition
  • nsManagedRoleDefinition
A managed role also allows an optional description attribute.
Members of a managed role have the nsRoleDN attribute in their entry.
This example creates a role which can be assigned to the marketing department.
  1. Use ldapmodify with the -a option to add the managed role entry. The new entry must contain the nsManagedRoleDefinition object class, which in turn inherits from the LdapSubEntry, nsRoleDefinition, and nsSimpleRoleDefinition object classes. 
    dn: cn=Marketing,ou=people,dc=example,dc=com
objectclass: top
objectclass: LdapSubEntry
objectclass: nsRoleDefinition
objectclass: nsSimpleRoleDefinition
objectclass: nsManagedRoleDefinition
cn: Marketing
description: managed role for marketing staff
  2. Assign the role to the marketing staff members, one by one, using ldapmodify: 
    dn: cn=Bob,ou=people,dc=example,dc=com
changetype: modify
add: nsRoleDN
nsRoleDN: cn=Marketing,ou=people,dc=example,dc=com
    The nsRoleDN attribute in the entry indicates that the entry is a member of a managed role, cn=Marketing,ou=people,dc=example,dc=com.

8.2.3. Creating a Filtered Role

Entries are assigned to a filtered role depending whether the entry possesses a specific attribute defined in the role. The role definition specifies an LDAP filter for the target attributes. Entries that match the filter possess (are members of) the role.

8.2.3.1. Creating a Filtered Role in the Console

  1. In the Directory Server Console, select the Directory tab.
  2. Browse the tree in the left navigation pane, and select the parent entry for the new role.
  3. Go to the Object menu, and select New > Role.
    Alternatively, right-click the entry and select New > Role.
  4. Click General in the left pane. Type a name for the new role in the Role Name field. The role name is required.
  5. Enter a description of the new role in the Description field.
  6. Click Members in the left pane.
    A search dialog box appears briefly.
  7. In the right pane, select Filtered Role.
  8. Enter an LDAP filter in the text field, or click Construct to be guided through the construction of an LDAP filter.
    The Construct opens the standard LDAP URL construction dialog. Ignore the fields for LDAP Server Host, Port, Base DN, and Search (since the search scope cannot be set filtered role definitions).
    • Select the types of entries to filter from the For drop-down list. The entries can be users, groups, or both.
    • Select an attribute from the Where drop-down list. The two fields following it refine the search by selecting one of the qualifiers from the drop-down list, such as contains, does not contain, is, or is not. Enter an attribute value in the text box. To add additional filters, click More. To remove unnecessary filters, click Fewer.
  9. Click Test to try the filter.
  10. Click OK.

8.2.3.2. Creating a Filtered Role through the Command Line

Roles inherit from the ldapsubentry object class, which is defined in the ITU X.509 standard. In addition, each filtered role requires two object classes that inherit from the nsRoleDefinition object class:
  • nsComplexRoleDefinition
  • nsFilteredRoleDefinition
A filtered role entry also requires the nsRoleFilter attribute to define the LDAP filter to determine role members. Optionally, the role can take a description attribute.
Members of a filtered role are entries that match the filter specified in the nsRoleFilter attribute.
This example creates a filtered role which is applied to all sales managers.
  1. Run ldapmodify with the -a option to add a new entry.
  2. Create the filtered role entry.
    The role entry has the nsFilteredRoleDefinition object class, which inherits from the LdapSubEntry, nsRoleDefinition, and nsComplexRoleDefinition object classes.
    The nsRoleFilter attribute sets a filter for o (organization) attributes that contain a value of sales managers. 
    dn: cn=SalesManagerFilter,ou=people,dc=example,dc=com
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: SalesManagerFilter
nsRoleFilter: o=sales managers
Description: filtered role for sales managers
The following entry matches the filter (possesses the o attribute with the value sales managers), and, therefore, it is a member of this filtered role automatically: 
dn: cn=Pat Smith,ou=people,dc=example,dc=com
objectclass: person
cn: Pat
sn: Smith
userPassword: secret
o: sales managers

8.2.4. Creating a Nested Role

Nested roles are roles that contain other roles. Before it is possible to create a nested role, another role must exist. When a nested role is created, the Console displays a list of the roles available for nesting. The roles nested within the nested role are specified using the nsRoleDN attribute.

8.2.4.1. Creating a Nested Role in the Console

  1. In the Directory Server Console, select the Directory tab.
  2. Browse the tree in the left navigation pane, and select the parent entry for the new role.
  3. Go to the Object menu, and select New > Role.
    Alternatively, right-click the entry and select New > Role.
  4. Click General in the left pane. Type a name for the new role in the Role Name field. The role name is required.
  5. Click Members in the left pane.
  6. In the right pane, select Nested Role.
  7. Click Add to add roles to the list. The members of the nested role are members of other existing roles.
  8. Select a role from the Available roles list, and click OK.

8.2.4.2. Creating Nested Role through the Command Line

Roles inherit from the ldapsubentry object class, which is defined in the ITU X.509 standard. In addition, each nested role requires two object classes that inherit from the nsRoleDefinition object class:
  • nsComplexRoleDefinition
  • nsNestedRoleDefinition
A nested role entry also requires the nsRoleDN attribute to identify the roles to nest within the container role. Optionally, the role can take a description attribute.
Members of a nested role are members of the roles specified in the nsRoleDN attributes of the nested role definition entry.
This example creates a single role out of the managed marketing role and filtered sales manager role.
  1. Run ldapmodify with the -a option to add a new entry.
  2. Create the nested role entry. The nested role has four object classes:
    • nsNestedRoleDefinition
    • LDAPsubentry (inherited)
    • nsRoleDefinition (inherited)
    • nsComplexRoleDefinition (inherited)
    The nsRoleDN attributes contain the DNs for both the marketing managed role and the sales managers filtered role. 
    dn: cn=MarketingSales,ou=people,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsNestedRoleDefinition
cn: MarketingSales
nsRoleDN: cn=SalesManagerFilter,ou=people,dc=example,dc=com
nsRoleDN: cn=Marketing,ou=people,dc=example,dc=com
Both of the users in the previous examples, Bob and Pat, are members of this new nested role.

8.2.5. Editing and Assigning Roles to an Entry

The entries which belong to a role are assigned on the role entry itself. For managed roles, user entries are added explicitly; for filtered roles, they are added through the results of an LDAP filter.
User entries are assigned to the role through the command line by editing the role entry, either by adding the entry as a member or adjusting the filter so it is included. In the Directory Server Console, however, there is a shortcut to add entries to a role by apparently editing the required user entry (but, functionally, this really edits the role entry).
  1. Select the Directory tab.
  2. In the left navigation pane, browse the tree, and select the entry for which to view or edit a role.
  3. Select Set Roles from the Object menu.
  4. Select the Managed Roles tab to display the managed roles to which this entry belongs.
  5. To add a new managed role, click Add, and select an available role from the Role Selector window.

    Note

    The configuration for a managed role associated with an entry can be edited by clicking the Edit button. The Edit Entry dialog box opens, and the general information or members for the role can be changed.
  6. Select the Other Roles tab to view the filtered or nested roles to which this entry belongs.
    Click Edit to make changes to any filtered or nested roles associated with the entry.

8.2.6. Viewing Roles for an Entry through the Command Line

Role assignments are always visible for an entry when it is displayed in the Directory Server Console. Role assignments are not returned automatically through the command line, however.
The nsRole attribute is an operational attribute. In LDAP, operational attributes must be requested explicitly. They are not returned by default with the regular attributes in the schema of the entry. You can either explicitly request single operational attributes by listing them or use + to output all operational attributes for result objects. For example, this ldapsearch command returns the list of roles of which uid=scarter is a member, in addition to the regular attributes for the entry: 
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(uid=scarter)" \* nsRole  

 dn: uid=scarter,ou=people,dc=example,dc=com
 objectClass: inetorgperson
 objectClass: top
 objectClass: person
 objectClass: organizationalPerson
 uid: scarter
 cn: Sam Carter
 sn: Carter
 givenName: Sam
 mail: scarter@example.com
 userPassword: {SSHA}6BE31mhTfcYyIQF60kWlnEL8sIvPZ59hvFTRKw==
 manager: uid=lbrown,ou=people,dc=example,dc=com
 nsRole: cn=Role for Managers,dc=example,dc=com  
 nsRole: cn=Role for Accounting,dc=example,dc=com  

Important

Be sure to use the nsRole attribute, not the nsRoleDN attribute, to evaluate role membership.

8.2.7. Making a Role Inactive or Active

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.
Members of a role can be temporarily disabled by inactivating the role to which they belong. Inactivating a role inactivates the entries possessed by the role, not the role itself.
  1. Select the Directory tab.
  2. Browse the navigation tree in the left pane to locate the base DN for the role. Roles appear in the right pane with other entries.
  3. Double-click the role, open the Account tab, and click the Inactivate button.
    Alternatively, select the role. Right-click the role and select Inactivate from the menu.
The role is inactivated.
To reactivate a disabled role, re-open the role configuration or open the Object menu, and select Activate. All of the members of the role are re-enabled.

8.2.8. Viewing the Activation Status for Entries

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.
The Directory Server Console automatically shows the active or inactive status of entries.
To see the inactivated entries, select Inactivation State from the View menu. Members of an inactivated role have a red slash through them. For example, John Smith is a member of the inactive Example Role.
The nsAccountLock attribute is an operational attribute and must be explicitly requested in the search command in the list of search attributes or specify + to request all operational attributes. For example: 
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(uid=scarter)" nsAccountLock

8.2.9. About Deleting Roles

Deleting a role deletes the role entry but does not delete the nsRoleDN attribute for each role member. To delete the nsRoleDN attribute for each role member, enable the Referential Integrity plug-in, and configure it to manage the nsRoleDN attribute. For more information on the Referential Integrity plug-in, see Chapter 5, Maintaining Referential Integrity.

8.2.10. Using Roles Securely

Not every role is suitable for use in a security context. When creating a new role, consider how easily the role can be assigned to and removed from an entry. Sometimes it is appropriate for users to be able to add or remove themselves easily from a role. For example, if there is an interest group role called Mountain Biking, interested users should be able to add themselves or remove themselves easily.
However, it is inappropriate to have such open roles for some security situations. One potential security risk is inactivating user accounts by inactivating roles. Inactive roles have special ACIs defined for their suffix. If an administrator allows users to add and remove themselves from roles freely, then in some circumstance, they may be able to remove themselves from an inactive role to prevent their accounts from being locked.
For example, user A possesses the managed role, MR. The MR role has been locked using account inactivation. This means that user A cannot bind to the server because the nsAccountLock attribute is computed as true for that user. However, if user A was already bound to Directory Server and noticed that he is now locked through the MR role, the user can remove the nsRoleDN attribute from his entry and unlock himself if there are no ACIs preventing him.
To prevent users from removing the nsRoleDN attribute, use the following ACIs depending upon the type of role being used.
  • Managed roles. For entries that are members of a managed role, use the following ACI to prevent users from unlocking themselves by removing the appropriate nsRoleDN: 
    aci: (targetattr="nsRoleDN") (targetattrfilters= add=nsRoleDN:(!(nsRoleDN=cn=AdministratorRole,dc=example,dc=com)), del=nsRoleDN:(!(nsRoleDN=cn=nsManagedDisabledRole,dc=example,dc=com))) (version3.0;acl "allow mod of nsRoleDN by self but not to critical values"; allow(write) userdn=ldap:///self;)
  • Filtered roles. The attributes that are part of the filter should be protected so that the user cannot relinquish the filtered role by modifying an attribute. The user should not be allowed to add, delete, or modify the attribute used by the filtered role. If the value of the filter attribute is computed, then all attributes that can modify the value of the filter attribute should be protected in the same way.
  • Nested roles. A nested role is comprised of filtered and managed roles, so both ACIs should be considered for modifying the attributes (nsRoleDN or something else) of the roles that comprise the nested role.
For more information about account inactivation, see Section 19.15, “Manually Inactivating Users and Roles”.