Red Hat Directory Server 8.0 Administrator's Guide

users to be able to adder 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, in some security contexts, it is inappropriate to have such open roles. Consider
account inactivation roles. By default, account inactivation roles contain ACIs defined for their
suffix. When creating a role, the server administrator decides whether a user can assign
themselves to or remove themselves from the role.
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, suppose the user was
already bound and noticed that he is now locked through the MR role. If there are no ACIs
preventing him, the user can remove the nsRoleDN attribute from his entry and unlock himself.
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") (targattrfilters=
add=nsRoleDN:(!(nsRoleDN=cn=AdministratorRole,
dc=example,dc=com)),
del=nsRoleDN:(!(nsRoleDN=cn=nsManagedDisabledRole,dc=example,dc=com)))
(version3.0;aci 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 the above points
should be considered for each of the roles that comprise the nested role.
For more information about account inactivation, see Section 2, “Inactivating Users and Roles”.
2. Assigning Class of Service
A Class of Service definition (CoS) shares attributes between entries in a way that is
transparent to applications. CoS simplifies entry management and reduces storage
requirements.
Assigning Class of Service
143