Using Roles Securely - Red Hat DIRECTORY SERVER 8.0 - ADMINISTRATION Administration Manual

Chapter 5. Managing Entries with Roles, Classes of Service, and Views
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,ou=people,dc=example,dc=com
objectclass: person
cn: Pat
sn: Pat
userPassword: bigsecret
o: sales managers
5.1.3.3. Example: Nested Role Definition
The Example Corporation administrator is creating a nested role that contains both the marketing staff
and sales managers who are members of the roles marketing managed role and the sales filtered role.
1. Run ldapmodify with the -a option to add a new entry:
ldapmodify -a -D "cn=Directory Manager" -w secret -h host -p 389
2. Create the nested role entry. The nested role has the the nsNestedRoleDefinition
object class, which inherits from the LDAPsubentry, nsRoleDefinition, and
nsComplexRoleDefinition object classes. 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, would be members of this new nested role.

5.1.4. 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, 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.
120