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 unavailableCredential policy expiredYou do not have permission to check out this credentialThis 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
- Attempt the checkout or session launch. Note the exact error message.
- 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.
- 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.
- 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.
- 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.
- After any change, retry the checkout or session launch.
Escalation path
If none of the above steps resolve the failure:
- Note the exact error message and the name of the Safe and credential involved.
- If the vault sealed unexpectedly (not during planned maintenance), treat this as a P1 operational incident and contact your VaultPAM operator immediately.
- 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.