# OpenAM Administration Guide
Chapter 20. Securing OpenAM

Sidebar | Prev | Up | Next

## 20.5. Administering the amadmin Account

You can make changes to the password and user name for the main OpenAM administrative account.

You can change the user name of the `amadmin` administrative account to something more obscure, such as superroot. However, the capabilities of that alternative administrative account would not be complete, due to some hard-coding of `amadmin` in the source files. When changing the password for the main OpenAM administrative account, you must make a corresponding change to the authentication datastore. That datastore could be OpenDJ. The steps you would take to change the OpenAM top-level administrative password and account name are shown in the following sections.

Procedure 20.1. To Change the Password for the Top-Level Administrator (normally `amadmin`)

1. Login to the OpenAM console as the administrator, normally `amadmin`.

2. Under Access Control > / (Top Level Realm) > Subjects > User, select the name of the current top-level administrative user.

3. In the page that appears, navigate to the Password row and click Edit.

4. In the window that appears, enter the desired new password in the New Password and Re-Enter Password text boxes.

5. Click OK to implement the change. If you want to cancel, click Close or just close the window.

6. You'll also need to change the password for the administrator on the directory server. If you are using OpenDJ, refer to the OpenDJ Administration Guide section on Resetting Administrator Passwords. If you are using a different directory server, you will have to refer to the documentation for that server.

In the following steps, you will identify the new administrative user by assigning it to the `com.sun.identity.authentication.super.user` directive. You may also need to create an OpenAM account for the new administrative user. Don't forget to make sure that new administrative account is configured in the corresponding directory server such as OpenDJ.

Procedure 20.2. To Change the Account Name for the Top-Level Administrator (normally `amadmin`)

1. Login to the OpenAM console as the administrator, normally `amadmin`.

2. Navigate to the page where you can set the properties for different classes. Select Configuration > Servers and Sites > `Server Name` > Advanced.

3. In the Advanced Properties window that appears, click Add.

4. You'll see blank entries in the end of the list of Property Names and Property Values. In the empty Property Name text box, enter `com.sun.identity.authentication.super.user`.

5. In the corresponding Property Values test box, enter appropriate values for the new administrative user in LDAP Data Interchange Format (LDIF). For example, the following entry would set up an administrative user named `superroot`, in the organizational unit named `people`people, associated with the example.com domain: `uid=superroot,ou=people,dc=example,dc=com`.

6. Click Save to save the changes that you've made.

7. If the account doesn't already exist in OpenAM or on a connected directory server, you'll need to create it. To do so, select Access Control > / (Top Level Realm) > Subject > User > New. In the New User window that appears, create the new user. Make sure to enter an appropriate password and make that user Active. The ID for that new user is the user name.

8. As noted earlier, you'll also need to make sure that the corresponding account on the directory server has at least CN=Directory Manager privileges. If you're using OpenDJ, refer to the chapter on Configuring Privileges & Access Control in the OpenDJ Administration Guide.

If you do change the account name of the top-level administrative account, you should be aware that the original `amadmin` account is "hard-coded" in the source code of several files. The code in these files may affect the functionality of a top-level administrative user with a name other than `amadmin`.

One of the improvements that we plan to make to OpenAM is to eliminate these instances of hard-coding. Until we make such improvements, the amadmin user would retain privileges related to the LoginState and some IDM-related classes.