--- title: Secure administrative access description: Some deployments may need only one administrator. For example, deployments whose configuration never changes in production. If your deployment requires more than one administrative user, it makes sense to limit what individual administrators can do. component: pingam version: 8.1 page_id: pingam:security:securing-administration canonical_url: https://docs.pingidentity.com/pingam/8.1/security/securing-administration.html keywords: ["Security", "Setup & Configuration", "Identities"] page_aliases: ["security-guide:securing-administration.adoc"] section_ids: securing-admin-users: The amAdmin user amadmin-password-console: Change the amAdmin password amadmin-password-secret-store: Store the amAdmin password in a secret store delegating-realm-administration-privileges: Delegate privileges delegate-privileges-ui: Delegate privileges in the UI delegate-privileges-rest: Delegate privileges over REST delegate-realm-administration-revoke-sessions: Let delegated subrealm administrators invalidate sessions delegate-agent-profile-creation: Delegate agent profile creation securing-admin-console: Secure access to the admin UIs securing-tools: Secure access to Amster --- # Secure administrative access Some deployments may need only one administrator. For example, deployments whose configuration never changes in production. If your deployment requires more than one administrative user, it makes sense to limit what individual administrators can do. This approach reduces the risk of accidental or intentional abuse of power, and lets you divide work between different teams and audit configuration changes. To secure administrative access to AM make sure you: * Understand and secure the `amAdmin` user. * Know how to delegate realm privileges to groups of users. * Secure access to the AM admin UI. * Secure access to the tools you use to configure AM. ## The `amAdmin` user The AM installation process creates an `amAdmin` administrative account. This account has unrestricted access to the AM configuration, including the ability to create new users and augment their list of administrative privileges. You can't delete the `amAdmin` account because it's hard-coded in the source code of several files. The `amAdmin` user is defined in AM's configuration, so it's always available to AM even if the identity stores become unavailable. Because this account isn't an *identity* defined in an identity store, it can't use any capabilities that require a user profile, such as device match or push notifications. The advanced server property `com.sun.identity.authentication.super.user` defines the DN of the `amAdmin` user. You can change this property to the DN of a regular user that exists in any identity store configured in AM. | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Changing the name of the `amAdmin` user might affect functionality in some areas where the name is hardcoded. Make sure you test a change like this before deploying it in production. | Secure the `amAdmin` user with a strong password and restrict its use as much as possible. [Delegate realm administration privileges](#delegating-realm-administration-privileges) to regular users instead. ### Change the amAdmin password This topic describes how to use the AM admin UI to change the `amAdmin` user. | | | | - | ----------------------------------------------------------------------------------------------------------------------------------- | | | A better way to secure the `amAdmin` password is to [Store the amAdmin password in a secret store](#amadmin-password-secret-store). | Follow these steps to change the `amAdmin` password: 1. In the AM admin UI, click on the user avatar ([icon: user-circle, set=fa]) in the top right corner. 2. Click Change Password. 3. Enter the current password in the Current password field. 4. Enter the new password in the New password and Confirm new password fields. 5. Save your work. If your deployment has multiple AM servers, the new password replicates across all servers. ### Store the amAdmin password in a secret store Using a secure secret store is more secure than storing the `amAdmin` password in the configuration. | | | | - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | * The secret store you use for the `amAdmin` password is a special secret store and isn't visible in the AM admin UI. If you store the `amAdmin` password in a secret store, you can't change the password in the AM admin UI unless you remove the secret configuration. * When you remove the secret configuration, the `amAdmin` password reverts to what it was before you configured the secret. * You *must* salt and hash an `amAdmin` password stored in a secret. Encryption is optional but *highly recommended*. | To store the `amAdmin` password in a secret store: 1. Create a new password then salt and hash it using a script similar to the following. The comments in the script indicate the salt and hash requirements: ```python #!/usr/bin/env python3 import getpass import os import sys import struct import hashlib import base64 if os.isatty(0): pwd = getpass.getpass() cnf = getpass.getpass('Confirm: ') else: pwd = sys.stdin.buffer.readline().decode('utf-8').strip() cnf = pwd if pwd != cnf: sys.exit("Password and confirmation don't match") ## Create some random bytes as the salt salt = os.urandom(20) ## Hash the salt and the new password with a SHA-512 function h = hashlib.sha512() h.update(salt) h.update(pwd.encode('utf-8')) hash = h.digest() ## Concatenate the salt length as a single byte, the raw salt, and the hashed password packed = struct.pack("B20s64s", 20, salt, hash) ## Generate the final hashed string outform = "{SSHA-512}" + base64.b64encode(packed).decode('ascii') print(outform) ``` 2. Optionally, encrypt the hashed string with the AM encryption password or with a secret stored in the Google Cloud Key Management Service (KMS). * Encrypt with the AM encryption password: 1. Log in to the AM admin UI as an administrative user. 2. Go to `https://am.example.com:8443/am/encode.jsp` and paste the hashed string in the field. Copy the encrypted password string. 3. Go to Configure > Server Defaults > Advanced. 4. Set the `org.forgerock.openam.secrets.special.user.passwords.format` advanced server property to `ENCRYPTED_PLAIN`. * Encrypt with a secret stored in the Google Cloud KMS: > **Collapse: Prerequisites** > > You need a Google Cloud Platform account with a project that includes the following: > > * A key ring containing the secrets that you'll use to encrypt the hash of the password of the `amAdmin` user. > > You can configure the key ring in any Google Cloud location. > > * A service account that AM will use to connect to the project. > > Learn more in the [Google Key Management Service documentation](https://cloud.google.com/kms/docs) and Google's [Getting Started with Authentication](https://cloud.google.com/docs/authentication/getting-started). > > You can find information on configuring AM to connect to the Google Cloud KMS with the service account in [Configure Google service account credentials](secret-stores.html#configuring-google-api-credentials). 1. Check if you already have a Google Cloud KMS secret for decrypting. Go to Configure > Server Defaults > Advanced, and check if the `org.forgerock.openam.secrets.googlekms.decryptionkey` advanced server property is configured. If the property is configured, you don't need to create another key. If the property isn't configured, log in to your Google Cloud dashboard and create a secret of one of the following types in the key ring of your choosing: * Symmetric encrypt/decrypt * Asymmetric decrypt 2. Use the secret you identified or created in the previous step to encrypt the hashed string. You can use the `gcloud` tool included in Google Cloud's SDK to encrypt the string. The tool creates a binary file with the encrypted secret, but AM doesn't support secrets in binary format. To work around this, base64-encode the encrypted secret. For example: ```bash gcloud kms encrypt \ --plaintext-file=./amadmin_password_hashed_string.txt \ --ciphertext-file=- \ --project=my_project_ID \ --location=my_location \ --keyring=my_keyring_for_AM \ --key=my_key_for_decrypting_secrets_in_AM \| base64 > encrypted_hash_of_amadmin_password.enc ``` 3. In the AM admin UI, go to Configure > Server Defaults > Advanced. 4. (Optional) If unset, set the `org.forgerock.openam.secrets.googlekms.decryptionkey` advanced server property to the fully qualified resource ID of the Google Cloud KMS secret that you used to encrypt the hash string. For example: ```none projects/my_project_ID/locations/my_location/keyRings/my_keyring_for_AM/cryptoKeys/my_key_for_decrypting_secrets_in_AM ``` Learn how to find the key ID in [Object Hierarchy](https://cloud.google.com/kms/docs/object-hierarchy#key_resource_id) in the Google Cloud KMS documentation. 5. Set the `org.forgerock.openam.secrets.special.user.passwords.format` advanced server property to `GOOGLE_KMS_ENCRYPTED`. * Leave the hashed string unencrypted (not recommended) | | | | - | -------------------------------------------------------------------------------------- | | | Ensure that the password is randomly generated and has high entropy before continuing. | 1. In the AM admin UI, go to Configure > Server Defaults > Advanced. 2. Set the `org.forgerock.openam.secrets.special.user.passwords.format` advanced server property to `PLAIN`. | | | | - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | If you don't have access to the AM admin UI, you can add the required property to the `CATALINA_OPTS` variable. For example, for Apache Tomcat, add the following to the `$CATALINA_BASE/bin/setenv.sh` file:```bash export CATALINA_OPTS="$CATALINA_OPTS -Dorg.forgerock.openam.secrets.special.user.passwords.format=PLAIN" ``` | 3. Map the encrypted secret to the secret label that you'll use. Perform one of the following: * Save the encrypted password to a file in the special secret store directory: ```bash $ echo -n salted_encrypted_password > /path/to/am/security/secrets/userpasswords/password.amadmin ``` | | | | - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The default location of the special secret store is `/path/to/am/security/secrets/userpasswords`. To change it, configure the `org.forgerock.openam.secrets.special.user.passwords.dir` advanced server property. | * Create an operating system variable named `PASSWORD_AMADMIN` and set its value to the encrypted password. Make the variable available to the user running the container where AM runs; for example, add it to the user's `bash.profile` file. * Create a Java system variable called `password.amadmin` and set its value to the encrypted password. Make the variable available to the container where AM runs. For example, if using Apache Tomcat, add it to `$CATALINA_BASE/bin/setenv.sh` as follows: ```bash export password.amadmin="y3GVzNP5Z3$EXZQHX75aRE!8FjN" ``` AM caches this special secret after it's been read. The expiry time of the cache is 900 seconds (15 minutes) by default. To change the expiry time, set the [org.forgerock.openam.secrets.special.user.secret.refresh.seconds](../setup/server-advanced.html#secrets.special.user.secret.refresh.seconds) advanced server property. For increased security, rotate this secret periodically. Learn more in [Map and rotate secrets](secret-mapping.html). ## Delegate privileges The `amAdmin` user can change any setting in AM's configuration, but giving that power to each of your administrative users isn't ideal. In AM, you don't create administrative users. You create regular users and delegate realm administration privileges to a group they belong to. For example, you can create a group of users that are only allowed to make REST calls to endpoints in a specific realm, or a group of users that have full administrative privileges for a particular realm. This approach of splitting responsibilities lowers the risk of accidental or intentional abuse. Because users with delegated administration privileges are regular users in the identity store, they can use any form of multi-factor authentication. You can also delegate other kinds of privileges, such as making REST calls to realms for policy evaluation, modifying policies, and more. > **Collapse: Realm privileges available for delegation** > > The following table describes the privileges you can assign in the AM admin UI or using REST: > > | Privilege in the AM admin UI | Option to use over REST | Description | > | ------------------------------ | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | > | Entitlement Rest Access | `EntitlementRestAccess` | REST calls for policy evaluationSubset of the `Realm Admin` and `Policy Admin` privileges. | > | Application Read Access | `ApplicationReadAccess` | REST calls for reading policy applicationsSubset of the `Realm Admin` and `Policy Admin` privileges. | > | Resource Type Read Access | `ResourceTypeReadAccess` | REST calls for reading policy resource typesSubset of the `Realm Admin` and `Policy Admin` privileges. | > | Privilege Rest Read Access | `PrivilegeRestReadAccess` | REST calls for reading policiesSubset of the `Realm Admin` and `Policy Admin` privileges. | > | Application Types Read Access | `ApplicationTypesReadAccess` | REST calls for reading policy application typesSubset of the `Realm Admin` and `Policy Admin` privileges. | > | Subject Attributes Read Access | `SubjectAttributesReadAccess` | REST calls for reading subject attributesSubset of the `Realm Admin` and `Policy Admin` privileges. | > | Agent Admin | `AgentAdmin` | Read and write access to all configured agentsProvides access to centralized agent configuration.Subset of the `Realm Admin` privilege. | > | Policy Admin | `PolicyAdmin` | Read and write access only for policy properties, including REST callsAssign this privilege to policy administrators in order to let them modify or read any part of the AM policy configuration.This privilege lets an administrator modify or read all policy components: policies, applications, subject types, condition types, subject attributes, and decision combiners. All other AM privileges that affect policy components are included with this privilege.Subset of the `Realm Admin` privilege. | > | Log Read | `LogRead` | Read access to all log filesSubset of the `Realm Admin` privilege. | > | Subject Types Read Access | `SubjectTypesReadAccess` | REST calls for reading subject conditionsSubset of the `Realm Admin` and `Policy Admin` privileges. | > | Cache Admin | `CacheAdmin` | Read and write access to manipulate the cache | > | Condition Types Read Access | `ConditionTypesReadAccess` | REST calls for reading environment conditionsSubset of the `Realm Admin` and `Policy Admin` privileges. | > | Log Write | `LogWrite` | Write access to all log filesSubset of the `Realm Admin` privilege. | > | Session Property Modify Access | `SessionPropertyModifyAccess` | REST calls for modifying session propertiesSubset of the `Realm Admin` and `Policy Admin` privileges. | > | Federation Admin | `FederationAdmin` | Read and write access to all federation metadata configurationsSubset of the `Realm Admin` privilege. | > | Privilege Rest Access | `PrivilegeRestAccess` | REST calls for managing policiesSubset of the `Realm Admin` and `Policy Admin` privileges. | > | Log Admin | `LogAdmin` | Read and write access to all log filesSubset of the `Realm Admin` privilege. | > | Realm Read Access | `RealmReadAccess` | REST calls for reading realmsSubset of the `Realm Admin` privilege. | > | Realm Admin | `RealmAdmin` | Read and write access to all realm and policy propertiesAssign this privilege to administrators in order to let them modify or read any part of an AM realm.Use this privilege when you don't require granularity in your delegation model. All other AM privileges are included with this privilege. Administrators using the AM admin UI must have this privilege. | > | Application Modify Access | `ApplicationModifyAccess` | REST calls for modifying policy applicationsSubset of the `Realm Admin` and `Policy Admin` privileges. | > | Resource Type Modify Access | `ResourceTypeModifyAccess` | REST calls for modifying policy resource typesSubset of the `Realm Admin` and `Policy Admin` privileges. | > | Decision Combiners Read Access | `DecisionCombinersReadAccess` | REST calls for reading decision combinersSubset of the `Realm Admin` and `Policy Admin` privileges. | ### Delegate privileges in the UI These steps describe how to create a user and assign administrative privileges using the AM admin UI. You can also delegate privileges over [REST](#delegate-privileges-rest). 1. Go to the realm for which you want to delegate privileges. For example, go to Realms > Top Level Realm. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | Delegating *administrative* privileges in the Top Level Realm allows members of the group full access to the AM instance. Administration privileges in any other realm allows the group to access administrative functionality only in that realm, and any child realms. | 2. Go to Identities > Groups and click the name of the group to which you intend to grant access. If you don't have a group yet, create one. The All Authenticated Identities virtual group lets you assign privileges to any identity that has a valid session in AM. Use it with caution, since not every identity authenticates to AM by using strong authentication. 3. Choose the administrative privileges to delegate for the realm: 1. To grant users in the group access to the AM admin UI for the realm, click Realm Admin. Administrators can use the AM admin UI as follows: * Delegated administrators with the `Realm Admin` privilege can access full administration console functionality within the realms they can administer. * Users with lesser privileges, such as the `Policy Admin` privilege, can't access the AM admin UI, but can use REST to create and manage the functionality for which they have privileges. * Both the top-level administrator (such as `amAdmin`) and delegated administrators in the Top Level Realm with the `Realm Admin` privilege have access to full console functionality in all realms and can access AM's global configuration. 2. To grant users in the group access to REST endpoints, choose the required privileges from the list. Learn more about the available privileges in [Realm privileges available for delegation](#realm-privileges-delegation-ref). 4. Click Save Changes. To enable delegated subrealm administrators to invalidate sessions, you must add an attribute to their entry in the datastore, as described in [Let delegated subrealm administrators invalidate sessions](#delegate-realm-administration-revoke-sessions). ### Delegate privileges over REST These steps describe how to create a user and assign administrative privileges to a group in the `alpha` realm using REST. You can also delegate privileges in the [AM admin UI](#delegate-privileges-ui). 1. Authenticate as an administrative user. For example: ```bash $ curl \ --request POST \ --header "Content-Type: application/json" \ --header "X-OpenAM-Username: amadmin" \ --header "X-OpenAM-Password: password" \ --header "Accept-API-Version: resource=2.0, protocol=1.0" \ 'https://am.example.com:8443/am/json/realms/root/authenticate' { "tokenId":"AQIC5wM…​TU3OQ*", "successUrl":"/am/console", "realm":"/alpha" } ``` 2. Create the user who you want to make an admin user if they don't already exist. For example: ```bash $ curl \ --request POST \ --header "iPlanetDirectoryPro: AQIC5wM…​TU3OQ*" \ --header "Content-Type: application/json" \ --header "Accept-API-Version: protocol=2.1,resource=3.0" \ --data '{ "username": "newAdmin", "realm": "/alpha", "userpassword": "Ch4ng31t", "mail": "new.admin@example.com" }' \ 'https://am.example.com:8443/am/json/realms/root/realms/alpha/users/?_action=create' { "_id": "newAdmin", "_rev": "-1", "realm": "/alpha", "username": "newAdmin", "uid": [ "newAdmin" ], "mail": [ "new.admin@example.com" ], "universalid": [ "id=newAdmin,ou=user,o=alpha,ou=services,ou=am-config" ], ... } ``` 3. Create a new group for this type of admin user. For example: ```bash $ curl \ --request POST \ --header "iPlanetDirectoryPro: AQIC5wM…​TU3OQ*" \ --header "Content-Type: application/json" \ --header "Accept-API-Version: resource=1.0" \ --data '{ "username":"newAdminGroup" }' \ 'https://am.example.com:8443/am/json/realms/root/realms/alpha/groups/?_action=create' { "_id": "newAdminGroup", "_rev": "-1", "realm": "/alpha", "username": "newAdminGroup", "universalid": [ "id=newAdminGroup,ou=group,o=alpha,ou=services,ou=am-config" ], "dn": [ "cn=newAdminGroup,ou=groups,ou=identities" ], "cn": [ "newAdminGroup" ], "objectclass": [ "top", "groupofuniquenames" ] } ``` 4. Add your admin user to this new group ensuring you use the appropriate attribute for your identity store. For example, if you use DS, specify the user using the `uniqueMember` attribute: ```bash $ curl \ --request PUT \ --header "iPlanetDirectoryPro: AQIC5wM…​TU3OQ*" \ --header "Content-Type: application/json" \ --header "Accept-API-Version: resource=3.0" \ --data '{ "uniqueMember":[ "uid=newAdmin,ou=user,o=alpha,ou=services,ou=am-config" ] }' \ 'https://am.example.com:8443/am/json/realms/root/realms/alpha/groups/newAdminGroup' { "_id": "newAdminGroup", "_rev": "-1", "realm": "/alpha", "username": "newAdminGroup", "universalid": [ "id=newAdminGroup,ou=group,o=alpha,ou=services,ou=am-config" ], "dn": [ "cn=newAdminGroup,ou=groups,ou=identities" ], "cn": [ "newAdminGroup" ], "uniqueMember": [ "uid=newAdmin,ou=user,o=alpha,ou=services,ou=am-config" ], "objectclass": [ "top", "groupofuniquenames" ] } ``` 5. Retrieve details for the new group to obtain a list of possible privileges and the current settings. For example: ```bash $ curl \ --request GET \ --header "iPlanetDirectoryPro: AQIC5wM…​TU3OQ*" \ --header "Content-Type: application/json" \ 'https://am.example.com:8443/am/json/realms/root/realms/alpha/groups/newAdminGroup' { "_id": "newAdminGroup", "_rev": "1146531813", "username": "newAdminGroup", "realm": "/alpha", "universalid": [ "id=newAdminGroup,ou=group,o=alpha,ou=services,ou=am-config" ], "members": { "uniqueMember": [ "newAdmin" ] }, ... "privileges": { "EntitlementRestAccess": false, "ApplicationReadAccess": false, "ResourceTypeReadAccess": false, "PrivilegeRestReadAccess": false, "ApplicationTypesReadAccess": false, "SubjectAttributesReadAccess": false, "AgentAdmin": false, "PolicyAdmin": false, "LogRead": false, "SubjectTypesReadAccess": false, "CacheAdmin": false, "ConditionTypesReadAccess": false, "LogWrite": false, "SessionPropertyModifyAccess": false, "FederationAdmin": false, "PrivilegeRestAccess": false, "LogAdmin": false, "RealmReadAccess": false, "RealmAdmin": false, "ApplicationModifyAccess": false, "ResourceTypeModifyAccess": false, "DecisionCombinersReadAccess": false } } ``` Learn more about the available privileges in [Realm privileges available for delegation](#realm-privileges-delegation-ref). 6. Give this group the required privileges. Use the above output for the data option and set any required privileges to `true`. The following example sets the `RealmAdmin` privilege to `true`: ```bash $ curl \ --request PUT \ --header "iPlanetDirectoryPro: AQIC5wM…​TU3OQ*" \ --header "Content-Type: application/json" \ --header "Accept-API-Version: protocol=2.1,resource=4.0" \ --data '{ "_id": "newAdminGroup", "_rev": "1146531813", "username": "newAdminGroup", "realm": "/alpha", "universalid": [ "id=newAdminGroup,ou=group,o=alpha,ou=services,ou=am-config" ], "members": { "uniqueMember": [ "newAdmin" ] }, "dn": [ "cn=newAdminGroup,ou=groups,ou=identities" ], "cn": [ "newAdminGroup" ], "objectclass": [ "top", "groupofuniquenames" ], "privileges": { "EntitlementRestAccess": false, "ApplicationReadAccess": false, "ResourceTypeReadAccess": false, "PrivilegeRestReadAccess": false, "ApplicationTypesReadAccess": false, "SubjectAttributesReadAccess": false, "AgentAdmin": false, "PolicyAdmin": false, "LogRead": false, "SubjectTypesReadAccess": false, "CacheAdmin": false, "ConditionTypesReadAccess": false, "LogWrite": false, "SessionPropertyModifyAccess": false, "FederationAdmin": false, "PrivilegeRestAccess": false, "LogAdmin": false, "RealmReadAccess": false, "RealmAdmin": true, "ApplicationModifyAccess": false, "ResourceTypeModifyAccess": false, "DecisionCombinersReadAccess": false } }' \ 'https://am.example.com:8443/am/json/realms/root/realms/alpha/groups/newAdminGroup' ``` The response returned is the same as in the previous step but with the updated privileges. To enable delegated subrealm administrators to invalidate sessions, you must add an attribute to their entry in the datastore, as described in [Let delegated subrealm administrators invalidate sessions](#delegate-realm-administration-revoke-sessions). ### Let delegated subrealm administrators invalidate sessions 1. Create an LDIF file that modifies the distinguished name entry of the subrealm administrator, adds the `iplanet-am-session-destroy-sessions` attribute, and sets its value to the subrealm's DN. In the following example, the delegated administrator is named `subRealmAdmin` and the subrealm is called `mySubRealm`: ```ldif dn: uid=subrealmadmin,ou=people,dc=am,dc=example,dc=com changetype: modify add: objectClass objectClass: iplanet-am-session-service - add: iplanet-am-session-destroy-sessions iplanet-am-session-destroy-sessions: o=mysubrealm,ou=services,dc=am,dc=example,dc=com ``` | | | | - | ---------------------------------------------------------------------------------------------- | | | All values in the LDIF must be in lowercase, even if the subrealm or administrator name isn't. | 2. Run the `ldapmodify` command included with DS to apply the LDIF file to the user datastore. For example: ```bash $ /path/to/opendj/bin/ldapmodify \ --hostname 'ds.example.com' \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --truststorepassword:file /path/to/opendj/config/keystore.pin \ --bindDN uid=admin \ --bindPassword str0ngAdm1nPa55word \ /path/to/ldif.file # Processing MODIFY request for uid=subrealmadmin,ou=people,dc=am,dc=example,dc=com # MODIFY operation successful for DN uid=subrealmadmin,ou=people,dc=am,dc=example,dc=com ``` The delegated realm administrator will now be able to invalidate sessions created in the subrealm. ### Delegate agent profile creation If you want to create agent profiles when installing web or Java agents, then you need the credentials of an AM user who can read and write agent profiles. You can use the AM administrator account when creating agent profiles. If you delegate web or Java agent installation, then you might not want to share AM administrator credentials with everyone who installs agents. Follow these steps to create *agent administrator* users for a realm: 1. In the AM admin UI, go to Realms > *realm name* > Identities. 2. On the Groups tab, click Add Group and create a group for agent administrators. 3. On the Privileges tab, choose Realm Admin. 4. Click Save Changes. 5. Go to Realms > *realm name* > Identities. On the Identities tab, create as many agent administrator users as needed. 6. For each agent administrator user, edit the user profile. On the Groups tab of the user profile, add the user to agent profile administrator group. 7. Click Save Changes. 8. Provide each system administrator who installs web or Java agents with their agent administrator credentials. When installing Java agents with the `--custom-install` option, the system administrator can choose the option to create the profile during installation, and then provide the agent administrator user name and the path to a read-only file containing the agent administrator password. For silent installs, you can add the `--acceptLicense` option to auto-accept the software license agreement. ## Secure access to the admin UIs AM provides end-user pages, located at `am/XUI`, and an administration UI, located at `am/ui-admin`. Consider the following points to secure the AM admin UI: * Limit access to the AM admin UI. For example, allow access to the AM admin UI URI only to inbound connections from a specific network, or create a denylist or an allowlist with the endpoints the AM admin UI uses. Learn more in [Protecting PingAM with PingGateway](https://docs.pingidentity.com/pinggateway/2025.11/gateway-guide/protect-am.html) and [How do I remove admin UI access in PingAM?](https://support.pingidentity.com/s/article/How-do-I-remove-admin-UI-access-in-PingAM). * Make sure administrative users present strong credentials when logging in to the AM admin UI. By default, users that log in to the AM admin UI use the tree configured in the Organization Authentication Configuration property for the realm. To locate this property, go to Realms > *realm name* > Authentication > Settings > Core. Make sure you change the default for all realms, including the Top Level Realm. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The [API Explorer](../am-rest/about-api-explorer.html) is enabled by default. For security reasons, it's strongly recommended that you disable it in production environments.To disable the API Explorer, go to Configure > Global Services > REST APIs, and select Disabled in the API Descriptors drop-down list. | ## Secure access to Amster [Amster](../amster/preface.html) is a command-line interface built upon the AM REST interface. Don't install Amster on the same server as AM, so that administrators don't require a local system account on that server. Consider how Amster connects to AM and secure as necessary: * If Amster connects using interactive login, make sure administrative users present strong credentials. By default, Amster uses the tree configured in the Administrator Authentication Configuration property under Realms > Top Level Realm > Authentication > Settings > Core to connect interactively. * If Amster connects using private key connections, make sure you create your own keys and share them with AM. Learn more in [Private key connections](../amster/connect-am.html#private-login).