Skip to main content

ManageEngine PAM360

Read a distribution credential's value from a PAM360 account password at the moment it is used. For the concept, the never-cached reading model and everything the store types share, see External secret stores.

PAM360's shape is simpler than Vault's: there is no mount or namespace, and no login step — a per-request AUTHTOKEN authenticates everything. There is no username or password anywhere in the API path: the token is the whole identity, and the three PAM360 steps below all happen in its web UI as an administrator.

1. Create a host-bound API user​

In PAM360, go to Users → Add User → Add API User and create a dedicated user for CertAutoPilot:

  • Username — e.g. certautopilot.
  • Host name — the machine the API calls will come from, as PAM360 sees it: the hostname or IP of the CertAutoPilot backend (in --mode=all/worker, the worker host). The token is bound to this host — the same token sent from any other machine is rejected, so a wrong value here looks like an invalid token later.
  • Role — Password User is sufficient. CertAutoPilot only retrieves passwords; it never creates or edits resources.

Finish with Generate an Authentication Token — PAM360 requires it before the user can be saved, and shows the token once. Copy it.

2. Exchange the UI token for the working token​

The token from the UI is a bootstrap token: until it is exchanged, every API call answers "Regenerate your authentication token…" (statusCode 40035) — CertAutoPilot's Test button surfaces that message verbatim, so it tells you what to do. Exchange it once (from the host you bound in step 1):

curl -k -X PUT -H "AUTHTOKEN: <ui-token>" \
  https://pam360.internal:8282/restapi/json/v1/user/regenerateAuthtoken

The response carries the working token in Details.AUTHTOKEN — that is the value you will store in CertAutoPilot. The UI token stops working at that moment, and running the exchange again rotates the token (invalidating the previous one), which is also how you rotate it later.

3. Share the resources with the API user​

An API user sees nothing that is not explicitly shared to it — a fetch for an unshared resource fails as not found, not as permission denied. For each resource CertAutoPilot should read: Resources → select the resource → Share → the API user, with view/retrieve permission. The store's Test button reports how many resources the token can currently see, so 0 right after setup means this step was missed.

4. Configure CertAutoPilot​

  1. Add a stored credential of type PAM360 API Token holding the working token from step 2.
  2. Add the secret store: Store Type pam360, the PAM360 base URL (e.g. https://pam360.internal:8282), the credential from step 1, and — only if your install enforces reason/ticketing for password access — an Access Reason sent with every password retrieval. If PAM360 uses its self-signed certificate, either add its CA under CA Certificate or (lab only) skip TLS verification.
  3. Point a credential at it: Resource and Account exactly as their names appear in the PAM360 UI. The credential's value is that account's password.

What the value can be​

Because the value is always an account password, PAM360 suits the single-string credential types naturally (SSH password, SMTP password, bearer token, …). For a type that expects JSON, store the complete JSON object as the account's password — it works, but Vault's field-based model is the more natural fit for structured values. What each credential type expects is the field-mapping table.

PAM360 has no revision concept, so deployments record these reads as (no revision) in the job log (the same behaviour as Vault KV v1).

Operational notes​

  • API-call cost. A password retrieval is up to three API calls (resource name → id, account list, password). Within one deployment job the id lookups run once per resource/account and are reused; the password itself is fetched fresh on every single use — the id reuse never extends to the value.
  • PAM-side audit volume. Because nothing is cached between jobs, every deployment, retry and health check produces its own audited password retrieval in PAM360 (with the store's Access Reason, where configured). Size PAM360's audit retention and any ticketing rules with that in mind.

See also​