Quick Start Guide

This guide is for new or prospective IBM Security customers who wish to purchase or sign up for a trial of the integrated Verify Privilege Vault Cloud on the Verify Privileged Identity Platform, with unified administration. With unified administration, individual administrators can access both Verify Privilege Vault Cloud and platform functionality simultaneously and seamlessly.

The guide is not for existing Verify Privilege Vault Cloud or Verify Privilege Vault On-Premises customers. See the Notes below:

Existing Verify Privilege Vault Cloud customers must integrate their Verify Privilege Vault Cloud instance into the Verify Privileged Identity Platform. Please see Connecting to Verify Privilege Vault Cloud.

Existing Verify Privilege Vault On-Premises customers can add Privileged Remote Access functionality using a limited upgrade. Please see Connecting to Verify Privilege Vault On-Premises.

To troubleshoot common on-boarding issues, see Onboarding Troubleshooting.

Platform Security Best Practices

It's important to keep platform security best practices in mind while you're setting up your new Verify Privileged Identity Platform instance. These practices are defined in the Platform Security Best Practices topic, with the following subtopics:

• Maintaining Two Emergency Cloudadmin Accounts

• Enforcing AAL3 MFA for Cloudadmin Accounts

• Using a Hardware Security Module for the Master Encryption Key

• Always Using Federated Identity--Avoiding Local User Accounts

• Requiring MFA for All User Log Ins

• Enforcing Least Privilege Access

• Monitoring for Suspicious Activity

• Implementing a Disaster Recovery Site for Vault Access

The Cloudadmin Account

IBM Security creates the cloudadmin account for you, with the name formatted as cloudadmin@your_platform_tenant_name. It is the first account on the platform, and it has unlimited permissions across the platform and Verify Privilege Vault Cloud. When you are signed in as cloudadmin, you will perform initial provisioning, login, and setup tasks that include installing the IBM Security AD Connector, authorizing domain user accounts, assigning your own business domain user account to the System Administrator group. Please refer to Maintaining Two Emergency Cloudadmin Accounts in Platform Security Best Practices.

Other Administrator Accounts

After you create the Platform Admin account, you can create additional administrator accounts with permissions tailored to specific purposes.

Provisioning a Platform Tenant

1. Contact a Delinea sales representative to request a trial platform account.

2. When your trial is approved, you receive an email with the subject line, Welcome to Your Delinea Trial – Let's Get You Started.

3. To start provisioning your platform tenant, click the Begin Setup link in the email. This link is valid for 30 days.

4. The link launches the provisioning flow in your browser.

5. Follow the steps in the provisioning flow to complete your platform tenant setup.

6. When provisioning is complete, you receive an email with the subject line, You have been invited to the tenant-name tenant on Delinea Platform.

7. Click Accept Invitation to complete the setup of your cloudadmin account.

Secure your cloudadmin account as soon as setup is complete. Enforce AAL3-level multi-factor authentication using a hardware device such as a FIDO2 key or YubiKey, and avoid relying on this account for day-to-day work. For more information, see Platform Security Best Practices.

If you don't receive one or more of these emails from Delinea, see Onboarding Troubleshooting for guidance.

Not all platform features are available by default. To trial features like ITP/PCCE or Privilege Control for Servers, contact your sales representative to have these enabled in your tenant.

Enabling Domain Users to Log into the Platform

To enable domain users to log in to the platform, use one or both of the following options. You can then define security policies, assign them to platform identity groups, and map your existing domain groups to the platform identity groups.

• Installing the IBM Security AD Connector and Authorizing AD Accounts

• Adding Federated User Accounts

Installing the IBM Security AD Connector and Authorizing AD Accounts

To add Active Directory user accounts to the platform, you must install the IBM Security AD Connector. For complete instructions on downloading, installing, and registering the Connector, see Active Directory Connector.

The basic steps for installing the IBM Security AD Connector are as follows.

