Vault

NOTE:
  • This document contains information for the new UI. For Legacy instances, navigate to Legacy Credentials

The VPAM Vault stores private and privileged information as Secrets. A Secret can store a User ID and password relation or an SSH key association. When an authorized Vendor Rep or Internal User launches an Application service, VPAM can pass the Secret to the RDP, SSH, or Telnet sign-in window automatically.

The following list contains relevant terms that you must understand to continue with this document:

  • Secret: Refers to the privileged object in the Vault. It can be a User ID and password relation or an SSH key association.

  • Credential: Refers to the Legacy UI object. The Vault in the new UI does not deal with credentials.

Requirements

To configure the Vault and its extended functionality with Tasks, you must meet the following requirements:

  • Server Version: Your VPAM server must be on version 25.1 or later.

  • Permissions: System Admins have access to Vault management. Internal Users require the following permissions to work with the Vault:

    • LOGIN_TO_WEB_UI

    • VIEW_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS

    • CREATE_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS

    • EDIT_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS

    • DELETE_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS

    • UNLOCK_SECRET

    • MANAGE_SECRET_TYPES

    • MANAGE_CREDENTIALS

    • MANAGE_SSH_KEYS

    • MANAGE_HTTP_CREDENTIAL_MAPPING

    • MANAGE_SECRET_ACCESS_CONTROL

    • APPROVE_SECRET_ACCESS_REQUEST

    • Personal Vault: Internal Users must have CREATE_PERSONAL_SECRETS permission to use the Personal Vault.

      After you grant CREATE_PERSONAL_SECRETS, Internal User must sign out and sign back in.

  • Configuration: Personal Vault requires the server to use the Internal Access workflow.

Reference List

The Vault enables you to add the following types of secrets:

  • Password Secret: Stores a User ID and password relation. Useful when a Vendor Rep or Internal User have to authenticate to services such as RDP, SSH, or Telnet.

  • SSH Key Secret: Stores a User ID and SSH key association. SSH key pairs do not work if the key pairs are password protected.

  • OAuth Client Credential: Stores OAuth Credential for AI Agents.

  • Access Token: Stores an Access Token for AI Agents.

The Vault enables you to organize secrets with the following tools:

  • Secret Scope: Limits which User Groups and Vendor Reps have access to a secret.

  • Secret Category: Organizes the available secrets by access levels that you grant to Vendor Reps or Internal Users.

  • Secret Pool: Groups a number of secrets for one port type or service.

The Vault enables you to employ and protect secrets with the following actions:

Add a Secret

Add a Password Secret, SSH Key Secret, or Personal Secrets for Internal Users with the following steps:

  1. Open Vault > Secrets.

  2. Select Add New Secret.

  3. Select the secret type:

    1. Password Credential: A User ID and password association.
      Internal Users can use this option for Personal Secrets.

    2. SSH Key Credential: A User ID and SSH key pair association.

  4. Complete the form.

  5. Save the secret.

After you create a Secret, you can use it with services configured for an Application.

IMPORTANT:

SSH key pairs do not work if the key pair is password protected.

NOTE:

The Personal Secret Scope is driven by PAM and may require additional licensing. Contact your Imprivata Customer Support for more information.
System Admins can see Personal Secrets in the Secrets list for inventory and offboarding. They can see the owner, but they cannot view the stored password or SSH key.

To edit or delete a secret select the Secret name to open it.

The Secret Details page lets authorized users view the configuration and access the Edit and Delete actions.

NOTE:

To delete a Secret, you might first need to unlock it. If the Secret is checked out, it must be checked in before a System Admin can delete it.

Use Secret Scope to prevent a Secret from being available globally. Ensure the Secret Scope supports a specific team, Vendor, or access pattern.

The available Secret Scopes are:

  • Global: The secret is available for all permitted users.

  • User Group and Vendor: The secret is available for User Groups and Vendor Reps configured in the Secret.

  • Personal: The secret is only available to the Internal User that configures it.

NOTE:

The Personal Secret Scope is driven by PAM and may require additional licensing. Contact your Imprivata Customer Support for more information.

BEST PRACTICE:

Ensure you review the Secret Unlock feature for additional security measures.

Secret Categories define different types of Secrets within a Secret or Secret Pool.

Common uses include separating standard and administrative accounts or assigning categories to individual Vendor Reps for a more personalized desktop experience, such as unique RDP profiles.

If a Secret or Secret Pool requires categories, create the categories before you add the Secrets.

To add a Secret Category, follow this steps:

  1. Open Vault > Secret Categories.

  2. Select Add New Secret Category.

  3. Enter a name and a description.

  4. Select Save.

After you create a Secret Category, you can assign it to users or Vendor Reps so they receive the right Secrets and access level when they start a session.

IMPORTANT:

Secret Categories are implemented for individual users, individual Vendor Reps, or Secret Pools.
Each user and Vendor Rep can be assigned to multiple Secret Categories, and each Secret Category can include several Secrets.

To assign Secret Categories to a user or Vendor Rep:

  1. Navigate to the following:

    • User Management > Users > Select the User > Edit button > Secret Categories.

    • Vendors > Vendor List > Select the Vendor > Vendor Rep section > vendor representative > Edit button > Secret Categories.

  2. Select the Secret Categories that apply to them.

  3. Save the changes.

