Secret Rotation Task

The Secret Rotation Task enables VPAM administrators to set an automatic change policy (rotation) to a user’s password (secret) in a VPAM application. VPAM administrators can configure the secret rotation to a custom time, in a daily, weekly, or monthly frequency.

The Secret Rotation Task works by linking a VPAM application user secret to an Active Directory (AD) user, enforcing security and privacy to access the VPAM application. Additonally, the Secret Rotation Task can rotate local secrets in your systems.

This document contains the requirements and procedure to configure the Secret Rotation Task.

Requirements

To use the Secret Rotation Task, the VPAM administrator must comply with the following requirements:

  • Admin Role or Permissions in VPAM Server: To access the Vault and Tasks pages, you must have the admin role or additional privileges in your VPAM server. Contact your VPAM administrator for more information.

  • Active Directory (AD) Requirements:

    • Account: The VPAM admin must have access to the Active Directory account where they manage their users.

    • Administrator Privilege in the AD Account (Domain Admin): For the AD Secret Rotation Task, the VPAM administrator must also have AD admin permits, as they are needed to grant permission to rotate (change) another user’s password.

    • Base DN: Domain Admins must provide the Base DN attributes to configure the user retrieval from the Active Directory.

  • Linux/Unix and Windows Requirements:

    • Account: The VPAM admin must have access to the system where they manage their users.

    • Administrator Privilege in the System: For the Secret Rotation Task, the VPAM administrator must also have Linux/Unix or Windows admin permits, as they are needed to grant permission to rotate (change) another user’s password.

  • Domain User: A second user in your Active Directory. This user receives the Secret Rotation policy.

  • VPAM Server Version: The Secret Rotation Task is only available for VPAM servers with version 25.1.3 or newer. Contact success@imprivata.com for more information on how to update your VPAM server.

  • Application Services: (For AD Secrets) To configure your secrets and create tasks, ensure you have an application set up with either an LDAP or LDAPS service that's pointing to your Active Directory Domain Controller.

    • To properly configure the Rotation Policy, the application associated to the secret must have a WinRM service configured; otherwise, the rotation fails.

IMPORTANT:

If the administrator does not meet any of the previous requirements, the Secret Rotation Task will not run. Read the Secret Rotation Task Troubleshooting for more information.

How-To Use the Feature

The Secret Rotation Task functions in two areas of the VPAM User Interface:

  • The Vault tab, where you configure the secrets.

  • The Tasks tab, where you configure the rotation policy and to whom it applies.

The following sections describe the steps for VPAM admins to configure and use the Secret Rotation Task.

To create a new secret in the Vault Section of VPAM, follow these steps:

  1. Click +Add > Password Secret.

  2. Complete the Add New Password Secret Form considering the following:

    Attribute Description Required
    Secret Type Indicates the type of secret being created. Yes
    Secret Name Enter a unique name for the secret. This name identifies the specific secret. Yes
    Description Provide a description of the user associated with the secret. This is optional but can be helpful for identifying the purpose of the secret.

    No, but recommended
    Domain Specify the domain for the secret.

    Yes for AD

    No for Local
    User ID Enter the user ID associated with the secret. Yes
    Password Provide a password used for authentication. Yes
    Confirm Password Re-enter the password to confirm it. This ensures that the password was entered correctly. Yes
    Local Account checkbox Check this option to specify the secret is locally administrated.

    NOTE: This checkbox is required to enable Local Account Secret Rotation tasks.

    No for AD

    Yes for Local
    Is this secret part of a secret pool?

    Select Yes or No to indicate whether this secret is part of a secret pool. Secret Pools are groups of secrets that allow multiple users to log in to a host simultaneously, each with a unique secret. When a user connects to a service, an available secret is returned by the pool and marked as used by that user. A secret can only be used by one user at a time.

    IMPORTANT: Secrets in secret pools are not available for Rotation Tasks.

    No
    Select Port Types to Restrict Usage Specify the port types to ensure that this secret is available only for use with the selected port types.

    No, but recommended
    Select a Category Specify a secret category to limit the usage of this secret to users assigned to that category.

    No, but recommended
    Secret Scope Associate the secret to a User Group or a Vendor to limit who interacts with the secret. Yes.

  3. Click Create Secret to finalize and create the new secret.

The new secret is now ready for use and can be associated with the password rotation policy in the Tasks section.