1. Download the connector executable file by clicking Settings from the left navigation, then selecting Connectors.
2. On the Connectors page, click Add Connector.
3. In Box 1 on the Add connector page, click Download to get the 64-bit Connector Installer.
4. In Box 2, copy the tenant URL, and save it for later.
5. Generate or copy a connector Registration Code, and save that for later too.
6. In the Connector Configuration Wizard, select the box next to Use Registration Code and paste the code that you saved earlier into the field provided. The Connector Configuration Wizard, similar to a Distributed Engine in Verify Privilege Vault, will read the forest and automatically display a list of forest domains that you can connect to the platform.
7. Select any domain where your users will be logging in from.
8. Make sure to include the domain that your own business user account belongs to.

To map Microsoft Entra ID groups to platform groups, see Integrating Entra ID.

Assigning Your Business Domain User to the System Administrator Group

After you have authorized Active Directory accounts on the platform, including your own personal domain account, you need to assign standard Administrator permissions for platform and Verify Privilege Vault to your personal domain account, while logged in as cloudadmin.

1. Click Access from the left navigation, then select Groups.
2. Click the System Administrator group.
3. Click the Members tab.
4. Click Add members.
5. In the Search dialog, change the first filter to Users and change the second filter to your connected domain. Now the search will find users from your connected domains.
6. Find your own Platform Admin domain account and add it to the System Administrator group. Through your membership in this group, your account automatically inherits the Platform Admin role with appropriate permissions on the platform.

Synchronizing the System Administrator Group to Verify Privilege Vault

1. Click Settings from the left navigation, then select Administration below Verify Privilege Vault.

2. On the Secrets Administration page, click Platform Upgrade.

3. Select the Groups tab.

4. Add the platform System Administrator group to the list of synchronized groups. Verify Privilege Vault automatically creates a corresponding Verify Privilege Vault group that is synchronized to the platform group.

5. Add a role with Verify Privilege Vault administrator permissions to the new enabled platform System Administrator group. Your platform System Administrator account now has Verify Privilege Vault administrator permissions through its membership in the synchronized Verify Privilege Vault group.

Accessing Secrets as a System Administrator

After you have assigned your business domain user to the system administrator group and synchronized the system administrator group to a Verify Privilege Vault, you can access secrets from the platform using your System Administrator account.

1. Log out of the platform as Cloudadmin.
2. Log back into the platform using your System Administrator account.

3. On the platform Home page, click Access Your Secret Server. The All Secrets page opens, where you can view, create, and manage your secrets.

For more on how to use and manage your secrets, see Using Secrets.

Adding Federated User Accounts

Unlike Verify Privilege Vault Cloud users, federated Verify Privileged Identity Platform users are added to the platform "on-the-fly" when they log in, as long as they satisfy the authentication requirements through an external source such as AD or a federation service provider. Users do not need to be authorized or granted permissions in advance. Users that exist in external sources will not be listed on the platform at Access >Users until they log in to the platform for the first time.

The platform does not natively support bulk import and synchronization of all users from an external source such as federation or AD. Platform administrators can find AD users to add to the platform by performing filtered searches through external AD directories, but federated directories cannot be searched.

To integrate federation Identity Provider (IdP) services on the Verify Privileged Identity Platform, see Federation.

To manage federation IdP services on the platform, see Federation Management. Also see Group Mapping Troubleshooting.

About Local User Accounts

Adding local users to the platform is not considered a best practice for privileged access management. Generally, users should be added to the platform only through federation or through their membership in an Active Directory. Local user accounts should be used only rarely. For example vendors are added as local accounts, and you might need to add a local user account for someone who needs to try out platform functionality for a very limited time.

Local accounts cannot be converted to domain accounts.

(for customers upgrading from Verify Privilege Vault only) After the Connector is installed and Active Directory is set up on the platform, do not add an existing Verify Privilege Vault Cloud user as a local user, because doing so could cause synchronization issues between the platform and Verify Privilege Vault.