A Secret Pool is a group of Secrets based on port type. When a user accesses an Application service that uses a Secret Pool, VPAM passes the stored User ID and password to the client and signs the user in automatically.

Secret Pools are instanced per host name. Because of that, the same Secret can be handed out more than once if the host names are different.

For example, if the same host is defined once as host.domain.tld and once as 192.168.1.1, VPAM treats them as two different host names and two different Secret Pool instances.

IMPORTANT:

Secrets cannot be shared across multiple Secret Pools.

Create Secret Pools with the following steps:

  1. In Vault > Secrets, select Add New Secret Pool.

  2. Complete the form.

  3. Select Save.

To add Secrets to a Pool:

  1. Open the target Secret Pool.

  2. Select Add.

  3. Complete the form.

  4. Select Create Secret.

  5. Use the Secret Pool with the related services.

Secret Unlock and Checkout

Use Secret Unlock and Secret Checkout to control how Internal Users access sensitive Secrets in the Vault.

  • Secret Unlock protects Secrets until an authorized Internal User or System Admin requests access to view, copy, use, or edit the Secret.

  • Secret Checkout controls exclusive use. When checkout is required, VPAM checks out the Secret to one user for a limited time. Other users cannot unlock or view the Secret until the secret is checked back in or a System Admin checks it in manually.

IMPORTANT:

If an Internal User is not permitted to view or edit a secret, the request to Unlock or Checkout a secret triggers an Internal Approval Process.

NOTE:

Vendor Reps do not use the Vault unlock or checkout workflow directly. If a Secret is scoped to the Vendor Rep, VPAM uses the assigned Secret during the Application service launch.

Use this section to configure approval, checkout, Secret-level access, and required permissions. Follow the steps in this section.

Configure Server-Level Approval Rule for Secret Unlock

These steps manage the configuration of Secret Unlock at a server-level:

  1. Open System Administration > Access Management > Internal User Access tab.

  2. In Secret Access Settings, select one of these options:

    • Require approval for Internal Users to edit or unlock a Secret: Internal Users must request approval before they can edit or unlock a Secret.

    • No Internal User Approval: Internal Users can unlock Secrets without submitting an access request.

  3. Set the default approval form or profile if approval is required,

  4. Confirm that approvers have access to the Secret and the APPROVE_SECRET_ACCESS_REQUEST permission.

Configure Server-Level Exclusive Checkout

These steps manage the configuration of Secret Checkout at a server-level:

  1. Open System Administration > System Settings.

  2. Set Secret Checkout for Exclusive Use:

    • Required: VPAM reserves the Secret for one user when the Secret is unlocked or edited. (Recommended)

    • Disabled: Users can unlock the Secret, but VPAMdoes not enforce exclusive checkout.

  3. Set the Secret Checkout Duration.
    When an Internal User checks out a Secret, the number specified here will appear as the default duration. This will not prevent the User from specifying a different duration.

  4. Save the changes.

Configure Access for an Individual Secret

These steps manage the configuration of Secret Unlock at a Secret level.

TIP:

Reserve this configuration for individual secrets that require to be separate from the server-level configuration set in Configure the Default Approval Rule for Internal Users.

  1. Open the Secret, or create a new Secret.

  2. Review Secret Scope.

  3. Confirm that only the required User Groups and Vendors can use the Secret.

    NOTE:

    If a user has been assigned multiple Secret Categories, they will have access to this Secret if it is associated with any of their assigned categories. Review all assigned categories when scoping Secret access.

  4. Select one of the following in Secret Access Approval:

    1. Use system default: Follows the server-level configuration.
      Read Configure the Default Approval Rule for Internal Users

    2. Require approval for Internal Users to edit or unlock this Secret: Internal Users must request approval before they can edit or unlock a Secret.

    3. No Internal User Approval: Internal Users can unlock Secrets without submitting an access request.

  5. Save the Secret.

Configure a Secret Unlock Rotation Policy

System Admins can create a password rotation policy that runs after a Secret is checked-in.

Read the Secret Rotation Task document for more information.

Internal Users may need approval before they can view, copy, use, or edit a Secret. The exact workflow depends on the approval and checkout settings configured by the System Admin.

Unlock a Secret to View, Copy, or Edit

  1. Open the Secret you want to view or copy.

  2. Select Request Access, if Request Access is available.

  3. Complete the approval request.

  4. Wait for approval.

  5. After approval, or immediately if approval is not required, select Unlock Password.

  6. Enter a reason, if prompted.

  7. Enter the checkout duration, if prompted.

  8. Select Continue.

  9. View, copy, or edit the Secret.

If exclusive checkout is enabled, VPAM checks out the Secret to the user for the selected time.

Status Reference

During the Secret Unlock and Secret Checkout, Internal Users may see the following UI elements:

State Description
Request Access Approval is required before the user can unlock or edit the Secret.
Access Request Pending The approval request is waiting for an approver.
Unlock Password The user can unlock the Secret value.
Edit Secret The user can start the edit flow.
Checkout Expires In The Secret is checked out and the timer is running.