Skip to main content
Version: latest

Password checkout fails or vault is locked

VaultPAM stores credentials in an encrypted vault backed by OpenBao. When you attempt to launch a session or check out a credential and the action fails, one of four causes is almost always responsible. Vault seal events are rare but disruptive; permission and policy issues are far more common.

Symptoms​

  • Clicking Launch Session or Check out password returns an error such as:
    • Vault is sealed — credential access unavailable
    • Credential policy expired
    • You do not have permission to check out this credential
    • This safe is locked
  • The credential field in the Safe detail view shows a lock icon or "Unavailable" instead of a masked value.
  • A previously working checkout suddenly fails after no visible change.

Causes​

1. Vault sealed (OpenBao)​

VaultPAM uses OpenBao for credential encryption. If the OpenBao instance is sealed — due to a restart without auto-unseal, a key provider outage, or an operator seal command — no credential read or write operation can succeed until the vault is unsealed.

Check: A "Vault is sealed" banner may be visible in the VaultPAM admin panel under System → Vault Status. Operators can also check directly on the OpenBao host:

bao status

The Sealed field will be true if the vault needs unsealing.

Who can fix this: Only operators with unseal key shares (or access to the auto-unseal provider, such as GCP KMS or AWS KMS) can unseal the vault. End users cannot unseal it.

Fix for operators: Unseal the vault using the required number of unseal key shares:

bao operator unseal <key-share>

Repeat for each required share. Once Sealed: false is confirmed, credential operations resume automatically. If auto-unseal is configured and the vault sealed unexpectedly, check that the KMS key or Transit path is reachable from the OpenBao host.

2. Credential policy expired​

Safe-level credential policies can enforce a maximum checkout duration, a rotation schedule, or an expiry date. If a policy has expired or if a time-based rotation has invalidated the current credential before checkout, the checkout fails.

Check: Open Safes → pick Safe → Edit → Credential policy. Look for:

  • A policy end date that has passed.
  • A rotation schedule that ran and the new credential has not yet been stored.
  • A "Checkout TTL" that is set to zero or a very short window.

Fix: Update the credential policy to extend the validity window, or trigger a manual rotation: Safes → pick Safe → Credentials → Rotate now. If rotation requires an upstream system change, coordinate with the target system admin.

3. User lacks checkout permission​

Checkout is an explicit permission granted through Safe membership and role assignment. A user with read access to a Safe does not automatically have checkout permission.

Check: Open Safes → pick Safe → Members. Find the user or the group the user belongs to. Confirm their role includes the Checkout permission. Roles and their permission sets are visible in Organization → Access → Roles.

Fix: Ask a Safe admin or VaultPAM admin to update the user's role to one that includes the Checkout permission, or add the user to a group that already has that access.

4. Safe locked by admin​

An admin can lock a Safe to prevent all sessions and checkouts, typically during a security incident investigation or a maintenance window. A locked Safe shows a lock icon in the Safe list.

Check: In the Safes list, look for a lock badge on the affected Safe. If present, the Safe is intentionally locked.

Fix: Only a Safe owner or VaultPAM admin can unlock a Safe. Contact your admin and ask them to unlock it via Safes → pick Safe → Actions → Unlock safe. Ask them to confirm the reason for the lock and whether it is safe to unlock.

Resolution steps​

  1. Attempt the checkout or session launch. Note the exact error message.
  2. If the error mentions the vault being sealed, open System → Vault Status in the VaultPAM admin panel. If the vault is sealed, escalate to an operator with unseal key access immediately — end users cannot resolve a sealed vault.
  3. If the error mentions a policy, open Safes → pick Safe → Edit → Credential policy and check for an expired policy or overdue rotation. Extend the policy or trigger a manual rotation.
  4. Open Safes → pick Safe → Members and verify your role includes the Checkout permission. If it does not, request a role change from a Safe admin.
  5. In the Safes list, confirm no lock icon is displayed on the affected Safe. If it is locked, contact a Safe owner or VaultPAM admin and ask them to unlock it.
  6. After any change, retry the checkout or session launch.

Escalation path​

If none of the above steps resolve the failure:

  1. Note the exact error message and the name of the Safe and credential involved.
  2. If the vault sealed unexpectedly (not during planned maintenance), treat this as a P1 operational incident and contact your VaultPAM operator immediately.
  3. For persistent permission or policy issues that cannot be explained by the current configuration, open a support ticket with: Safe name, affected username, exact error message, and a screenshot of the current credential policy and member list.