To add a new local user, see Adding Users.

Assigning Roles and Permissions to Users and Groups

On the Verify Privileged Identity Platform, permissions are assigned to roles, and roles are assigned to groups, so users inherit permissions through their group memberships. The platform supports custom roles and the following two built-in roles, which cannot be renamed or deleted:

• Platform User: All platform users belong to the Everybody group, and through that group membership they inherit the Platform User role. The Platform User role provides the user with basic permissions to log in to the platform, access their secrets, launch PRA sessions, and view their own session recordings.

• Platform Admin: Platform users added to the System Administrator group inherit the Platform Admin role through that group membership. The Platform Admin role provides all permissions on the platform.

  User roles and permissions are managed by clicking Access from the left navigation, then selecting Users, Groups, or Roles.

  For more detailed instructions on managing roles and permissions on the platform, see User Roles and Permissions.

Setting up the Platform Engine

The Platform Engine manages and protects endpoints using small software packages called Engines that handle the orchestration of IBM Security services called workloads. The platform’s Engine Management feature provides administrators with a single interface for managing these engines and workloads, which are automatically updated and maintained after installation — removing the need for separate installers and management processes traditionally necessary on individual machines.

The engine is required when you want to:

• Integrate with on-premises Active Directory

• Run advanced discovery (CID, AD Rapid Discovery)

• Use Privilege Control for Servers (PCS)

• Enable Privileged Remote Access (PRA) to on-prem targets

If you’re only using Verify Privileged Identity Platform for cloud-based vaulting, SSO, or simple user/group management, you may not need the Platform Engine at all.

The Platform Engine is not the same as the Verify Privilege Vault Distributed Engine, which runs Verify Privilege Vault operations such as discovery, heartbeat, and remote password changing. See Setting Up a Distributed Engine.

Setting Up a Distributed Engine

A Distributed Engine is a Verify Privilege Vault component that you install on a server inside your network. It allows Verify Privilege Vault Cloud to reach resources that are not directly accessible from the cloud. The engine performs work such as discovery scans, heartbeat, and remote password changing against your on-premises targets.

Set up a Distributed Engine when you want to:

• Run Secret Server Discovery against on-premises or network resources

• Rotate passwords and run heartbeat against on-premises targets

The basic steps for setting up a Distributed Engine are as follows.

1. Click Settings from the left navigation, then select Administration below Verify Privilege Vault.
2. On the Secrets Administration page, search for and select Distributed Engines.
3. Create a site, then download the engine installer.
4. Install the engine on a server inside your network that can reach your target systems.
5. Activate the new engine and assign it to your site.

For complete instructions, see Distributed Engines in the Verify Privilege Vault documentation.

Delinea plans to transition Distributed Engine capabilities to a workload on the Setting up the Platform Engine . This section will be updated when that transition completes.

Secret Server Discovery

Verify Privilege Vault Discovery scans your environment to find accounts and their dependencies, such as scheduled tasks, application pools, and services. Discovery then imports the accounts into Verify Privilege Vault as secrets, so you can vault and manage them.

Discovery supports Active Directory, ESX/ESXi, Amazon Web Services (AWS), Google Cloud Platform, and Linux/Unix sources. You can extend Discovery to other account types using custom PowerShell scripts.

The platform offers two discovery capabilities:

• Verify Privilege Vault Discovery finds accounts and dependencies in your infrastructure, including Windows local and domain accounts and Linux/Unix accounts.

• Continuous Identity Discovery (CID) identifies privileged cloud service users that are not yet vaulted in Verify Privilege Vault Cloud. See Setting Up Continuous Identity Discovery.

Scanning on-premises networks requires a Distributed Engine. Set one up first. See Setting Up a Distributed Engine.

To open Discovery:

1. Click Settings from the left navigation, then select Administration below Verify Privilege Vault.
2. On the Secrets Administration page, search for and select Discovery.

