PingAM and ForgeRock Security: Hardening AM, DS and IDM Deployments

PingAM, PingDS and PingIDM, the access management, directory and identity management products many teams still know by their ForgeRock names, hold the super-user accounts, signing secrets and connector credentials that the rest of an identity platform depends on. Because these products are commonly self-managed, the customer controls most of the settings that decide how well they are protected: who can administer each realm, where secrets live, which journeys users pass through, how the directory authorises administrators and what gets logged. This guide sets out a practical hardening baseline for all three, using the product names and settings in Ping Identity's version 8 documentation. It is for identity engineers and platform teams running these products in production. PingFederate and PingOne are covered separately in the Ping Identity Security Hardening Guide.

This is an independent guide from NHI Mgmt Group, based on Ping Identity's public documentation as of November 2026. It is not sponsored or reviewed by Ping Identity. Product features change, so confirm settings against Ping Identity's current documentation.

Key takeaways

• Keep amAdmin for break-glass work only: delegate realm privileges to ordinary users in groups, and store the amAdmin password as a hashed, encrypted secret in a secret store.
• Scope delegated privileges to subrealms, because privileges delegated in the Top Level Realm grant full access to the AM instance, and narrow REST privileges such as Policy Admin avoid handing out Realm Admin.
• Move every key and password into mapped secret stores, using secret labels with an active alias and older aliases kept for verification, so rotation is a reorder rather than an outage.
• Make strong journeys the default in every realm, including the Top Level Realm, and turn on journey session allowlisting.
• Use uid=admin in PingDS and openidm-admin in PingIDM only for set-up, then replace or restrict them, and ship AM, DS and IDM audit logs to a central SIEM.

How identity and access work in PingAM, PingDS and PingIDM

The three products divide the work of a self-managed identity platform:

In PingAM, everything happens inside realms. The Top Level Realm sits above all subrealms, and users authenticate through journeys (authentication trees) chosen by realm settings. Administrators are either the built-in amAdmin user or ordinary identity store users who have been granted privileges through group membership. Applications reach AM through OAuth 2.0 clients, SAML entities and agents. Signing, encryption and mTLS rely on secrets that AM resolves through secret labels mapped to aliases in secret stores.

Ping's general guidance for AM and IDM is the same starting point used in this guide: keep up to date on patches and cryptographic algorithms, enable certificate verification, turn off unnecessary features, limit access to the servers, enforce security rather than relying on users, audit access and changes, and protect system passwords and secrets. PingIDM's security guide adds that its out-of-the-box set-up favours ease of development, so production deployments need deliberate configuration.

Admin roles and privileged access

PingAM: amAdmin and delegated administrators

Ping documents amAdmin as an account to use sparingly. It cannot be deleted, so the aim is to protect it and avoid needing it:

• Delegate instead of sharing amAdmin: create ordinary users, place them in groups, and grant privileges at Realms, realm, Identities, Groups, group, Privileges (or with ssoadm add-privileges).
• Delegate in subrealms: privileges granted in the Top Level Realm give full access to the AM instance, while subrealm privileges apply only to that realm and its children.
• Choose narrow privileges: Realm Admin grants full realm access and is required for the admin UI. For REST-only automation, Ping lists narrower privileges such as Policy Admin, Entitlement Rest Access, Privilege Rest Read Access, Privilege Rest Access and Session Property Modify Access.
• Avoid broad virtual groups: the All Authenticated Identities group applies to any identity with a valid session, so do not grant it privileges.
• Require MFA for delegated admins: they are ordinary identity store users, so any supported multi-factor journey can apply to them.
• Give agent installers their own account: create a group with Realm Admin for dedicated agent administrator users rather than sharing amAdmin credentials.

To protect the amAdmin password itself, Ping recommends storing it in a secret store. The value must be hashed with salted SHA-512 using the {SSHA-512} prefix, and encryption is strongly recommended, by setting org.forgerock.openam.secrets.special.user.passwords.format to ENCRYPTED_PLAIN (AM encryption password) or GOOGLE_KMS_ENCRYPTED (Google Cloud KMS). The secret is mapped through a password.amadmin file in the special secret store directory, the PASSWORD_AMADMIN environment variable or the password.amadmin Java system property. AM caches it for 900 seconds by default, and Ping advises rotating it periodically. While the secret is configured, the password cannot be changed in the admin UI, which helps keep the value under change control.

