HP-UX Directory Server Administrator Guide HP-UX Directory Server Version 8.1 (5900-3098, May 2013)

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” (page 301).
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” (page 188)
• “Managing CoS using the console” (page 192)
• “Managing CoS from the command line” (page 204)
• “Creating role-based attributes” (page 209)
• “Access control and CoS” (page 210)
5.2 Assigning class of service 187