Legacy Mode Administrative Roles

In Access Manager Legacy mode, delegated administration of the LDAP entries (mapped to each identity-related object in Access Manager) are implemented through the use of pre-defined roles and access control instructions (ACIs). Default administrative roles and their defined ACIs are created during Access Manager installation and can be viewed and managed using the Access Manager Console. In Access Manager 7.1 in Realm mode, roles depend on policies rather then ACIs.

When an Access Manager identity-related object is created, the appropriate administrative roles (and thus, corresponding ACIs) are also created and assigned to the LDAP entry for that object. The role can then be assigned to an individual user who maintains control of that object’s node. For example, when Access Manager creates a new organization, several roles are automatically created for it and stored in Directory Server:

• Organization Administrator has read and write access to all entries in the configured organization.

• Organization Help Desk Administrator has read access to all entries in the configured organization and write access to the userPassword attribute in those entries.

• Organization Policy Administrator has read and write access to all policies in the organization.

The assignation of any of these roles to a user gives that user all the permissions accorded that role.

The following table summarizes the Access Manager administrator roles and the permissions that apply to each one.

Table 3–2 Default and Dynamic Roles and Their Permissions in Legacy Mode

Role	Administrative Suffix	Permissions
Top-level Organization Admin (amadmin)	Root level	Read and write access to all entries (such as roles, policy, and groups) under top-level organization.
Top-level Organization Help Desk Admin	Root level	Read and write access to all passwords under top-level organization.
Top-level Organization Policy Admin	Root level	Read and write access to policies at all levels. Used by sub-organizations to delegate referral policy creation.
Organization Admin	Organization only	Read and write access to all entries (such as roles, policy, and groups) under the created sub-organization only.
Organization Help Desk Admin	Organization only	Read and write access to all passwords under the created sub-organization only.
Organization Policy Admin	Organization only	Read and write access to all policies under the created sub-organization only.
Container Admin	Container only	Read and write access to all entries (such as roles, policy, and groups) under the created container only.
Container Help Desk Admin	Container only	Read and write access to all passwords under the created container only.
Group Admin	Group only	Read and write access to all entries (such as roles, policy, and groups) under the created group only.
People Container Admin	People Container only	Read and write access to all entries (such as roles, policy, and groups) under the created people container only.
User (self-administrator)	User only	Read and write access to attributes in the user entry only (except for user attributes such as nsroledn and inetuserstatus).

Using roles instead of group-based ACIs is more efficient and requires less maintenance. Filtered roles are simpler for LDAP clients, because they can just ask for the nsRole attribute of a user. Roles do suffer though from scope limitations, where a role must be a peer of a parent of a member of that role.

For more information about default ACIs, see the Access Manager Console Online Help.