Administrative Users

When assessing the technical requirements for your Access Manager deployment, consider the following administrative users and accounts:

• Access Manager Administrative Roles

• Access Manager Administrative Accounts

• Policy Agent Administrative Users

Access Manager Administrative Roles

• Realm Mode Administrative Roles

• Legacy Mode Administrative Roles

Realm Mode Administrative Roles

In Access Manager Realm mode, the Delegation plug-in works with the Identity Repository plug-in to determine a network administrator's scope of privileges. Default administrator roles are defined in the Identity Repository plug-in. The Delegation plug-in forms rules that describe the scope of privileges for each network administrator, and also specifies the roles to which the rules apply. The following table lists the roles defined in the Identity Repository and the default rule the Delegation plug-in applies to each role.

Table 3–1 Access Manager Roles and Scope of Privileges in Realm Mode

Identity Repository Role	Delegation Rule
Realm Administator	Can access all data in all realms of the Access Manager information tree.
Subrealm Administrator	Can access all data within a specific realm of the Access Manager information tree.
Policy Administrator	Can access all policies in all realms of the Access Manager information tree.
Policy Realm Administrator	Can access policies only within the specific realm of the Access Manager information tree.

The Authentication service and Policy service use the aggregated data to perform the authentication and authorization processes. The code for the Delegation plug-in and Identity Repository plug-in are not public in Access Manager.

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.

Access Manager Administrative Accounts

During the installation of Access Manager, the following administrative accounts are created:

• Administrator user ID (amadmin) is the Access Manager top-level administrator that has unlimited access to all entries managed by Access Manager. You cannot change the default name, amadmin.

  During installation, you must provide a password for amadmin. To change the amadmin password after installation, use the Access Manager Administration Console.

• Bind DN user for LDAP, Membership, and Policy services (amldapuser) is the administrative user that has read and search access to all Directory Server entries. You cannot change the default name, amldapuser.

  During installation, you must provide a password for amldapuser. Do not use the same password that you used for amadmin. To change the amldapuser password after installation, use the Directory Server Console or the ldapmodify utility.

  If you change the amldapuser password, you must also modify the LDAP authentication service and policy configuration services to reflect the change (amldapuser is the default user used in these services). You must make changes in each organization where these services are registered.

• Proxy user (puser) can take on any user's privileges (for example, an organization administrator or end user).

• Admin user (dsameuser) is used for binding purposes when the Access Manager SDK performs operations on Directory Server that are not linked to a particular user (for example, retrieving service configuration information).

Both puser and dsameuser have an associated password that is stored in encrypted format in the serverconfig.xml file, in the following directories:

• Solaris systems: /etc/opt/SUNWam/config

• Linux and HP-UX systems: /etc/opt/sun/identity/config

• Windows systems: javaes-install-dir\identity\config

  The javaes-install-dir variable represents the Java ES 5 installation directory. The default value is C:\Program Files\Sun\JavaES5.

After installation, it is recommended that you change the password for puser and dsameuser, but do not use the same password that you used for amadmin or amldapuser. To change the puser or dsameuser password, use the ampassword utility:

• The ampassword --admin (or -a) option changes the password for dsameuser. (This option does not change the amadmin password.)

• The ampassword --proxy (or -p) option changes the password for puser.

Changing the puser or dsameuser password depends on your deployment.

If Access Manager is deployed on a single host server:

1. Use the ampassword utility to change the respective password in Directory Server and in the local serverconfig.xml file.

2. Restart the Access Manager web container.

If Access Manager is deployed on multiple host servers:

1. On the first server, use the ampassword utility to change the respective password in Directory Server and in the local serverconfig.xml file.

2. Encrypt the new password using the ampassword --encrypt (or -e) option.

3. On each additional server where Access Manager is deployed, change the password manually in the serverconfig.xml file, using the new encrypted password from Step 2.

4. On each server where you changed the password, including the first server, restart the Access Manager web container.

For information about the ampassword utility, see the Sun Java System Access Manager 7.1 Administration Reference.

Policy Agent Administrative Users

A Policy Agent in the Access Manager Policy Agent 2.2 software set authenticates to Access Manager using a user name and password stored in its AMAgent.properties file. The process is similar but slightly different for Web Agents and J2EE Agents.

Web Agents

A Web Agent uses the following properties in the AMAgent.properties file to store its user name and password used to authenticate to Access Manager:

• com.sun.am.policy.am.username contains the name of the user that the Web Agent uses to login to Access Manager. The default name is UrlAccessAgent.

• com.sun.am.policy.am.password contains the encrypted password of the user that the Web Agent uses to login to Access Manager. The password must be encrypted using the crypt_util utility.

When an Access Manager instance is initially configured, the Java ES installer or the amconfig script creates the amService-UrlAccessAgent user in the top-level realm with the same password as the amldapuser user.

By default, all Web Agents use the same user name and password to authenticate to an Access Manager instance. To improve security and to allow each Web Agent to use a unique name and password, you can create an agent profile in the Access Manager Administration Console for a Web Agent to use for authentication. For more information, see Using an Agent Profile for Authentication.

J2EE Agents

A J2EE Agent communicates with Access Manager with a user name (agent ID) and password through an agent profile created in the Access Manager Administration Console. After the agent profile is created, the J2EE Agent then uses the following properties in its AMAgent.properties file to store the user name (agent ID) and password:

• com.sun.identity.agents.app.username contains the user name (agent ID) that the J2EE Agent uses to login to Access Manager.

• com.iplanet.am.service.secret contains the encrypted password of the user name (agent ID) that the J2EE Agent uses to login to Access Manager. The password must be encrypted using the agentadmin utility with the --encrypt option.

See the next section for information about agent profiles.

Using an Agent Profile for Authentication

To authenticate to Access Manager, a J2EE Agent requires that you create an agent profile in the Access Manager Administration Console. A Web Agent can also use an agent profile, which allows each Web Agent to have a unique user name (agent ID) and password. For the steps to create an agent profile, see the Access Manager Console online Help.

An agent profile also allows you to change the password and user name (agent ID) for a Policy Agent, as required by your deployment. To change a password and user name (if required), follow these general steps:

1. Log in to the Access Manager Console as the Access Manager administrator (amadmin).

2. In the agent profile for the Policy Agent, change the password and user name (agent ID), if required. Save the profile.

3. Encrypt the new agent password from Step 2 using the crypt_util utility for Web Agents or the agentadmin utility with the --encrypt option for J2EE Agents.

4. Set the following properties in the Policy Agent's AMAgent.properties file:

   • For Web Agents: Set the com.sun.am.policy.am.password property to the new encrypted password from Step 3. If you also changed the user name (agent ID), set the com.sun.am.policy.am.username property to the new user name (agent ID) from Step 2.

   • For J2EE Agents: Set the com.iplanet.am.service.secret property to the new encrypted password from Step 3. If you also changed the user name (agent ID), set the com.sun.identity.agents.app.username property to the new user name (agent ID) from Step 2.

5. Restart the Web Agent web container for the new password (and user name if you changed it) to take effect.

For more detailed information about creating and configuring agent profiles and encrypting passwords, see the Access Manager Policy Agent 2.2 documentation collection:

http://docs.sun.com/coll/1322.1