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

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.
However, 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 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.
NOTE:
The nsRole attribute is an operational attribute. In LDAP, operational attributes must be requested
explicitly in the search attributes list; they are not returned by default with the regular attributes in
the schema of the entry. 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 ... args ... “(uid=scarter)” \* nsRole
Be sure to use the nsRole attribute, not the nsRoleDN attribute, to evaluate role membership.
The Console will automatically show the roles.
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.
For more information about how roles work, see the HP-UX Directory Server deployment guide.
The concept of activating and 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.
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.
NOTE:
The nsAccountLock attribute is an operational attribute and must be explicitly requested in the
search command in the list of search attributes. For example:
ldapsearch ... args ... “(uid=scarter)” \* nsAccountLock
The Console will automatically show the active or inactive status of entries.
5.1 Using roles 167