Verify Privilege Vault Roles on the Platform

This topic explains which Verify Privilege Vault roles automatically migrate to the Platform, what changes after the upgrade, and what you build yourself.

Start Here

Most customers do not need to manually recreate their Verify Privilege Vault roles on the Platform.

Built-In Roles in Verify Privilege Vault

Verify Privilege Vault ships with Administrator, User, and Read-Only User, plus a slimmed-down Basic User role. There are also internal system roles—Group Owner, User Owner, and the secret and folder access roles—which are not assigned like normal application roles.

What the Upgrade Center Brings Over

During Step 6, Synchronize Data, the upgrade copies the following from Verify Privilege Vault into the Verify Privileged Identity Platform:

• All roles, copied into the Verify Privileged Identity Platform database with the name prepended with Secret Server. Your Administrator role becomes Secret Server Administrator on the Verify Privileged Identity Platform, User becomes Secret Server User, and so on.

• Role assignments, preserved through group membership and individual assignment. If a Break-Glass Admins group holds the Administrator role in Verify Privilege Vault, that group becomes a member of the Secret Server Administrator role on the Verify Privileged Identity Platform.

• Local users, including their existing passwords, so people can keep signing in.

• Local groups, created with matching names and updated membership. Domain users in those groups are resolved through the AD Connector.

You do not need to rebuild any of this. For full detail and the surrounding steps, see Using Platform Upgrade Center in the Verify Privileged Identity Platform documentation.

What Changes After the Upgrade

Once you finish Step 7, Complete the Upgrade:

• The Verify Privileged Identity Platform becomes the authoritative source. Role and permission management transfers to the Verify Privileged Identity Platform and becomes read-only in Verify Privilege Vault.

• Manage everything at Access > Users / Groups / Roles on the Verify Privileged Identity Platform. The Verify Privileged Identity Platform reflects those changes into Verify Privilege Vault.

• Migrated roles appear only in the Verify Privileged Identity Platform. The Secret Server-prefixed roles are not shown in the Verify Privilege Vault interface.

• New Verify Privileged Identity Platform roles and role changes do not appear in the Verify Privilege Vault interface either, but they do take effect when users log in. This catches people out: an administrator looks in Verify Privilege Vault, does not see the change, and assumes it failed. Verify the change on the Verify Privileged Identity Platform under Access > Roles, not in Verify Privilege Vault.

• Disable User Synchronization in Verify Privilege Vault's Directory Services configuration after the upgrade, to prevent conflicting duplicate identity sources.

The Verify Privileged Identity Platform's Own Built-In Roles

Separate from your migrated roles, the Verify Privileged Identity Platform provides two built-in roles that cannot be edited:

• Platform User: logging in, launching Privileged Remote Access (PRA) sessions, accessing your own secrets, and viewing your own session recordings.

• Platform Admin: every permission for the features you have purchased, with one deliberate exception—Read All Secret Names is not granted automatically.

Creating a New Role

When you need a role that does not exist in Verify Privilege Vault today, go to Access > Roles > Create Role on the Verify Privileged Identity Platform and either start fresh or clone an existing role. Cloning one of your migrated Secret Server roles is often the fastest starting point. Add permissions on the Permissions tab, then attach the role to a group on the Members tab.

Starter Permission Sets

The tables below list the Verify Privileged Identity Platform permission names and strings for the two most frequently requested equivalents. Permission names and strings are as published in Platform Permissions in the Verify Privileged Identity Platform documentation.

User-Equivalent

Read-Only-User-Equivalent

Add read access to whichever reports and audit views the role needs, for example View Secret Audit (delinea.vault/secretserver/secret/audit/read) or Browse Secret Server Reports (delinea.vault/secretserver/administration/reports/browse).

Mapping Limitations to Plan For

• Some Verify Privilege Vault permissions collapse into a single Verify Privileged Identity Platform permission. Several distinct Verify Privilege Vault permissions map to the same Verify Privileged Identity Platform permission, so a fine-grained split you rely on today may not be reproducible. For example, the separate Verify Privilege Vault view permissions for Active Directory, Users, and Groups all map to one Verify Privileged Identity Platform identity read permission—grant it and you get all three.

• One role can require permissions from several Verify Privileged Identity Platform services. Session recording, analytics, discovery, licensing, and notification permissions live under their own Verify Privileged Identity Platform services rather than under the vault. Building the equivalent of a single Verify Privilege Vault role can mean selecting permissions from more than one place.

• A few Verify Privilege Vault permissions have no Verify Privileged Identity Platform equivalent and remain Verify Privilege Vault-side only.

Taking Inventory Before You Upgrade

Verify Privilege Vault stores the mapping between each of its own role permissions and the corresponding Verify Privileged Identity Platform permission name. Reading this mapping before you upgrade gives you an accurate picture of what each role contains and how it will express itself on the Verify Privileged Identity Platform—useful for reviewing least privilege while you are already touching roles.

Create a custom report using the SQL below. This is a read-only query and requires the Administer Reports permission. No direct database access is needed. For the full procedure, see Creating and Editing Reports.

SELECT r.Name                    AS [Secret Server Role],
                rp.Name                   AS [Secret Server Permission],
                rp.PlatformPermissionName AS [Platform Permission]
                FROM   tbRole r
                JOIN tbRoleToRolePermission rrp ON rrp.RoleId = r.RoleId
                JOIN tbRolePermission rp        ON rp.RolePermissionId = rrp.RolePermissionId
                WHERE  r.RoleType = 1
                AND r.Name = 'User'
            ORDER  BY 2

When you run the report:

• Change r.Name to the role you are interested in, or remove that line entirely to export every role at once.

• RoleType = 1 restricts the results to application roles and excludes the internal secret and folder access roles.

• Rows where Platform Permission is empty are Verify Privilege Vault permissions with no Verify Privileged Identity Platform equivalent.