Then enable Discovery and follow the instructions in Secret Server Discovery to create a discovery source, assign it to a site, and run a scan.

Setting Up Continuous Identity Discovery

Continuous Identity Discovery (CID) continuously identifies privileged cloud service users that are not yet vaulted in Verify Privilege Vault Cloud. We recommend vaulting these accounts in Verify Privilege Vault to enforce proper login, or disabling the user if access is unnecessary.

To discover privileged accounts not managed in Verify Privilege Vault, select Identity Posture > Checks and review the following checks:

• Unvaulted Admin Credentials
  Discover cloud service administrators whose credentials are not in Verify Privilege Vault.

• Unvaulted Shadow Admin Credentials (for CSP only)
  Discover cloud service shadow admins whose credentials are not in Verify Privilege Vault.

• Unvaulted Privileged Account Credentials
  Discover privileged cloud service user accounts whose credentials are not in Verify Privilege Vault.

• Unvaulted Admin Access Keys (for AWS only)
  Discover cloud service administrators whose access keys are not in Verify Privilege Vault.

• Unvaulted Shadow Admin Access Keys (for AWS only)
  Discover cloud service shadow admins whose access keys are not in Verify Privilege Vault.

• Unvaulted Privileged Account Access Keys (for AWS only)
  Discover privileged cloud service user accounts whose access keys are not in Verify Privilege Vault.

For details, see Continuous Identity Discovery.

Setting Up and Using Privileged Remote Access

IBM Security Privileged Remote Access (PRA) provides seamless access to remote machines through Remote Desktop Protocol (RDP) and Secure Socket Shell (SSH), with no need for a Virtual Private Network (VPN).

Installing an engine with PRA capabilities: 

Before adding an engine with PRA capabilities, make sure you meet the minimum requirements. See Server Hardware and System Requirements.

1. Navigate to the Engine Management page.

2. Click Create Site.
3. Follow the instructions at Creating a Site.
4. Follow the instructions at Adding a Platform Engine.

Launching a PRA Session

To launch a PRA session from the Verify Privileged Identity Platform:

1. From the left navigation menu, select Secret Server.
2. On the All secrets page, locate a secret associated with PRA.
3. Hover your cursor near the right end of the Name field.
4. Click the rocket (launch) icon. The Select Launcher window pops up.
5. Select Open with Remote Access. A new browser tab opens, where you can launch a PRA connection to a remote machine.

For more detailed instructions on using the Privileged Remote Access, see Using Privileged Remote Access.

About Multi-factor Authentication

The platform provides cloud-based, flexible multi-factor authentication (MFA) as powerful as many retail MFA products and services. All administrators and business users on the platform should be required to use multi-factor authentication (MFA) to log in.

Platform MFA has two components: Authentication Profiles and Identity Policies.

• An identity MFA profile determines which MFA challenges are presented to a user (see Creating Authentication Profiles).

• An identity MFA policy determines whether and when a user is presented with the challenges in their assigned MFA profile (see Creating Identity Polices).

More information about MFA on the platform can be found in the following sections:

• MFA for Secrets. Multi-factor authentication (MFA) for secrets gives platform administrators the option to add one or more security requirements to access defined secrets.

• Creating Identity Policies. Enabling MFA on the platform requires setting up identity policies and assigning them to users. An identity policy determines whether and when a user is presented with the challenges specified in the associated MFA profile.

• Creating Authentication Profiles. Enabling MFA on the platform requires setting up authentication profiles. An authentication profile specifies the authentication challenges required to log in to the platform, and the length of time that must elapse before a user is re-prompted for authentication.

• Configuring Corporate IP Ranges. The Corporate IP Range function is used to define IP ranges for both internal and external networks, and to define authentication requirements such as the locations or IP ranges from which users can log in to the Verify Privileged Identity Platform.

• RADIUS Authentication. You can use your RADIUS server to authenticate users to the Verify Privileged Identity Platform.