HP-UX Directory Server 8.1 administrator guide

nsRoleDN: cn=SalesManagerFilter,ou=people,dc=example,dc=com
nsRoleDN: cn=Marketing,ou=people,dc=example,dc=com
Both the users in the previous examples, Bob and Pat, are 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 roles for some security situations.
One potential security risk is inactivating user accounts by inactivating 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 users can remove the nsRoleDN
attribute from their entry and unlock themselves if there are no ACIs preventing them.
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 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 “Inactivating users and roles”.
5.2 Assigning class of service
A class of service (CoS) definition shares attributes between entries in a way that is transparent
to applications. CoS simplifies entry management and reduces storage requirements.
• “About CoS”
• “Managing CoS using the console”
• “Managing CoS from the command line”
• “Creating role-based attributes”
• “Access control and CoS”
5.2 Assigning class of service 187