IMPORTANT:

You must have at least one Domain Admin with permission to set up secret rotation for other users, and at least one Domain User, which can be either an admin or a standard user.

NOTE:

If you are configuring the Task for a local secret, read the Local Account Secret Rotation section.

After you have created the secrets for the AD Admin and the AD User users, you must continue to set the password rotation policy in the Tasks section of the VPAM UI. To start configuring the secret rotation:

  1. Click +Add > Password Rotation.

    The task pane opens.

  2. Select the type of system where the password is rotated:

    1. Active Directory (AD)

    2. Linux/Unix

    3. Windows.

  3. Click Next to open the Rotation Details.

  4. Complete the form considering the following:

Attribute Description Required Applies to
Task Name Add a unique name to the password rotation. Yes All Systems
Base DN Provide the Base DN where the policy queries the user to whom it applies. Consider the following example: dc=instance,dc=example,dc=com Yes AD only
Application Select the application that the user has access to, which is impacted by the secret rotation policy. No, but recommended AD only

Host Service

Select the LDAP or LDAPS service of the application.

 Yes AD only

Secrets to be rotated

Select all the user’s secrets (AD Users) that are impacted by the policy rotation policy.

 Yes AD only

Secret Provider

Select Single.

 Yes All Systems

Provider Name

Select the AD Admin User you created. This selection pulls authorization to place the rotation secret policy onto the AD User you selected in Secrets to be rotated.

 Yes All Systems
Secret List Select the secrets that are subject to this task. Yes All Systems

Task Password Policy

Set the rules for each new password that the policy rotates.

No, but recommended

 All Systems

The rotation policy enables you to set a schedule-based rotation policy by completing the Rotation Policy. Consider the following:

  • Allow on demand: Enables users to trigger the policy rotation as requested.

  • Rotate at given minutes after unlock: Define the time that must pass after unlocking a password before it rotates.

    • Daily: The secret changes every day.

    • Weekly: The secret changes every week, on the same day.

    • Monthly: The secret changes every month, on the set number days.

  • Schedule Rotation: Defines the moment the password changes:

    • When Daily selected: Choose the time of day.

    • When Weekly selected: Choose the day of the week and the time of day.

    • When Monthly selected: Choose the dates to rotate.

After configuring the password rotation policy, you can review the results of the task executions through the Task History page. This page provides detailed information about the status and execution timeline of each task.

To view the task execution results:

  • In Task, click on the name of a previously created task to open Task Details.

  • Click on Task History. This shows a table with the following information:

Field Description
Run ID The unique identifier for the task run.
Task Start The exact date and time when the task execution started.
Task End The exact date and time when the task execution completed.
Triggered By The user who triggered the task execution.
Trigger For The user whose secrets were impacted by the task
Execution Status Indicates whether the task was Successful or Failed.

This helps you monitor and verify the execution of secret rotation tasks.

Local Account Secret Rotation

While the configuration workflow in the UI is largely the same, local secret rotation introduces important behavioral differences and requirements that administrators must understand before implementation.

The following table outlines the differences between a local and AD rotation task:

Area Active Directory Accounts Local Accounts
Scope Centralized (domain-wide) Per-host only
Secret Assignment Can apply across multiple systems. One secret per host only.
Rotation Authority Domain Admin account. Local or valid executor account on host.
Dependency LDAP/LDAPS Integration Host-level access and permissions.
IMPORTANT:

The current implementation does not support reusing a single local secret across multiple hosts for rotation. Each host requires its own secret object.

When setting up Local Account Secret Rotation Tasks, consider the following:

  • One Secret per Host: A local secret must be tied to a single host. If the same username/password exists across multiple machines, you must duplicate the secret in the Vault and assign each secret to its respective host.

  • Valid Executor Account (Secret Provider): Unlike AD rotation (which uses a Domain Admin), local rotation requires a valid secret provider (executor account) that exists on the target host, and has sufficient permissions to change the target account password. This is configured in the Provider Name field in the Rotation Task.

  • Non-Domain Joined Hosts: For standalone systems, not connected to AD, you must manually ensure the following:

    • The target account (secret being rotated) exists on the host.

    • The executor account exists and has proper permissions.

NOTE:

Newly provisioned systems often have no additional users configured. Rotation fails because no valid account exists to execute the task.