Vault or Credentials

A credential is a saved User ID and optional password/domain association that your Vendors can reuse with many Applications.

Adding secrets enables you to store and authenticate a valid username and password credentials to RDP, SSH, and Telnet services for an Application.

IMPORTANT:
From Version 25.1 on, the platform manages this features in the Vault menu, using Secrets. Some features in this section may only be available in previous versions of VPAM, as the Credentials menu.
The new User Interface, using the Vault, also enables you to create Tasks for the Credential Rotation Task.

When your Vendor accesses your Application and selects the service, the User ID and password you provide will be passed through to the RDP, SSH, or Telnet log in window. If the credentials are accepted, your Vendor will be forwarded directly to the desktop to perform their work.

From the Vault or Credentials menu, you can add credentials, create credential categories, add credential pools, manage SSH Keys, and manage HTTP Credential Mappings.

Add a Secret or a Credential

To add a secret, click Add New Secret in the Vault page. Select the type of secret you want to add:

  • Password Credential: A User ID/Password association

  • SSH Key Credential: A User ID/SHH Key association.

NOTE:
SSH Key Pairs configuration does not work if the key pairs are password protected.

Complete the selected option's form and Save the changes.

You can grant a User Group access to the secret you configure by using the Secret Scope section of the form.

Using this method in the Vault also enables you to create Tasks for the Credential Rotation Task.

You can use the Secret Scope section to grant access to User Groups and Vendors to the secret you create. The Secret Scope section of the form appears to System Administrators or internal users with the following permissions:

  • LOGIN_TO_WEB_UI

  • VIEW_SECRET

  • CREATE_SECRET

  • MANAGE_SECRET_TYPES

After you assign a secret to a User Group and Vendor, only that group and Vendor Reps can use the associated credentials, increasing security to applications.

BEST PRACTICE:
Provide granular access to User Groups and Vendors to increase access and security to your applications. Review the Secret Unlock feature for additional security measures.

To add new credentials:

  1. Select Add New Credential from the Credentials section.

  2. Enter information in the following fields:

    Field Description
    Credential Name (required) Enter a unique name for this credential.
    Description An optional description field.
    User ID (required)

    Enter the User ID to be stored.
    SSH Authentication Option

    Select the type of credential association:

    • Password: Provide a password for the user

    • SSH Key Pair: Provide the Key Pair name

    Password / Confirm Password

    For Password selection in SSH Authentication Option

    		 If desired, enter a password to associate to the referenced User ID.

    HTTP Credential Mapping

    For Password selection in SSH Authentication Option

    		 Required for HTTP Credential Mapping services configured in your Applications.

    SSH Key Pair Name

    For SSH Key Pair selection in SSH Authentication Option

    		 Provide the SSH Key Pair Name.
    Domain Enter the domain (if any) that is associated with the referenced User ID.

  3. After you add one or more credentials, you can edit services to take advantage of the new credentials.

To view a Secret or a Credential, click the name of the Secret or Credential you want to view.

The View Credential page enables you to edit or delete the credential.

From the View Secret or View Credential page, click Edit. System admins can edit all the fields in the Credential registry.

NOTE: To edit a Secret, you may need to follow the Secret Unlock feature.

From the Edit Secret or Edit Credential page, click Delete.

NOTE: To edit a Secret, you may need to follow the Secret Unlock feature.

Secret Unlock (v 25.1.9)

Secrets in your VPAM Vault are protected by the Secret Unlock feature. This feature prevents any internal user to view

For credentials that internal users require to access an application, system administrators or internal users with the VIEW_SECRET and UNLOCK_SECRET permissions can request access to edit or use a secret.

NOTE:
If the secret's scope is not global, internal users also require access to the secret's scope.

When requesting access to a Secret, the system does the following:

  • Prompts internal users to provide a reason for unlocking the secret.

  • Triggers an approval process to check out the secret.

  • Triggers an unlock rotation task that runs when the secret is checked in.

The Credential Checkout Approval Workflow requires an authorized approver to allow a user to check out or use a secret from the Vault. This feature is designed for high-risk credentials to enforce just-in-time access, multi-person authorization, and auditing.

If configured, the system triggers the Checkout Approval workflow when a system admin or permitted internal user click Request Access on a credential's details page.

System Admins can configure the approval process at a server-level or at a secret-level.

Read more about Approvals and Approval profiles.

Credential checkout and check-in allow you to enforce exclusive access to a credential. When a system administrator or permitted internal user requests access to a credential, the credential can be checked out to prevent simultaneous use.

  • Credential Check Out: Prevents other users or administrators from viewing or unlocking the credential until it is checked back in.

  • Credential Check In: Makes the credential available again for other permitted users or administrators to unlock and check out.

Configure

Credential check-out behavior is controlled under System Administration > System Settings using the Secret Check Out for Exclusive Use setting.