PingDS: uid=admin and directory privileges

• Use uid=admin for set-up and privilege assignment, not routine work, as Ping's DS authentication guidance describes.
• Keep privilege-change away from everyday administrators: an account that can change privileges can grant itself bypass-acl, which exempts it from ACIs, including global ACIs.
• Grant narrow privileges for narrow jobs: for example subentry-write to administrators who manage password policy subentries.
• Keep anonymous access limited: anonymous access to directory data is off by default in PingDS. Allow it only for public data such as root DSE attributes and schema, using ACIs with the ldap:///anyone subject.

PingIDM: replace openidm-admin

Ping documents how to replace the built-in openidm-admin account with a custom administrator that holds internal/role/openidm-admin and internal/role/openidm-authorized. The steps are: create the internal user, add a STATIC_USER authentication module whose password is a $purpose reference to idm.admin.password, map that secret in conf/secrets.json and the filesystem secret store, verify the new account, then disable or delete openidm-admin. Disabling (setting enabled to false on its module) is reversible; deleting also requires removing it from conf/repo.init.json so it is not recreated at start-up.

Admin UI and tools

• Restrict network access to the AM admin UI (am/ui-admin) and its endpoints with an allowlist, or enforce access through PingGateway.
• Disable the API Explorer in production: Configure, Global Services, REST APIs, set API Descriptors to Disabled.
• Run Amster and ssoadm from a separate host so administrators need no local accounts on AM servers, and give tools a dedicated authentication tree through the Administrator Authentication Configuration property so tool logins stand out in logs.
• Protect the ssoadm password file: it is stored in cleartext, so make it readable only by its owner. For Amster, use strong credentials or your own keys for private key connections.

For the wider model of tiered admin access, see the Privileged Access Management Guide and the Break-Glass Account Guide.

Integrations, API tokens and service accounts

Secrets, keys and rotation in PingAM

AM resolves each cryptographic need through a secret label (signing, encryption, mTLS and others). Each label maps to one or more aliases in a secret store. The first alias is the active secret used to sign and encrypt; the others are used only to verify and decrypt, so older tokens keep working during rotation.

Secret stores can be global (Configure, Secret Stores) or per realm (Realms, realm, Secret Stores). Ping notes that rotating between secrets of different algorithm types is not a supported path, so plan algorithm changes as a separate migration. Ping's secrets documentation also includes a page on changing default key aliases: replace the sample keys shipped for evaluation with your own before go-live. For the underlying practice, see the Cryptographic Key Management Guide.

OAuth clients, agents and connectors

• OAuth 2.0 clients: each client is a non-human identity. Register it in the narrowest realm, restrict scopes and grant types to what it uses, and keep client secrets in your secrets manager. See the API Keys vs OAuth Tokens Guide.
• Agents: install them with the dedicated agent administrator accounts described above, not with amAdmin.
• IDM connectors: each connector authenticates to a target system (a directory, database or SaaS service) with a service account. Give that account only the rights the mapping needs, store its credential in an IDM secret store (file, filesystem, property or HSM types are documented), and review it alongside other privileged accounts.
• Directory bind accounts: AM and IDM bind to PingDS with service accounts. Ping's AM guide has a section on securing authentication to data stores; use LDAPS or StartTLS for every simple bind, or certificate-based SASL EXTERNAL where distributing keys is easier than protecting passwords.

Logging and detection

PingAM's audit logging service writes four topics by default through the JSON handler:

For configuration events, Ping documents that you can trace the actor through the transactionId in the access log, so correlate the two in your SIEM. Besides JSON, AM documents CSV, Syslog, JDBC and JMS handlers; digital signing of audit records, which makes tampering detectable, is available with the CSV handler. PingIDM's audit service follows the same log structure as the rest of the platform, and Ping's IDM guidance is to review both IDM and operating system audit logs. For onboarding these sources, see the SIEM Log Source Onboarding Checklist.

Priority alerts:

• Any authentication as amAdmin, uid=admin or openidm-admin outside a recorded change or break-glass event.
• Privilege grants in the Top Level Realm, and new grants of Realm Admin.
• Secret store, mapping or alias changes in config.audit.json.
• Changes to the Organization Authentication Configuration or to journeys used by administrators.
• New or changed OAuth 2.0 clients and agent profiles.

Metrics

