Linked logon accounts and dependent usage

Two related additions to a credential record, both now reachable from the console: Privileged → Clusters & agents (/pam/wave3), the Linked accounts & dependent usage panel. Pick the credential you want to configure — the panel is scoped one credential at a time, the same way the API underneath it is.

Linked logon accounts

Some privileged access is a two-step jump: you sign in as one account over SSH, then elevate (su or sudo) to the account actually being managed. A linked logon account records which credential is the jump account for a given managed credential, so the relationship is documented rather than living only in somebody's memory.

In the console, choose a credential, then use Set logon account to pick the jump credential from the vault and choose an elevation method, sudo or su. The panel shows the resolved name of the logon credential and its elevation method once set, and Clear removes the link entirely.

Dependent usage

A dependent usage is anything else that authenticates as a credential's account: a Windows service's Log On As identity, a scheduled task's Run As identity, an IIS application pool identity, or a reference baked into a configuration file. Recording these against a credential means a rotation's compliance report (see Rotation compliance report) can flag them, rather than a rotation silently breaking something nobody remembered depended on the old password.

From the same panel, Add usage records a usage's type, name and an optional description. You can optionally bind it to one of your enrolled PAM agents — see The PAM agent fleet for what an agent is and how it enrols. Binding an agent is what would let a usage be updated automatically after a rotation; a usage recorded with no agent is kept as inventory only and, today, cannot be acted on automatically either way, for the reason below.

The task payload never carries the new secret in the clear — it names the usage and the credential only, so a future agent-side handler would fetch the current secret through its own authenticated channel rather than the password travelling as plain task data.

The API behind the screen

PUT    /api/v1/organizations/{orgID}/pam/credentials/{credentialID}/logon-account
GET    /api/v1/organizations/{orgID}/pam/credentials/{credentialID}/logon-account
DELETE /api/v1/organizations/{orgID}/pam/credentials/{credentialID}/logon-account

POST   /api/v1/organizations/{orgID}/pam/credentials/{credentialID}/usages
GET    /api/v1/organizations/{orgID}/pam/credentials/{credentialID}/usages
DELETE /api/v1/organizations/{orgID}/pam/credentials/{credentialID}/usages/{usageID}

Both use the same pam:credentials.read/pam:credentials.write permissions as the rest of the vault, whether reached through the console or called directly.

What to do next

1. Record the jump account for any SSH credential you access through a two-step logon, so the relationship is documented, even though nothing enforces it yet.
2. Record every service, scheduled task and app pool you know depends on a credential's password before you turn on rotation for it — check A credential rotation failed if you are wondering why something broke after a rotation you already ran.
3. Do not rely on binding a PAM agent to a usage as a working auto-update yet — treat every dependent usage as something you still update by hand after a rotation, and check the agent's Tasks modal (see The PAM agent fleet) rather than assuming a queued task completed.