When Secret Check Out for Exclusive Use is set to Required, administrators can also configure the Secret Check Out duration. This setting defines how long a credential remains checked out before it is automatically checked back in. The maximum configurable duration is 60 minutes.

While a credential is checked out, the user who checked out the credential sees a banner in their session displaying a countdown timer that indicates when their access expires. Standard users cannot manually check in the credential.

Administrators can view the check-out status of credentials in the Vault, including which user currently has a credential checked out. Administrators can manually check in a credential on behalf of the user.

NOTE:

A credential must be checked in before an administrator can delete the secret. If the credential is currently checked out, the administrator must check it in before deleting it.

System Administrators can set a password rotation policy that is triggered by the unlocking of a credential. To create a password rotation policy triggered by the secret unlock, administrators should:

  1. Open the Tasks page.

  2. Create a new task for password rotation.

  3. Select the target system.
    The password rotation task form opens.

  4. Scroll to the Rotation Policy section of the form.

  5. Set the time for the password to rotate after being unlocked.

  6. Save the task.

Secret Pools

A secret pool is a group of credentials based upon port type (Ex/ RDP, SSH, Telnet). Adding credentials enables you to store and authenticate valid username and password credentials to credential-enabled services for an Application. Credentials cannot be shared across multiple pools.

When you access an Application's service, the User ID and Password provided by the stored credential will be automatically passed to the associated Client and you will be automatically logged in.

Secrets Pools, once defined, are instanced per Host Name. This means that it is possible for the Secret Pool to hand out the same credential more than once; however, because the hostname is different that's okay because it's presumed to be a different system. In the case of a hostname being defined twice — once as a string (host.domain.tld) and once as an ip address (192.168.1.1) — Imprivata Vendor Privileged Access Management will consider this as two separate hostnames and two separate pool instances.

To add new credential pools:

  1. Select Add New Secret Pool from Vault > Secrets.

  2. Enter information in the following fields:

    Field Description
    Name (required) Enter a unique name for this Credential Pool.
    Port Type (required) Select a Port Type for this Credential Pool.
    HTTP Credential Mappings

    Applies when HTTP or HTTPS are specified as the Port Type.
    Scope Select the User Groups that have access to this Secrets Pool. Read the Secret Scope section for more information.

To add secrets to a credential pool:

  1. Click + Add in the target Secret Pool.

  2. Enter information in the following fields:

    Field Description
    Credential Name (required) Enter a unique name for this credential.
    Description An optional description field
    User ID (required) Enter the User ID to be stored
    Password / Confirm Password  
    Domain Enter the domain (if any) that is associated with the referenced User ID.

  3. Click Create Secret.

  4. Use the credential pool for your services.

SSH Key Pairs

SSH Credentials may use password or key based authentication. To use key based authentication, you must upload the credential to the Imprivata Vendor Privileged Access Management server as a Private Key / Public Key pair so that the server may present this on behalf of the connecting user.

NOTE:
SSH Key Pairs configuration does not work if the key pairs are password protected.

  1. Navigate to System Administration > Credentials > New SSH Key Pair.

  2. Type a name for the SSH Key Pair.

  3. Type a meaningful description.

  4. Click Upload to upload a new SSH Key Pair.

  5. Click Choose File to select a file for the Private Key File.

  6. Click Choose File to select a file for the Public Key File.

  7. Click Save SSH Key Pair.

Once uploaded, the Key Pair can be linked to most Imprivata Vendor Privileged Access Management credential types (all but Credential Pools). A Key Pair may be linked to multiple credentials at the same time.

VPAM is compatible with RSA, DSA and ECDSA key formats. Generate a key from the command line:

Copy 
ssh-keygen -m PEM
NOTE:

Legacy OpenSSH versions do not support the -m PEM flag. For these versions, the flag is not required and the generated keys should work by default.

If you have an existing OpenSSH Key with the new format, you may need to convert to the -m PEM format. Here's an example command to do the conversion:

Copy 
ssh-keygen -p -f /path/user/.ssh/existing_keyfile -m PEM
NOTE:

The -p flag is used to remove the passphrase from the file.

SSH PAM Module

SSH PAM modules allow for an extra layer of security by prompting the connecting user to respond to a challenge via keyboard input. For example, Google Authenticator's verification codes.

SSH PAM modules are configured separately from normal sshd settings. The config files are typically in /etc/pam.d/sshd and /etc/ssh/sshd_config respectively.

For successful SSH service launches, the connecting host must have consistent authentication methods in the PAM and sshd configurations.

For example, password authentication must be enabled in sshd_conf if it is enabled in the sshd PAM settings and vice versa. Inconsistent authentication methods in sshd PAM and sshd_conf can prevent proper credential handling. The sshd server may prompt for a password despite the PAM settings refusing password authentication. Or, the PAM settings may require password authentication despite the sshd_conf not accepting them.

HTTP Credential Mapping

For information on this Credentials option, read the HTTP Credential Mapping document.