• Number of amAdmin, uid=admin and openidm-admin logins per month (target: only planned events).
• Number of users with Top Level Realm privileges.
• Percentage of secret labels mapped to managed secret stores rather than sample keys.
• Age of the active signing secret against your rotation target.
• Share of AM, DS and IDM servers forwarding audit logs to the SIEM (target 100 per cent).

Hardening baseline

Session, cookie and journey settings in PingAM

Ping's security guide also covers HttpOnly cookies, SameSite rules, CDSSO cookie restrictions, session quotas, account lockout and limits on request body and compressed JWT size; review each against your deployment.

Phased rollout

1. Inventory: list realms, privileged groups, OAuth clients, agents, secret stores and labels, DS privileges and IDM connectors. No changes yet.
2. Strengthen journeys: set an MFA journey as the Organization Authentication Configuration in a test realm, verify, then apply to each realm and finally the Top Level Realm. Rollback: restore the previous journey name in the setting, keeping a tested break-glass path.
3. Delegate and restrict admins: create subrealm admin groups with narrow privileges, move daily work off amAdmin, then move the amAdmin password into a secret store.
4. Secrets: map every label to managed stores, replace default key aliases, and rehearse rotation by adding and promoting a new alias in pre-production.
5. Directory and IDM: remove privilege-change from routine DS administrators, enforce TLS binds, and replace openidm-admin (disable first, delete later).
6. Logging: forward all audit topics to the SIEM and switch on the alerts above.
7. Maintain: apply Ping security updates promptly, review privileges quarterly and rotate secrets on schedule.

Decision guidance

• Single-realm, smaller deployments: keep end users in a subrealm, privileged accounts tightly limited, a filesystem or keystore secret store with documented rotation, and JSON audit logs forwarded by your log agent.
• Large or regulated deployments: an HSM or cloud KMS secret store for signing keys, PingGateway in front of AM admin and Top Level Realm endpoints, CSV signed audit or Syslog to a protected collector, and formal change control for journeys and privileges.
• Keystore versus HSM or KMS: keystores are simple and support multiple aliases per label; HSM and cloud KMS keep key material outside the AM host, with Google KMS and Secret Manager managing rotation on the Google side.

Framework mapping

Common misconfigurations

• amAdmin used for daily work: fix by delegating subrealm privileges to named users and storing the amAdmin password in a secret store.
• Privileges granted in the Top Level Realm for convenience: fix by moving them to the subrealm the admin actually manages.
• Realm Admin given to automation: fix by using REST privileges such as Policy Admin or Privilege Rest Read Access.
• Default ldapService journey left as the realm default: fix by setting an MFA journey in every realm, including the Top Level Realm.
• Sample or default key aliases in production: fix by mapping labels to your own keys and following Ping's change default key aliases steps.
• openidm-admin and uid=admin used by scripts: fix by creating dedicated, narrowly privileged accounts and restricting the built-in ones to set-up and recovery.

Practitioner checklist

• Delegate admin work to groups in subrealms; keep amAdmin for break-glass only.
• Store the amAdmin password hashed ({SSHA-512}) and encrypted in a secret store, and rotate it periodically.
• Set an MFA journey as the Organization Authentication Configuration in every realm and turn on Enable Allowlisting.
• Restrict am/ui-admin to admin networks, disable API Descriptors and run Amster and ssoadm from a separate host.
• Map every secret label to managed secret stores, replace default key aliases and rehearse rotation.
• In PingDS, keep privilege-change and bypass-acl off routine accounts and require TLS for simple binds.
• Replace openidm-admin with a custom admin backed by a secret, then disable the original.
• Give each IDM connector and OAuth client a least-privilege identity with its credential in a secret store.
• Forward AM access, activity, authentication and config audit topics, plus DS and IDM logs, to the SIEM with alerts on admin and secret changes.
• Apply Ping security updates promptly and review privileges every quarter.

Standards and references

• Ping Identity: PingAM Secure administrative access
• Ping Identity: PingAM Map and rotate secrets
• Ping Identity: PingAM Secure realms
• Ping Identity: PingAM Journey session allowlisting
• Ping Identity: PingAM Audit logging service
• Ping Identity: PingDS Authentication security
• Ping Identity: PingIDM Administrative users
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Ping Identity Security Hardening Guide · Identity Provider and SSO Security Guide · Cryptographic Key Management Guide · Privileged Access Management Guide · Cookie Security Guide