CyberArk Managed Security Service Provider Solution Implementation Guide

CyberArk Managed Security
Service Provider Solution

Implementation Guide
Version v9.10
Copyright © 1999-2017 CyberArk Software Ltd. All rights reserved.

This document contains information and ideas, which are proprietary to CyberArk
Software Ltd. No part of this publication may be reproduced, stored in a retrieval system,
or transmitted, in any form or by any means, electronic, mechanical, photocopying,
recording, scanning, or otherwise, without the prior written permission of CyberArk
Software Ltd.
MSSP-9-10-0-1
2 Table of Contents
Table of Contents
PAS Offering for Managed Security Service Provider 5

Overview 6
Features 6
Architecture 7
Managed Secure Service Provider 9
System Requirements 10
Recommended Server Specifications 10
Install the Multi-Tenant Vault 12
Harden the CyberArk Vault 12
Vault Installation Requirements 12
Before Installation 13
Install the CyberArk Vault Server 16
Install the PrivateArk Administrative Client 20
Following Installation 27
Create a Test Environment in the Vault 27
Install the First CPM 31
Considerations 31
Installation 32
Following CPM Installation 40
Test CPM Installation 43
The Central Policy Manager Environment 44
Install the Multi-Tenant PVWA 48
Considerations 48
Installation 50
Following the Installation 58
Install Multiple PVWAs 60
Test PVWA Installation 62
Test CPM installation in PVWA 63
The Password Vault Web Access Environment 65
Vault Backup Solution 72
Backup Considerations 72
Use the CyberArk Backup Process 73
Install the Vault Backup Utility 76
Using a Third Party Backup System 85
Backup Guidelines 87
Disaster Recovery Site 88
Installation 88
Following the Installation 92
Test the DR Vault Installation 94
Reset the DR Vault 94
Amazon Web Services (AWS) 95
Security Considerations 95
Installation 96
Managed Security Service Provider

Table of Contents 3
Authenticate to the Privileged Account Security Solution 99

Define Authentication Methods in PVWA 99
CyberArk Password Authentication 100
LDAP Authentication 102
RADIUS Authentication 104
Install the MSSP 111
Convert to a Multi-Tenant Vault 111
Configure User Management via LDAP 118
Configure Transparent User Management 118
Configure the Vault to Recognize Multi-lingual External Directories 123
Synchronize External Users and Groups in the Vault with the External
Directory 123
Upgrade the MSSP to v9.10 126
Before upgrade 126
Upgrade 126
Following upgrade 129
Convert Customer Authentication from LDAP to RADIUS 130
Customer Management 132
System Requirements 133
Recommended server specifications 133
Install the CPM for customers 134
Privileged Session Manager for Customers 136
Considerations installing PSM 136
Pre-installation tasks 140
Install the Privileged Session Manager 144
Post installation tasks 153
Harden the PSM server 162
Move PSMConnect and PSMAdminConnect Users to your Domain (Optional) 186
Privileged Session Manager Environment 205
Add Customers 207
Before Creating Customers 209
Create a customer 210
View customer details 213
The Customer Environment 214
Safes 214
Platforms 214
Password Upload Utility 216
Log on to the MSSP 217
Disable Customers 218
Extracting Content for Customers 219
Generate Customer Reports 221
Ongoing Customer Maintenance 222
Add New Safes for Customers 222
Add New Platforms for Customer Workflows 222
Auditing 223
MSSP REST API 226
Add Customer 227
URL 227
Resource Information 227

4 Table of Contents
Header parameter 227

Body parameters 227
Disable Customer 232
URL 232
Body parameters 232
Result 233
List Customers 233
URL 233
Result 234
Get Customer Details 236
URL 236
Result 236
Return Codes 238
Add RADIUS Server 239
URL 239
Body parameters 239
Return Codes 240
Customer End User Guide 241
Onboarding Accounts 242
Safe Members 243
Add Safe members 246
Add Safe members from LDAP 248
Manage Safe members 249
Troubleshooting 251
Appendices 252
Daily Activities 253
CreateCredFile Utility 255
Credential File Security 255
Specify Applications 256
Create User Credentials Files 256
Create the User Credential File for Password Authentication 264
Create the User Credential File using a Token 265
Create the User Credential File for PKI Authentication 266
Create the User Credential File for Proxy Authentication 267
Password Upload Utility 269
Implement the Password Upload Utility 269
Run the Password Upload Utility 277
Vault Parameter File 278

5
PAS Offering for Managed Security

Service Provider
CyberArk's PAS offering for MSSP enables you to provide Privileged Accounts Security
services to customers.
This section explains the architecture that enables you to benefit from CyberArk's secure
environment in a shared managed service environment.
In this section:
Overview

CyberArk Managed Security Service Provider Solution Implementation Guide 6
Overview
CyberArk's PAS offering for MSSP enables Service Providers to provide Privileged
Account Security services to their customers to enrich their security posture with a 'best
in breed' solution. This offering is easy to install and deploy, while providing a secure
environment for managed privileged accounts. This version was designed specifically for
MSSP with cost effective ROI in mind, so that MSSP can leverage the CyberArk platform
and scale it to their customers.
Features
CyberArk has introduced a multi-tenancy architecture with the following highlights, in
addition to its existing capabilities:
MSSP provides the following features:
Feature Description
Customer Through a dedicated area in the web console, you can add or disable
management customers.
General Create a centralized overview of the security and compliance policy of

policy privileged accounts that are managed in the MSSP, and configure
management compliance driven rules that are defined as the baseline for customers.
To reduce management and maintenance costs, by default, the same
policy is enforced for all customers making it easy to manage. There is
also an option to define a specific policy for a customer in case
exceptions are required.
Inventory To support your billing processes and streamline maintenance

report procedures, view an inventory report of all customers' accounts .
The MSSP version uses CyberArk's patented Digital Vault as a secure repository where
customers store their privileged accounts. The Multi-Tenant Vault enables the MSSP to
provide secure services to multiple customers, while totally segregating them and
protecting their privacy at the highest standard. Customers who use this offering to store
privileged accounts in the Digital Vault benefit from CyberArk's Central Policy Manager
(CPM) and Privileged Session Manager (PSM) to facilitate automatic management and
monitoring.

7 Overview
Architecture
The Multi-Tenant Privileged Account Security architecture provides a multi-tenant
managed environment where your customers' privileged accounts can be securely
managed, transferred, and shared by authorized users, such as IT staff, on-call
administrators, and local administrators in remote locations.
The Multi-Tenant Digital Vault integrates with other CyberArk components, such as the
Central Policy Manager (CPM) and the Privileged Session Manager (PSM), and also
supports most of the supported complementary Vault services, such as Disaster
Recovery, High Availability and others. A dedicated security layer that ensures complete
tenant segregation hosts multiple tenants side by side, but they are not aware of each
other and can only access their own data.
High level architecture

The following diagram shows the different components of the MSSP solution and how
they interact:
The Multi-Tenant Digital Vault, Password Vault Web Access (PVWA), and other
complementary Vault services are deployed in the Service Provider's environment, while
the CPM and PSM are deployed in the customer's (tenant) environment. After
deployment, the CPM and PSM communicate with the Vault over the Internet, using
CyberArk's secure Vault Protocol.
PVWA is publicly available over the Internet, and is accessible to both the service
provider and customers.
Note:The Service Provider is responsible for ensuring secure access to

their environment.

Security and multi-tenancy

Multi-tenancy in the Multi-Tenant Digital Vault is based on the Vault's built-in Locations
security mechanism, which limits users from a specific Location to accessing only
associated data. A specific location represents a customer who has a defined list of
associated Safes and users. Each Safe belongs to single location, thus ensuring
complete customer segregation.
The service provider administrator can see all the customer locations in the Vault, and
has permission to add customers, customer users and Safes, while customers can only
see and access Safes in their own location.

9
Managed Secure Service Provider
In this section:
System Requirements
Install the Multi-Tenant Vault
Install the First CPM
Install the Multi-Tenant PVWA
Vault Backup Solution
Disaster Recovery Site
Amazon Web Services (AWS)
Authenticate to the Privileged Account Security Solution
Install the MSSP
Configure User Management via LDAP
Upgrade the MSSP to v9.10

System Requirements
This section lists the specifications for the servers used in CyberArk's PAS offering for
MSSP and the required Customer (tenant) server.
The CyberArk platform that is installed on the MSSP site requires the following servers:
■ Multi-tenant Vault Server
■ High Availability Vault Server (optional)
■ DR Vault Server (optional)
■ Central and multi-tenant PVWA
■ CPM
For security and performance reasons, CyberArk recommends installing Vault
instances on physical hardware or approved Cloud Instances (AWS or Azure).
Recommended Server Specifications

This section summarizes the recommended hardware and software specifications for the
required servers when implementing CyberArk’s MSSP Privileged Account Security
(PAS) solution.
Vault and DR Vault Servers

The following specifications list the requirements for the CyberArk Digital Vault that is
installed in the Service Provider's environment.
The Vault is multi-tenanted and currently supports up to 100,000 managed accounts or
15 customers. The recommended specifications for standalone Vault servers and
standalone DR Vault servers are listed below.
Software specifications
■ Windows 2012 R2
■ .NET Framework 4.5.2
Hardware specifications
■ 4X Eight core processors (Intel compatible)
■ 64GB RAM
■ 2X 500GB SAS hot-swappable drives (15K RPM)
■ RAID Controller
■ Network adapter (1Gb)
■ DVD ROM
■ Additional storage for PSM recordings
Supported Cloud platforms
■ Amazon Web Services (AWS)
■ Microsoft Azure

11 System Requirements
Central PVWA and CPM

Servers software specifications
■ Windows 2012 R2
■ IIS 7.5 or 8.5
■ .NET Framework 4.5.2
■ Chrome 47 and higher
■ 4X Eight core processors (Intel compatible)
■ 64GB RAM
■ 2X 80GB SAS hot-swappable drives
■ RAID Controller
■ Network adapter (1Gb)
■ DVD ROM
Supported Cloud platforms
■ Amazon Web Services (AWS)
■ Microsoft Azure
Recommended resolution
■ 1920x1080

Install the Multi-Tenant Vault

This section describes how to install CyberArk's Multi-Tenant Vault in the PAS offering
for MSSP. The installation must be performed in the order listed below.
In this section:
Harden the CyberArk Vault

CyberArk installs the Vault Server on a hardened operating system, based on Microsoft
Bastion Host server recommendations which define a highly secured Windows server.
The hardening process is performed as part of the Vault installation and results in
disablement of many operating system services. The hardened Vault Server is designed
to serve only CyberArk protocol requests. As such, it may not function as a regular
domain member in a Windows network. In addition, the hardening process also strips the
permissions from existing and built-in Windows users (except the user that runs the
installation).
For more information, refer to the Windows Server 2008 Security Guide:
https://technet.microsoft.com/en-us/library/cc264463.aspx
Vault Installation Requirements

Before installing the Vault, make sure that you have the following:
Vault Installation Package
You will receive the Vault installation package from your CyberArk support
representative. The installation package contains the following:
■ The CyberArk Vault installation CD
■ Master CD
■ Operator CD
■ License file
■ Installation documentation
Server Resources
In the environment planning stage, you should have determined the resources that
you require to install the Enterprise Password Vault. As each Vault must be
installed on a dedicated server, make sure that you have the required number of
dedicated servers for the number of Vaults that you will install. This is essential for
file security, as the Vault uses a unique protocol and prevents all incoming or
outgoing communication, except legitimate Vault communication.
If you plan to install a Password Vault cluster for a High-Availability implementation,
make sure that you have a dedicated server for each node in the cluster. For details
about specific requirements for a High-Availability Enterprise Password Vault, see
High Availability.

13 Install the Multi-Tenant Vault
Before Installation
Before you install the Vault, prepare the machine where it will be installed and check the
following:
Server requirements
Check the Vault server machine has the requirements as listed in Digital Vault Server.
Vault location on hard drives

Check the Vault server hard drives and decide where to install the CyberArk Vault, and
where the Safes will be installed. These locations should be in separate folders. It is
recommended that you install the Safes on an NTFS drive so you can control the
permissions.
The recommended size of the partition is double the average size of the Safes (the data
size).
Make sure that the Vault machine is part of a local Workgroup and not part of a Domain.
Preparation for backup

If you are planning to backup your Vault using a third party backup application, create a
Backup User on the Vault machine and install your backup application on this machine
before installing the CyberArk software. For details, see Vault Backup Solution, page 72.
Customer license
Your CyberArk support representative will supply the license file that you will need for
installation.
Note:Until you receive your Customer license, you will not be able to install the
CyberArk Vault Server.
Preparation of CyberArk Vault Keys

The Keys for the Vault (Server Key and Recovery Public Key) are stored on the Operator
CD. These keys are required during installation and each time the server is restarted.
After startup, remove the CD and place it in a physical safe for security reasons.
If the Vault machine is in a secure physical location, you can copy the keys on the
Operator CD to the hard drive to enable the Remote Control feature to work without
needing to insert the Operator CD each time. It is highly recommended to store the keys
in a folder on an NTFS drive which is protected by OS Access Control.
Specify the following permissions to enable access to the NTFS drive:
Folder Group Permission
PAKeys Administrators Read/Write

Server Key storage on a Hardware Security Module (HSM)

If your implementation requires the Server Key to be stored on a Hardware Security
Module (HSM), gather the following information:
■ The IP address of the HSM device
■ The TCP/UDP ports used by the HSM device for communication
Administrator User
Only users with Administrator authorizations can install the CyberArk Vault. When you
install the Vault, log onto the Server computer as an Administrator user.
Configure the Vault Interface Language for Non-unicode Programs

Configure the Vault interface language for non-unicode programs so that you will be able
to create Safes, users, and files in multiple languages.
On the Vault machine, the IIS server, and the machine where you will install the
PVWA, do the following:
1. In the Control Panel, select Clock, Language, and Region, the Clock,
Language and Region window appears.
2. Select Region and Language; the Region and Language window appears.
3. In the Administrative tab, click Change system locale and select the
required language for the non-unicode programs.
4. Click OK; you will now be able to create Safes, users, and files in the
PrivateArk Client in English and in the language configured in the previous
step.
Preparation of the CyberArk Vault Server

The following preparations should be carried out by the Administrator user.
1. Install a clean Operating System or image with no third party software.
Note:It is essential to install a clean Operating System or image, and

not clean up an existing system. Do not install any additional software
2. Check that the Administrator password is appropriately strong. For example,

it should contain a minimum of 8 alphanumeric characters.
3. Check that the server machine has a static IP address.
4. In the Network Connection properties, clear Preferred DNS Servers
Note:DNS Connectivity is not possible for the Vault server, therefore no DNS
servers should be set.
5. Check the number of network cards, so that later you can verify that the Vault
has recognized them all.

6. Check that the server IP address is correctly configured, and that it is static.
7. Ping to a nearby address to check the network connection is working
correctly.
Note:It is important to verify the network connection before installing the

CyberArk Vault.
8. In the server machine BIOS security, set the Server machine’s boot
sequence to boot from the hard drive first.
Note:This is recommended for additional physical security.
9. Secure the Server machine BIOS by setting a password.

10. If DEP is supported on the Vault machine, enable it.
Note:For more information about implementing DEP, refer to Microsoft

documentation
11. Install a compatible version of Windows, as described in Digital Vault Server.

12. Uninstall all protocols, except the following TCP/IP protocols.
Note:This step is not relevant for High-Availability.
13. Reboot the Server.

Install the CyberArk Vault Server

This section describes the installation of the Vault Server.
In this section:
Install the Vault Remotely in an RDP Session

The Digital Vault can be installed remotely in an RDP session in the following RDP
environment:
■ RDP Client v5.2 and higher
In order to benefit from full functionality, use an RDP Console Session to install the Vault
on a remote machine.
After the RDP session described below is set up, follow the standard installation
procedure (see CyberArk Vault Server Normal Installation) .
Install the Vault Remotely in an RDP Session
1. Log onto the RDP console session using the Administrator user. Use the
original administrator user, called Administrator. Any other user or name will
not be able to install the Vault successfully over the RDP session.
2. Install the Vault as described in Install the CyberArk Vault Server, page 16.
3. When the installation wizard begins, the following message appears:
Note:
Make sure the message above appears; it confirms that the installation is being
installed over the RDP session. If the message is not displayed, the RDP
installation will not work as required and you will not be able to complete the
installation successfully.
Make sure you are aware of the security consequences of opening the Digital
Vault to the RDP protocol. For more information, contact your CyberArk
representative
4. Click Yes and continue installing the Vault according to the documented
procedure.
5. Click OK to continue and complete the Vault installation.
If the session is disconnected, reconnect to the RDP console session
and complete installation.
If you cannot reconnect to the RDP console session, you will only be able

to complete Vault installation by physically accessing the machine where

the Vault is being installed and completing the installation by direct
access.
Following Installation
Following Vault server installation, check the following things.
Services
Check that the following services have been installed and started
■ PrivateArk Database
■ PrivateArk Server
■ CyberArk Logic Container
■ Cyber-Ark Event Notification Engine
Vault started successfully
Check that the CyberArk Digital Vault started successfully
The Digital Vault’s service, called PrivateArk Server, starts automatically on startup.
Open the PrivateArk Server Management Console and check that it started successfully.
Make sure that the following message appears:

ITAFW001I Firewall is open for client communication
Configure HSM Key Management

After the Vault has been installed and has started successfully, you can move the Server
key to the HSM where it will be stored externally as a non-exportable key.
Encryption keys can be stored on the HSM device in either of the following ways:
■ Existing keys can be loaded onto the HSM device. For more information, refer to
Load the Server Key into the HSM, page 18.
■ New keys can be generated directly on the HSM device. For more information, refer
to Generate the Server Key in the HSM, page 19.

Initial Vault Configurations

1. To use an HSM that is attached to the network, configure the Firewall in
order to allow communication to the HSM device. In DBParm.ini, configure
the AllowNonStandard FWAddresses parameter to open the Firewall
and allow access to the HSM device, as shown in the following example:
AllowNonStandardFWAddresses=[HSM-
IP],Yes,1024:inbound/tcp,1024:outbound/tcp
2. Configure the PKCS#11 provider DLL and specify it in the

PKCS11ProviderPath parameter in DBParm.ini, as shown in the following
example:
PKCS11ProviderPath=<path to PKCS#11 provider dll>
3. Save DBParm.ini and close it.

4. Define the PIN/passphrase to be used by the Vault when accessing an HSM
device:
From a command line, run the following command, specifying your own
PIN/passcode that will be used to access the Server key:
CAVaultManager SecureSecretFiles /SecretType HSM /Secret
<hsmpincode>
Open DBParm.ini and make sure that the HSMPinCode parameter was added
with the encrypted value of the PIN/passcode.
5. Restart the PrivateArk Server to apply the new Firewall rules.
6. Shutdown the PrivateArk Server.
Load the Server Key into the HSM
The following process installs and stores the Server key on the HSM device. Once this
process is complete, the server key is stored as non exportable key on the HSM and will
be used by the Vault.
Install key on HSM device
1. Make sure that the Vault Server is not running.
2. Load the Server key to the HSM device:
a. On HSM devices that don’t require the key to be encrypted, from a
command line, run the following command:
CAVaultManager.exe LoadServerKeyToHSM
b. On HSM devices that do require the key to be encrypted, from a

command line, run the following command:
CAVaultManager.exe LoadServerKeyToHSM /WrapKey
This will generate a new key pair. The public key will be used to encrypt the
server key, and the private will decrypt it on the HSM device.
3. Make sure that the result confirms that the Server key has been loaded to the
HSM.

4. In DBParm.ini, change the value of the ServerKey parameter as follows:

ServerKey=HSM
5. Start the PrivateArk Server and make sure you can log on to the Vault.
The Server key has been successfully moved to the HSM and will be used for all
relevant CyberArk Vault operations.
Generate the Server Key in the HSM
1. Make sure that the Vault Server is not running.
2. Run the CAVaultManager command to generate the server key on the
HSM:
CAVaultManger GenerateKeyOnHSM /ServerKey
The above command will generate a new key for the Vault server and store it in
the HSM device, and will return the key generation keyword. For example:
HSM#5
Each time a key generation is created, the keyword allocated is one number
higher than the current server key generation specified in DBParm.ini. The
HSM can store up to 255 key generations, after which key generation
numbering will begin again at one. In order to create additional key generations
successfully, users have to manually delete the first generation of the server
key, otherwise an error will be returned. If the ServerKey parameter in the
CAVaultManager command specifies a path instead of an HSM keyword, the
first key generation will be created, i.e., HSM#1.
3. Re-encrypt the Vault data and metadata with the newly generated keys on
the HSM.
■ Run the ChangeServerKeys command to change the encryption keys that
will be used for the Vault server.
ChangeServerKeys PathToKeys PathToEmergencyFile
HSMKeyword
For example, the following command will re-encrypt the Vault data and
metadata with the encryption keys in ‘K:\PrivateArk\Keys’, and the ‘HSM#1’ key
will be used as the server key.
ChangeServerKeys K:\PrivateArk\Keys
K:\PrivateArk\Keys\VaultEmergency.pass HSM#1
4. Open DBParm.ini and in the ServerKey parameter specify the value of the
key generation version that was generated and specified in the output of the
CAVaultManager command above, as shown in the following example.
ServerKey=HSM#1
5. Start the Vault server and make sure you can log onto the Vault.

Install the PrivateArk Administrative Client

The PrivateArk Client is the administrative interface to the EPV. After installing the Vault
server, install the PrivateArk Client on the Vault server machine so that you can configure
the Vault.
Before beginning the installation, logon as the Administrator user.
Install the PrivateArk Administrative Client
1. In the installation folder that you copied to the local drive from the installation
CD at the beginning of Install the CyberArk Vault Server, page 16, display
the contents of the Client folder.
2. Start the installation procedure:
■ Double-click Setup.exe
or,
■ On systems that are UAC-enabled, right-click Setup.exe, then select Run
as Administrator.
The PrivateArk Client installation process begins and the PrivateArk Client
Setup window appears, as shown below.
Note:
You can exit the PrivateArk Client installation at any time by clicking Cancel. You
can return to the previous installation window by clicking Back, where applicable
3. Click Next to proceed to the next step of the PrivateArk Client installation,
which enables you to view the License Agreement and accept its terms, as
shown below.

4. Read the license agreement, then click Yes to accept its terms and proceed
to the next step of the installation, which enables you to enter user
information for licensing purposes, as shown below.
5. In the Name field, enter your first and last name.

6. In the Company field, enter the name of your organization.
7. Click Next to proceed to the next step of the installation, which enables you
to select the folder on your computer in which the PrivateArk Client
application files are to be located, as shown below.

8. Click Next to accept the default location provided by the installation,

displayed in the Destination Folder area, and proceed to the next step of
the installation,
or,
Click Browse and select another location, then click Next to proceed to the next
step of the installation.
9. Select the setup type for your Client installation, as shown below.
10. Select Typical to install all default Client interface components, including the
Microsoft Office extensions, and proceed to step 12,
or,
Select Custom to select from among several application components, as
shown below.
Note:

Custom installations are not relevant for a PrivateArk Client installation on the
Vault server machine
11. Select the options that you require, then click Next; the following window
appears if one or more Microsoft Office applications are active during
installation. Click OK, then close all Microsoft Office applications, and
continue installation.
12. If you selected Custom in step 9, you can now select the type of Client
configuration to implement. To use Global Configuration, select Use Global
Configuration, then either specify the location of the ini file or select
Registry to indicate where the Global Configuration information will be
stored.

Note:
For more information on using global configuration, refer to the Privileged
Account Security Implementation Guide
13. Click Next to proceed to the next step of the installation which enables you to
specify a name to be used for the PrivateArk folder in the Windows Start
menu, as shown below.
14. In the Program Folders field, enter a name for the PrivateArk folder in the
Windows Programs folder, then click Next,
or,
Click Next to accept the default PrivateArk folder name.
The installation is now carried out according to the specifications that you have
selected, then the following window appears.

15. Click OK to display the New Server window and define a new Vault,
or,
Click Skip to complete installation, as described in step 16, without defining a
Vault.
16. In the New Server window, define the new Vault:
a. Enter the name of the Vault and the workstation’s IP address.

b. In the Default User Name edit box, type the name of the User whose
name will appear by default in the Logon
c. Click Advanced to display the Vault Properties - Authentication dialog
box, and define the authentication parameters required by the Vault. The
Vault authentication methods are configured during Vault installation.
For more information, contact your system administrator.
d. Click the Connection tab to display the Connection dialog box and set
the port parameters.
e. Click OK to create the new Vault and complete PrivateArk Client
installation.
For more detailed information about defining a Vault, refer to the Privileged
Account Security Implementation Guide.
17. When the installation is complete, the following window appears to enable
you to restart your computer.

18. Select Yes, I want to restart my computer now and click Finish to
complete PrivateArk Client installation.
The installation automatically updates the Windows Start menu, places a
PrivateArk Client shortcut icon on the desktop, and updates the computer registry
information.
Note:
You are required to restart your computer in order to work with the PrivateArk
Client.
Caution:
Place the Master password and the Master CD in a safe physical location for
use in an emergency.

After installing the PrivateArk Client, you can access the Vault to perform administrative
tasks. The following instructions describe how to log onto the Vault and configure it for
use.
Log onto the Vault

In the PrivateArk Client, log onto the Vault as the Master user using the password that
you specified during Vault server installation. This ensures that you know the Master
password, and that in an emergency you will be able to log onto the Vault with the Master
user.
The Master User has complete control over the entire system, and can manage full
recovery when necessary.
The Master User can only log onto the Vault from the Server terminal. In addition, he can
only log on with the Master CD which contains the Private Recovery Key.
Limit access to specific networks

During installation, the Vault is configured to enable access from any network location.
To enable network locations access restrictions, configure the Network Areas as
described in the Privileged Account Security Implementation Guide.
Create a Test Environment in the Vault

After checking the Vault server installation by logging on through the PrivateArk Client,
you can create a test environment so that you can test the rest of the installations that
comprise the EPV environment. The following instructions describe how to create a test
environment that you will be able to use throughout the entire installation procedure.
Before you begin to create a test environment in the Vault, log on as the Administrator
user. This will ensure that you have all the authorizations in the Vault that you need to set
up this environment.
Create a location
Create the first location in the Vault hierarchy.
1. From the Tools menu, select Administrative Tools, then Locations; the
Locations window
2. Click Add; the Add Location window appears.

3. In the Name edit box, type the name of the new location, then click OK; the
Manage Locations window appears and displays the new location.
You can now create and save Safes, Users and Groups in the new location. For
more information, refer to the Privileged Account Security Implementation Guide.
Create a password Safe

Create a Safe to use during testing, and where you will store all the keys and files that will
be used during installation for future reference, if necessary.
Create a Safe
1. Logon to a Vault as the Administrator user, then from the File menu, select
New, then Safe; the New Safe window appears, and displays the General
tab which is mandatory.
2. Specify the name for this Safe. As this is the testing environment, in the Safe
name edit box, specify PIM-Internal
3. In the Authorized Area tab, select Public Locations (Internet) and
Unsecured Network Areas, then click OK.
For more information about creating Password Safes, refer to the Privileged Account
Security Implementation Guide.
Create a Vault user for testing

Create a user with Vault administration authorizations that will be used for testing
installations and upgrades. After the Enterprise Password Vault environment is ready for
implementation, you can either use this user for administrative tasks, or delete it.
Note:
Use a user that appears in the organization directory. This will enable you to utilize this
user for testing all the Enterprise Password Vault components
Create vault user

1. From the Tools menu, select Administrative Tools and choose Users
and Groups. The Users and Groups window appears.
2. In the hierarchy, select the Location where the user will be, then click New,
and select User; the New User window appears.
3. In the General tab:

■ In the User Name edit box, enter the user’s name.

4. In the Authentication tab:
■ The default Authentication method is Password.
■ In the Password edit box, specify a password for the user, then confirm it.
■ Clear User Must Change Password at Next Logon.
Note:
For security reasons, this password must be changed after testing
5. In the Authorization tab:

■ Select all the authorizations. This will enable the user to test all the different
features of the Vault.
6. In the Member of tab:
■ In the ‘Available Groups’ list, select Vault Admins, and move this group to
the ‘Member of’ list.
7. Click OK; the Users and Groups window appears.
8. Click Close to create the user.
Add the Vault Admins Group to the PIM-Internal Safe

Add the Vault Admins group as an owner of the PIM-Internal Safe with full
authorizations.
1. Open the PIM-Internal Safe, then click Owners on the PrivateArk toolbar;
the Owners window appears.
2. Click Add; the Add Owners dialog box appears.
3. Select the Vault Admins group, then click the arrow to move the group to
the Selected User(s) field.
4. Select all the Safe owner authorizations.
5. In Preferences, clear Retrieve for read-only as default.
6. In Ownership expires on, select Never, then click OK; the Administrators
group is added to the PIM-Internal Safe as an owner with the authorizations
that you have set.
Create Password Objects in the PIM-Internal Safe

In the PIM-Internal Safe, create the following password objects:
■ Local Windows Administrator – This password is for the local Windows
Administrator account on the Vault server. Make sure that the password in the Safe is
the same as the password in the Windows Administrator account.
■ Administrator – This is the password of the predefined administrator user. Specify
the password that you defined in the Administrator’s user account.
■ User – This is the password of the user that you created for testing. Specify the same
password that you used when you created this user account.

Create a Password Object

1. Open the Safe and navigate to the folder where the new password will be
created and stored.
2. From the File menu, select New, then File; a list displays all the new objects
that you can create.
3. Select PrivateArk Protected Object, then Password; the New Password
Object window appears.
4. In the Object Name edit box, type the name of the password object. This can
be any name. For example, the name of the machine where the password is
used, or the name of the environment or service that it enables you to
access.
5. In the Password edit box, type the password for this password object.
6. In the Confirm Password edit box, type the password again, then click OK;
the password object appears in the list of objects in the Working Area.

31 Install the First CPM
Install the First CPM

This section describes how to install the first CPM in the MSSP environment. The
installation must be performed in the order listed below.
In this section:
Considerations
Security and Protection

As the CPM station is important in terms of availability and sensitive information handling,
its security is imperative.
■ Use the strictest organizational policy that will enable the CPM machine to function
properly, regarding physical access to the CPM machine, network access, access
control, auditing, monitoring, active services and relevant up-to-date security
patches.
■ The CPM machine should not have access to, or be accessible from, the Internet or
any other unsecured network in the organization.
Network Communication
The CPM uses a TCP connection to communicate with the CyberArk Vault. Therefore,
any type of network protection on the machine where the CPM is installed must allow
TCP communication with the Vault’s IP address. The default TCP port number for
communication to the Vault is 1858, but it is configurable.
The CPM must also be able to communicate with the remote machine where passwords
are changed. Specific network requirements differ according to the type of remote
machine where the passwords will be changed (Windows Domain, Linux, Oracle, etc.).
Multiple CPMs
The Privileged Account Security solution can work with multiple instances of the CPM
that access the same Vault. This enables you to work with the following scenarios:
■ Password management in different networks
■ Load balancing implementations
■ On the DR Vault:
■ Password management on the same Safes as the production Vault
■ Password management for systems in the DR site
■ The type of implementation determines where the CPM will be installed.
CPM Disaster Recovery
The CPM is supported in DR mode for when the primary CPM is unavailable, so that you
can manually failover to the DR CPM. This process is designed like an “Active-Passive”

cluster, meaning there is only one active instance of the CPM at any time. For details, see
Installing the CPM in DR mode.
Before Installation
During installation, Safes and a User are created to enable the CPM to work. In order for
the installation to create these successfully, the Vault user who will carry out the
installation must have the following authorizations in the Vault:
Add Safes
Add/Update Users
Reset Users’ Passwords
Activate Users
Note:
During Vault installation, an Administrator user is created with these authorizations
especially for this type of activity. Use this Administrator user to install the CPM
Installation
The CPM can be installed in either of the following ways:
Standard installation – The user initiates installation and provides information
throughout the installation process in an intuitive installation wizard. For details, see
Standard installation, page 32 below.
Silent installation – The installation procedure is initiated either by a user or by a
script, and is performed without any human interaction. For details, see Silent
Installation, page 38.
Before beginning installation, log onto Windows as the Administrator user.
Note:
The Windows service for the CPM component is CyberArk Password Manager.
Standard installation
Standard installation
1. On the CPM machine, create a new folder and copy the Central Policy
Manager folder from the installation CD to it.
or,
as Administrator.
The installation process begins and the Setup window

3. If you have not already closed any open Windows applications, it is strongly
advised that you do so at this point.
Note: You can exit installation at any time by clicking Cancel. You can return to the
previous installation window by clicking Back, where applicable.
4. Click Next to proceed to the next step of the installation.The CPM installation
wizard appears and displays a list of required features that it will install on
your computer before it can install the CPM.
5. Click Install to proceed to the next step of the installation, which enables you
to view the CyberArk license and accept the terms of the License

Agreement.
to the Customer Information window, which enables you to enter user
information.
7. Enter your name and Company name in the appropriate fields, then click
Next to proceed to the Destination Location window which enables you to

select the folder on your computer where the CPM will be installed.
8. Click Next to accept the default location provided by the installation, as

displayed in the Destination Folder area,
or,
Click Browse and select another location.
Click Next to proceed to the Setup Type window, which enables you to specify
whether or not the CPM was already installed on the Vault.
9. Select No Policy Manager was previously installed, then click Next to

proceed to the Vault Connection Details window where you specify the

connection details of the Password Vault.
10. Specify the IP address or DNS of the Password Vault, and its port number,
then click Next to proceed to the Vault’s Username window where you
specify the logon details of the Vault user.
11. Specify the name and password of the Vault user who will create the CPM
environment in the Vault, then click Next; the installation process will now
build the CPM environment in the Vault and on the CPM machine.
12. If you selected No Policy Manager was previously installed in step 9, but
there is already a user called PasswordManager in the Vault, the following

window will appear.
■ Accept the default CPM user name,

or,
■ Specify a different name.
In multiple CPM installations, a default user name is suggested for the new
CPM. Either accept the suggested name, or specify a different one.
Click Next to continue with the installation.
13. If you selected No Policy Manager was previously installed in step 9, but
the cpm.ini file already exists in the Vault, the following window will appear.
■ Click Yes to override the existing cpm.ini file,

or,
■ Click No to leave the existing cpm.ini file in the Vault.
14. The following window appears, prompting you to confirm whether or not to
install Oracle Instant Client as part of the CPM installation. This component is
required to enable the CPM to support password management features on

Oracle databases.
■ Click Yes to install the Oracle Instant Client,

or,
■ Click No to confirm that you do not want to install the Oracle Instant Client
and to complete the CPM installation.
The Oracle Instant Client enables the CPM to manage Oracle passwords. It
includes the ODBC driver and all other Oracle features that are required for
successful password management on remote Oracle databases.
15. After the CPM environment has been created, the Setup Complete window
appears.
Click Finish to complete the CPM installation.
Silent Installation
The CPM can be installed by the silent installation procedure described below.
Note:
Silent installation does not install the Oracle Instant Client, which is required to enable
the CPM to support password management features on Oracle databases. In order to
manage Oracle accounts, install the standard Oracle Client that is relevant for your
database version on the CPM machine

Before Installation
1. On the CPM machine, create a new folder for the CPM installation files.
2. From the CPM installation package, copy the following files to the new CPM
folder on your local machine:
■ vault.ini
■ createcredfile.exe
■ cassleay32.dll
■ calibeay32.dll
■ silent.iss
3. Open the vault.ini file and specify the details of your Vault server.
4. Run the CreateCredFile utility to create a credential file for the Vault user
who will create the CPM environment in the Vault. For more information
about creating credential files, refer to Creating Credential Files.
Installation
1. In a command line interface, run the CPM installation, as shown below:
Setup.exe /s /f1"<path of the silent.iss file>"
/z"<installation parameters list>"
■ Make sure that there are no spaces between /f1 and /z and the values that
follow them.
■ Make sure that the paths of the silent.iss file and the files that will be
specified in the installation parameters list are the absolute paths for these
files and not relative paths.
The installation parameters list contains all the information required during
installation. The items in the list are separated by a semi-colon, and the entire
list is surrounded by quotation marks, as shown below:
"<your name>;<your company name>;<Destination folder>;<path
to Vault.ini>;<path to credential file>;<is this a new
installation on the Vault (Y/N)>"
To indicate a completely new CPM installation, specify Y in the last parameter of

the installation parameters list. However, if this installation is to re-install the
CPM, specify N.
When multiple CPMs are installed, the silent installation automatically creates
user names for all additional CPM users. For example, CPM1, CPM2, CPM3,
and so on. These user names cannot be changed.
The following example shows a typical installation command:
Setup.exe /s /f1"C:\installationfiles\silent.iss" /z"Paul
Black;My Company;
C:\Program Files\CyberArk\;C:\installationfiles\Vault.ini;
C:\installationfiles\admin.cred;Y"
In the above example, the installation will use the silent.iss file in the
C:\installationfiles folder. The name of the user performing the installation is
Paul Black, and his company is called My Company. The CPM will be
installed in C:\Program Files\CyberArk using the Vault parameter file stored

in C:\installationfiles, and a credentials file called admin.cred that is also

stored in C:\installationfiles. This is a new CPM installation, as indicated by
the Y.
1. Delete the credentials file used during installation.
2. During silent installation, the following log files are created:
■ Installation log file – A file called setup.log is created in the directory from
where the installation was executed. This file contains the Result Code of
the silent installation. Result Code 0 (zero) indicates that the installation was
successful.
■ Vault environment log file – A log file called CPMInstall.log is created in
the temporary folder. This file contains a list of all the activities performed
when the CPM environment in the Vault is created during the installation
procedure.
3. Check these log files to make sure that the CPM has been installed
successfully.
Following CPM Installation

During installation, several Vault objects are created to enable the CPM to access
existing passwords, generate new ones and replace them on a remote machine.
However, before the CPM can begin working, it is recommended to create a Trusted
Network Area for the CPM user to log onto the Password Vault.
Check the installation log files

During installation, a log file called CPMInstall.log is created to monitor the installation
process and to enable you to ensure that the Central Policy Manager was installed
successfully.
This log file is created in the Temp folder and it contains a list of all the activities
performed when the CPM environment in the Vault is created during the installation
procedure.
Other log files that are used for internal purposes are created in the same folder during
installation.
Check the CPM services

During CPM installation, the following services are added:
■ CPM service
■ CPM Scanner service
These services are started automatically after installation.
Check the user permissions on the CPM machine

Check the user permissions for the folders that were created on the CPM machine during
installation for the Central Policy Manager environment.

Directory User/Group Permission
<Program files>\CyberArk Administrators ■ Full control
Users ■ Read &

execute
■ List folder
contents
■ Read
<Program files>\CyberArk\Password Administrators ■ Full control

Manager
Users ■ Read &
execute
■ List folder
contents
■ Read
<Program files>\CyberArk\Password Administrators ■ Full control

Manager\Third Party
Users ■ Read &
execute
■ List folder
contents
■ Read
Create a trusted network area

Make sure that the CPM user can only log onto the Vault from the CPM station.
Create a trusted network area
1. Create a Network Area that includes only the IP address of the CPM station,
and from where the CPM user will log onto the Vault.
2. In the User’s Properties window, add this Network Area to the user’s Trusted
Network Areas.
3. Restart the following services:
CyberArk Password Manager service
CyberArk Central Policy Manager Scanner
Add restrictions to the protected credentials file

During installation, a credentials file is created to enable the CPM user to log onto the
Password Vault.
To enhance the security of the credentials file, use the CreateCredFile utility in the Env
folder to create a protected credentials file. For more information, refer to Appendix A:
Creating Credential Files.
Note:
The credentials file is created dynamically during CPM installation, and is not removed
automatically when the CPM is uninstalled

Enable FIPS cryptography

After installation, FIPS cryptography is disabled by default. You can enable it in the
registry by adding the AdvancedFIPSCryptography parameter:
■ Add the AdvancedFIPSCryptography parameter to the registry key in the following
folder:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CyberArk
Password Manager\ImagePath
As shown in the following example:
ImagePath= C:\Program Files (x86)\CyberArk\Password
Manager\PMEngine.exe /SERVICE /AdvancedFipsCryptography
Disable DEP on files used by the CPM

If DEP is supported on the CPM machine, you can disable DEP on selected executable
files used by the CPM:
For Windows 2008:
For Windows 2012:
1. In File Explorer, right-click This PC and select Properties; the Properties
window appears.
2. In the left pane, click Advanced system settings; the Advanced system
settings window appears.
3. In the Advanced tab, in the Performance section, click Settings; the
Performance Options window appears.
4. In the Data Execution Prevention tab, select Turn on DEP for all
programs and services except those I select.
5. Click Add and browse to the executable file for which you want to disable
DEP. You can disable the following executables:
■ PMTerminal.exe
■ Telnet.exe
■ Plink.exe
For example, to disable DEP for PMTerminal, browse to C:\Program
Files\CyberArk\Password Manager\bin and select PMTerminal.exe.
6. Click OK, and then OK again.
7. Reboot the CPM Server.
For more information about implementing DEP, refer to Microsoft documentation.
Install iMacros (on Windows 2008R2 and 2012)

■ On Windows 2008R2 or 2012, install iMacros v10.4. You can download it from the
iMacros archive page: http://download.imacros.net/archive/imacrossetup_
10022823_x64.exe.

Harden the CPM server

■ On Windows 2012R2, harden the CPM server, as described in the Hardening the
CyberArk CPM and PVWA Servers guideHardening the CyberArk CPM and PVWA
Servers. This ensures that your CPM server meets CyberArk’s security standards in
'In Domain' deployments as well as in 'Out of Domain' deployments.
Test CPM Installation

The CPM installation can be tested in the PVWA, and therefore is explained after PVWA
installation. Refer to Test CPM installation in PVWA, page 63 for more information.

The Central Policy Manager Environment
The environment on the CPM machine

During installation, all the files that are required by the CPM on the machine where it is
installed are copied to folders and subfolders that are created especially for this
environment.
Password manager application
By default, the main folder, ‘Password Manager’, is created in C:\ProgramFiles
(x86)\CyberArk.
However, this location can be changed during installation.
The following diagram shows the folder structure of the ‘Password Manager’ folder after
installation in the default location.
■ bin – This folder contains all the files required to run the CPM and password
management processes on remote machines. Files in this folder include dlls,
executables, prompts and process files.
■ Env – This folder is obsolete and is used for backward compatibility.
■ Logs – This folder contains the CPM activity log files. For more information about the
CPM log files, refer to CPM Activity Logs in the Privileged Account Security
Implementation Guide.
■ Samples – This folder is obsolete.
■ tmp – This folder contains files that are used by the CPM for internal processing.
■ Scanner – This folder contains files that are used by CPM Scanner for the Accounts
Feed.

■ Log – This subfolder contains the Scanner activity log files. For more information
about these log files, refer to CyberArk Central Policy Manager Scanner Logs in
the Privileged Account Security Implementation Guide.
■ Vault – This folder contains the Vault parameter file which specifies which Password
Vault will be accessed by the CPM. To update Vault parameters after installation,
open the Vault.ini file in this folder and specify the changes. For more information,
refer to Vault Parameter File, page 278.
This folder also contains the CreateCredFile utility that is used to create the user
credentials file that enables the CPM user to log onto the Password Vault. For more
information about the CreateCredFile utility, refer to Appendix A: Creating Credential
Files.
Installation log
During installation, a log file called CPMInstall.log is created in the temporary folder. This
file contains a list of all the activities performed when the CPM environment in the Vault is
created during the installation procedure.
Additional folders
The following additional folders are created on the CPM machine during CPM installation
for applications that support CPM plug-ins:
■ Application Installation folder
■ Python C:\Python27
■ Oracle Instant Client C:\oracle\instantclient
The Environment in the Password Vault

CPM Safes
During installation, five Safes are created for the CPM:
■ PasswordManager Safe – This Safe contains the CPM.ini file which includes the
main CPM settings, and the ADConfiguration.xml file where auto-detection
parameters are configured.
■ PasswordManager_workspace Safe – This Safe is used for internal processing
and should not be accessed by users.The default size of this Safe is 5000 MB.
■ PasswordManager_info Safe – This Safe is used to store notifications about the
CPM’s activities. The PVWAAppUser is automatically added to this Safe so that it
can read platform names and details, and display them in the PVWA.
■ CPM_ADInternal – This Safe is used for internal processing during auto-detection
activities and should not be accessed by users. This Safe is called <CPM>_
ADInternal. As it uses the name of the CPM as part of its name, by default, it is called
‘PasswordManager_ADInternal’.
■ PasswordManagerShared Safe - This is an internal Safe that is used as a
repository of platforms for all CPMs. The default size of this Safe is 500 MB.
During installation and upgrade, the Vault Admins group is automatically added to all of
the above Safes with all Safe member authorizations. However, if this group does not
have all of the authorizations, the upgrade procedure will not update them.

The CPM User

During installation, a unique CPM user is created to access accounts and manage them.
This user is created as a CPM user type and, as such, can only interact with the CPM
component and by default is the only user type in the Vault who can run the CPM.
This user is automatically given access to the CPM Safes with the following
authorizations:
In the PasswordManagerShared Safe:
■ Use Password/Use accounts
■ Retrieve Files/Retrieve accounts
■ List Files/List accounts
■ Create Files/Add accounts
■ Update Files/Update password value
■ Update File Properties/Update password properties
■ Initiate password management operations/Initiate CPM password management
operations
■ Initiate CPM Change with Manual Password/Specify next password value
■ Rename Files/Rename accounts
■ View Audit/View audit log
■ View Owners/View Safe Members
■ Create/Rename Folder/Create folder
■ Move Files/Folders/ Move accounts/folders
In the PasswordManager Safe:
operations
■ View Audit/View audit log
These authorizations will enable the CPM user to access platforms and the central CPM
parameter file, as well as store log files in the Safe.
In the PasswordManager_workspace Safe:


operations
■ Delete Folder/Delete accounts
■ Delete Folder/Delete folders
In the PasswordManager_info Safe:
operations
■ Delete Files/Delete accounts
■ Delete Folder/Delete folders
Password properties
When the CPM environment is created in the Vault, all the account properties that are
required for supported devices are created. In addition, all the Safes that are created
during this process are configured to require account properties.

Install the Multi-Tenant PVWA

This section describes how to install the Multi-Tenant PVWA in the MSSP environment.
The installation must be performed in the order listed below.
In this section:
Considerations
This section explains the Password Vault Web Access (PVWA) installation and guides
you through each step involved.
Note:
This installation procedure will create a new application pool that will be used for the
Password Vault Web Access
Secure the PVWA Site

If the default web site is not protected by a certificate, passwords will be transferred over
simple http in plain text. It is highly recommended to install an SSL certificate to protect
passwords while they are being transferred.
Multiple PVWAs
The Password Vault can work with multiple instances of the Password Vault Web
Access that are installed on different machines and which access the same Vault. This
enables you to work with High-Availability or Load Balancing (NLB) scenarios.
For more information, refer to Install Multiple PVWAs, page 60.
Authentication
By default, users can authenticate to the PVWA with CyberArk Password authentication.
However, you can configure additional authentication methods to meet your
organizational security and authentication standards. For more information, refer to
Authenticate to the Privileged Account Security Solution, page 99.
Before Installation
Work with a secure channel

To work with a secure channel between the Web server and the Internet Browser, install
an SSL certificate on the Web server.
Vault User Authorizations
During installation, Safes and a User are created to enable the Password Vault Web
Access to work. In order for the installation to create these successfully, the Vault user
who will carry out the installation must have the following authorizations in the Vault:
■ Add Safes

49 Install the Multi-Tenant PVWA
■ Add/Update Users
■ Reset Users’ Passwords
■ Activate Users
■ Manage Vault File Categories
■ Audit Users
Note:
During Vault installation, an Administrator user is created in the Root location of the
Vault hierarchy with these authorizations, especially for this type of activity. Use this
Administrator user to install the Password Vault Web Access
Before installing the PVWA on Windows 2008, add the Web Server role.
Add the Web Server role in the Server Manager on Windows 2012R2
Before installing the PVWA on Windows 2012R2, add the Web Server role.
1. Log onto the PVWA machine with the Administrator user.
2. In the Server Manager, select Add Roles and features; the Add Role
window appears.
3. Add the Web Server role with the following services:
■ Common HTTP:
■All features
■ Health and Diagnostics:
■HTTP Logging
■Request Monitor
■ Security:
■Request Filtering
■Basic Authentication
■Windows Authentication
■ Application Development:
■.NET Extensibility 4.5
■ASP
■ASP.NET 4.5
■ISAPI extensions
■ISAPI filter
■ Management Tools:
■All features
4. Under .Net Framework 3.5 Features make sure the following features are
selected so that they will be added:
■ Non-HTTP Activation
5. Under .Net Framework 4.5.2 make sure the following features are selected
so that they will be added:
■ .NET Framework 4.5.2 Features. This automatically includes .NET 4.0.
■ HTTP Activation

Click OK, the Web Server role is added and .NET Framework 4.5.2 is installed.
6. To enable EPV Web Services, under .Net Framework 4.5.2 Feature add
WCF Services HTTP Activation.
Make sure the following features are selected so they will be added:
■ Web Server
■ Application Development
■.NET Extensibility 4.5
■ASP.NET 4.5
■ Windows Process Activation Service
■ Process Model
■ Configuration APIs
7. Click OK; the Web Server role is added and .NET Framework 4.5.2 is
installed.
Note:
In order to install .NET Framework 4.5.2, you must either have access to the
internet or to the Windows 2012R2 installation media
Install the CPM

■ Install the CPM before installing the PVWA. This is a prerequisite.
Manage passwords with the CPM
■ Check that the Vault user who will be used for this installation is an owner of the
PasswordManager_Info Safe with the ‘Manage Safe Owners’ authorization.
Close all applications
■ Close all other applications currently running on your computer, before installing the
Password Vault Web Access.
Log onto Windows as the Administrator user
■ Before beginning installation, log onto Windows as the Administrator user.
Installation
The Password Vault Web Access must be installed on a different machine to the
Enterprise Password Vault server and a different machine to the CPM.
Installation procedure
1. On the PVWA machine, create a new folder and copy the Password Vault
Web Access folder from the installation CD to it.
or,
as Administrator.
3. The installation process begins and the following Setup window appears.

4. If you have not already closed any open Windows applications, it is strongly
Note: You can exit installation at any time by clicking Cancel. You can return to the
previous installation window by clicking Back, where applicable.
Agreement.
information.

Next to proceed to the Web application destination window which enables
you to select the folder on your computer where the Password Vault Web
Access will be installed.

or,
Click Browse and select another location.
Click Next to proceed to the Configuration files destination window, which
enables you to select the folder on your computer where the configuration and
connection files for the Password Vault Web Access will be installed.

Note:
Since some of the files under this folder will require full access permissions by the
user that runs the web application (e.g. ASPNET/NETWORKSERVICE), it is
highly recommended to leave the default location. Specifically, this location must
not be changed to ‘wwwroot’ or ‘Program Files

or,
Click Browse and select another location, then click Next.
The Setup Type window appears.

10. Select the type of Password Vault Web Access to install.

■ Full Password Vault Web Access – This option installs the PVWA for
desktop browsers. Select this option to install MSP.
■ Mobile Password Vault Web Access – This option installs a PVWA interface
that is specifically for mobile devices.
Click Next to proceed to the Web application details window, which enables you
to specify the web site name, application name, and authentication type(s) for
the web application.
11. Select the site name from the list of installed site names.
If the operating system does not support multiple web sites, the site name will be
disabled and you will not be able to select from a list of additional site names.
12. Specify the application name or leave the default application name.
13. Select one or more of the following authentication types that the PVWA will
support.
■ CyberArk
■ Windows
■ Radius
■ PKI
■ RSA SecurID
■ LDAP
■ Oracle SSO
■ SAML
For MSSP, select both Password and LDAP.
Note:

■ Some of the selected authentication types must be installed and configured

on the Vault before they can be configured for the PVWA. For more
information, refer to Authenticate to the Privileged Account Security Solution, page 99.
■ Make sure that the administrative user for testing can authenticate to the
Vault with one of the selected authentication methods so that you will be able
to test the installation.
14. Set the default authentication method that the PVWA will display when users
open the web browser to LDAP.
15. If you have installed an SSL certificate, select Require secure channel
(SSL).
16. To enable each user to display the authentication login page for their
authentication method, select Remember last used authentication
(requires cookies).
17. Click Next; if the application name has already been specified for a different
application, the following message will appear.
Click OK, then change the application name and click Next.
The Password Vault Web Access now configures the installation, then the CPM
Users window appears.
18. Specify the name of the CPM user in the Vault. If there is more than one
CPM User in the Vault, specify all the usernames, separated by commas.
19. Click Next to proceed to the Vault connection details window where you

specify the connection details of the Password Vault.
20. Specify the IP or DNS address and the port number of the Password Vault.
For high-availability implementations and DR, after installation in the Vault.ini
file, in the Address parameter, you can specify more than one Vault IP address,
separated by commas. Currently there is no limit to the number of IP addresses
that you can specify.
21. Click Next to proceed to the Vault’s username and password details window
where you specify the logon details of the Vault user.
If the Vault IP or the port number was not specified, the following message or a
similar one will appear.
■ Click Yes to skip to the end of the installation, in which case you will have to
create the Password Vault Web Access environment later,
Note:
This option is strongly not recommended
or,
■ Click No to return to the Vault connection details window, where you specify
the Vault’s connection details, then click Next to display the Vault’s
username and password details window.

22. Specify the username and password of the Vault user carrying out this
installation, then click Next to create the Password Vault Web Access
environment and display the Setup Complete window.
Note:
It is recommended to use the Vault administrator user for this installation as this
user has the appropriate Vault authorizations and is created in the appropriate
location in the Vault hierarchy
If the installation cannot use the specified user and password to log onto the
Vault and complete the installation, this screen will be displayed again.
If the username or password was not specified, the following message will
appear.
23. Click Yes to skip to the end of the installation, in which case you will have to
create the Password Vault Web Access environment later,
Note:
This option is strongly not recommended
or,

Click No to return to the Vault’s username and password details window and
specify the username and password, then click Next to create the Password
Vault Web Access environment and display the Setup Complete window.
24. Click Finish to complete the Password Vault Web Access installation.
Following the Installation

Several log files are created during installation to monitor the installation process and to
enable you to ensure that the Password Vault Web Access was installed successfully.
The following log files are created in the default Windows Temp folder, which differs
according to the Windows OS. These files contain all the information about the
installation procedure:
■ PVWAInstall.log
■ PVWAInstallEnv.log
If errors occur during installation, the Password Vault Web Access installation also
creates the following log files:
■ PVWAInstallError.log
■ PVWAInstallErrorEnv.log
Additional log files are created in the Env\Log subfolder of the Password Vault Web
Access configuration folder. In particular, the following log files contain important
information about the installation process:
■ CheckConnection.log – This log file contains information about the Password Vault
Web Access connection to the Password Vault, and enables you to check that the
connection is configured correctly.

■ CreateEnv.log – This log file contains information about the Password Vault Web
Access environment in the Password Vault, and enables you to check that the
environment was created correctly.
Other log files that are used for internal purposes are created in the same folder during
installation.
Check the user permissions on the Web Server

Check the user permissions for the folders that were created on the web server during
installation for the Password Vault Web Access environment.
By default, all folders except the <Windows folder>\Temp folder are created under
C:\CyberArk\Password Vault Web Access. However, this location can be changed
during installation.
Directory User/Group Permission
CredFiles Administrators ■ Full

control
Application pool’s dedicated user: ■ Full

■ IIS AppPool\PasswordVaultWeb control
AccessPool
VaultInfo Administrators ■ Full

control

AccessPool
WebCharts Administrators ■ Full

control

AccessPool
Internet Guest user1 ■ Read &

(IIS_IUSRS) Execute
<Windows Administrators ■ Full

folder>\Temp control

AccessPool
If you will use Internet Explorer in Windows 2008 to browse to the PVWA,
change the following setting:
Add restrictions to the protected credentials file

During installation, a credentials file is created to enable the PVWA user to log onto the
Password Vault.

To enhance the security of the credentials file, use the CreateCredFile utility in the Env
folder to create a protected credentials file. For more information, refer to Creating
Credential Files.
Specify Multiple Vault IP Addresses

For high-availability implementations and DR, after installation in the Vault.ini file, in the
Address parameter, you can specify more than one Vault IP address, separated by
commas. Currently there is no limit to the number of IP addresses that you can specify.
When the PVWA is running, if it cannot access the first Vault IP address, it automatically
tries to access the next Vault IP address transparently, and no human intervention is
required.
Harden the PVWA Server

On Windows 2012R2, harden the PVWA server, as described in the Hardening the
CyberArk CPM and PVWA Servers guide. This ensures that your PVWA server meets
CyberArk’s security standards in 'In Domain' deployments as well as in 'Out of Domain'
deployments.
Install Multiple PVWAs

The Password Vault can work with multiple instances of the Password Vault Web
Access that are installed on different machines. This enables you to work with High-
Availability and Load Balancing (NLB) scenarios.
Note:
■ In both scenarios, the Password Vault Web Access installations must be the same
version.
■ Load balancer requirements:
■ The load balancer must not alter page content or it should include a
mechanism to prevent pages from being altered.
■ The load balancers must not alter the application path hierarchy (leave the
default application path as it is).
■ The load balancer must support 'sticky sessions'.
Install the PVWA on two machines

When two instances of the PVWA are installed on different machines, you can configure
them to access the same XML configuration files from the PVWAConfig and
PVWAUserPrefs Safes.
Install the PVWA on two machines
1. On the first machine, install the PVWA following the standard procedure. For
more information, refer to Password Vault Web Access.
2. On the second machine, install the PVWA as described in Password Vault
Web Access until step 18.
3. When you are prompted for the name of the Vault user in the ‘Vault’s
username and password details’ window, display the

C:\CyberArk\Password Vault Web Access\Env folder.

4. In the \Env subfolder of the Password Vault Web Access installation folder,
open the PVConfiguration.template.xml file, and do the following:
■ In the Users section, change the following parameters:
■ GWUserName="PVWAGWUser2"
■ ApplicationUserName="PVWAAppUser2"
Note:
To configure the two instances of the PVWA to access the same configuration
files, change the GWUserName parameter and the ApplicationUserName
parameter
5. Save the configuration file, then close it.

6. Complete the installation as described in Installation, page 50.

Test PVWA Installation

The following configurations describe how to configure the PVWA so that you can carry
out a test to check that it was installed successfully.
■ Through the PrivateArk Web Client, log onto the Vault as the user that you used to
create the PVWA environment during installation.
Add the Administrative Test User to the PVWAMonitor Group
Add the following users to the PVWAMonitor group:
■ The predefined Administrator user
■ The administrative test user
Share the PIM-Internal safe with the PVWA gateway user
1. Open the PIM-Internal Safe that you created to test Vault installation and
display the Safe Properties window.
2. In the Sharing tab, select Share this Safe, and then select both of the
following options:
■ Enable access to fully impersonated users
■ Enable access to impersonated users with additional Server authentication.
3. From the Gateway Account drop-down list, select PVWAGWAccounts,
then click Add; the Gateway Account name is added to the list of Accounts
that the Safe is shared with.
4. Click OK; the Safe can now be accessed by authorized users through the
PVWA.
5. Log off the Vault.
Test the PVWA Installation
1. In your browser, specify the following URL:
https://<host name>/passwordvault
The main PVWA window appears.

2. Select the authentication method that you will use to authenticate to the
Vault; the relevant authentication page appears.
3. If necessary, authenticate to the PVWA. Make sure that your administrative
user is configured to authenticate with the specified method.
4. After the user is authenticated, you will be able to see the passwords that are
stored inside PIM-Internal.
Test a PVWA Installation with Multiple PVWAs

The following test can be used for multiple PVWA implementations.
Configuring the Vault Test Environment
Configure the test environment as described in Test PVWA Installation, page 62.
Test the PVWA installation on the first machine



Test the PVWA installation on the second machine

Test CPM installation in PVWA

The following steps describe how to configure the CPM so that you can carry out a test to
check that it was installed successfully.
Add the CPM User to the PIM-Internal Safe
1. Log onto the PVWA as the Administrator user.
2. Share the PIM-Internal Safe with the CPM user. By default, this user is
called PasswordManager; this name must not be changed.
a. Click POLICIES to display the Policies page, then click Access
Control (Safes); a list of Safes is displayed.
b. Select the PIM-Internal Safe, then click Edit Safe; the Edit Safe page
appears.
c. From the Assigned to CPM drop-down box, select
PasswordManager, then click Save; the CPM is assigned to this
Safe with the appropriate permissions and the Safe Details page is
displayed again. You can see the CPM user that you selected in the
list of Safe Members.

Configure a Platform
1. Click ADMINISTRATION to display the System Configuration page, then
click Platform Management to display a list of supported target account
platforms.
2. Select a Windows platform to use for this test, then click Edit; the
configuration editor for the selected platform displays the platform
parameters.
3. In the General parameters, change the following parameter:
Set the ImmediateInterval parameter to 1.
Note:
This parameter is for this test and must be reset afterwards to meet your
enterprise requirements
For a full list of platform parameters, refer to the Privileged Account Security
4. Click Apply to save the changes, then click OK to return to the System
Configuration.
5. Restart the CPM.
Create an Account
1. In the PVWA, in the ACCOUNTS page, click Add Account; the Add
Account page appears.
2. From the Store in Safe drop-down list, select PIM-Internal.
3. From the Device Type drop-down list, select Operating System; the
Platform Name edit box appears.
4. From the Platform Name drop-down list, select the Windows platform that
you configured in the previous steps; the required and optional password
properties for this type of password is displayed.
5. In the Address edit box, specify the IP address of the Vault.
6. In the User Name edit box, specify the name of the Vault user whose
password will be changed in this test.
7. In the Password edit box, specify the user’s Windows password , and type it
again in the Confirm Password edit box.
8. Click Save to save this password.
In the PVWA
1. Display the Account Details page of the password that you created above,
then click Change; the Change Password page appears.
2. Specify how the CPM will change the password, then click Save; the CPM
changes the password after the one minute interval specified in the
ImmediateInterval parameter.

Check that the password was changed successfully

1. After one minute, in the Account Details page, click Show to display the new
password.
2. In the Activities tab, the following Action should be displayed:
CPM Change Password
3. Click the action to display details about the password change process.
The Password Vault Web Access Environment

The Password Vault Web Access requires a suitable environment on the web server and
in the Password Vault. During Password Vault Web Access installation, both these
environments are created automatically.
The environment in the Web Server

During installation, all the files that are required on the web server for the Password Vault
Web Access application are copied to folders and subfolders that are created especially
for this environment.
Password Vault Web Access application
By default, the main folder, ‘PasswordVault’, is created under Inetpub\wwwroot.
Although the location can be changed during installation, it is recommended to leave the
default installation location due to potential permissions problems. In particular, it is
recommended not to install the application folder under ‘Program Files’.
This folder is used as the physical path of the virtual directory that is created under the
selected web site.
The following diagram shows the folder structure of the ‘PasswordVault’ folder after

Global Web Client Controls Folder

■ webctrl_client – This folder contains a variety of general controls and images that
are required by the application. It is created in the same location as the Password
Vault Web Access application.
If the default web application location was changed during installation, make sure that
this folder is under the root location of the selected web site.
Password Vault Web Access working environment
A new folder called ‘Password Vault Web Access’ is created for the configuration and
connection files required by the Password Vault Web Access to create its working
environment. By default, this folder is created under C:\CyberArk. This location can be
changed during installation, but the folders should not be copied to a different location
after installation. In particular, it is recommended not to install this folder under ‘Program
Files’.
The following diagram shows the folder structure of the ‘Password Vault Web Access’
folder after installation in the default location.

The ‘Password Vault Web Access’ folder contains the following subfolders and files:
■ CredFiles – This folder contains the credential files for the Password Vault Web
Access Gateway user and the internal application user. The user that runs the
application (by default, ASPNET on IIS5 or Network Service on IIS6) will have read
and write permissions on this folder.
To recreate these files, use the CreateCredFile utility. For more details about using
the CreateCredFile utility, refer to Appendix A: Creating Credential Files.
■ Env – This folder contains the utilities, dll files, and configuration files that are
required during installation to create the Password Vault Web Access environment.
This folder also contains the platform configuration files required to create a working
environment with or without a CPM.
■ VaultInfo – This folder contains the parameter file which specifies the Password
Vault that will be accessed through the Password Vault Web Access. The user that
runs the application (by default, ASPNET on IIS5 or Network Service on IIS6) will
have full permissions on this folder.
■ To update Vault parameters after installation, open the Vault.ini file in this folder and
specify the changes. For more information, refer to Vault Parameter File, page 278.
■ WebCharts – This folder contains the charts that are created for the Password Vault
Web Access dashboard. The Internet guest user (IUSR_<computer_name>) will
have full permissions on this folder. However, the user that runs the application (by
default, ASPNET on IIS5 or Network Service on IIS6) will not have any permissions
on this folder.
IIS Virtual folders
The following virtual folders are created during installation:
■ PasswordVault – This folder points to where the Password Vault Web Access
application is installed. By default, this is the ‘PasswordVault’ folder.
■ WebCharts – This folder points to the ‘WebCharts’ folder under the
CyberArk\Password Vault Web Access folder.
The environment in the password vault
During installation, all the required Safes, users, groups and properties are created in the
Password Vault. This environment enables you to begin working with the Password

Vault Web Access immediately after installation.

Password Vault Web Access safes
The following Safes are created for the Password Vault Web Access environment:
■ PVWAConfig – This Safe contains all the configuration settings for the Password
Vault Web Access.
■ PVWAUserPrefs – This Safe contains the user preference settings for the
Password Vault Web Access interface.
In both of the above Safes, relevant information is stored automatically, and users should
not modify files in the Safes directly.
■ PVWATicketingSystem – This Safe is used to store accounts that are used to
connect to ticketing systems that are configured to work with the PVWA.
■ VaultInternal – This Safe is used to store the accounts that are used to connect to
LDAP directories and are used by the LDAP integration components for transparent
user management in the Vault and CPM automatic detection.
The following Safes are automatically created during installation. When the first report is
generated, a new folder is created for the user where the reports they generate are
stored.
■ PVWAReports – This Safe is specifically for reports and is created with the following
configuration:
■ Object Level Access – Reports Safes are configured for Object Level Access.
For more information, refer to Object Level Access Control in the Privileged
By default, reports are created in a separate folder per user and each user can
only access their own reports. Only users who have specifically been given
access authorizations in this Safe will be able to see all the reports.
■ Automatic purge – Reports Safes are configured to delete reports
automatically when the object retention period expires. For more information,
refer to Protecting Reports in the Privileged Account Security Implementation
Guide.
■ Objects retention – Reports are stored in the Reports Safe for 30 days, by
default.
■ Safe activity retention – Safe activity logs are stored in the recording Safe for
90 days, by default.
■ PVWATaskDefinitions – This Safe contains all the reports that were saved and/or
scheduled by users.
■ PVWAPublicData – This Safe contains the help documents that can be accessed in
the PVWA.
Password Vault Web Access users
The following users are created for the Password Vault Web Access environment. For
each user, a credentials file is created to enable the user to access the Vault from the
Password Vault Web Access.
These files are created during installation and are stored in:
C:\CyberArk\Password Vault Web Access\CredFiles.

■ PVWAGWUser – This is the Gateway user through which other users will access the
Vault. The credentials file for this user is PVWAGWUser.ini. This user is a member
of the PVWAGWAccounts group described below. For more information about the
Safes that this user is added to during installation, refer to Password Vault Web
Access Groups, page 69.
■ PVWAAppUser – This user is used by the Password Vault Web Access for internal
processing. The credentials file for this user is PVWAAppUser.ini. This user is
created as a PVWAApp user type and, as such, can only interact with the PVWA
component and by default is the only user type in the Vault who can run the PVWA.
For a list of Safes that this user is added to and its authorizations in each one, refer to
Safe Ownership, page 70.
Password Vault Web Access Groups
During installation or upgrade, several predefined groups are created and added
automatically to the Safes that are created as part of the Password Vault Web Access
environment.
The following groups are created for the Password Vault Web Access environment:
■ PVWAMonitor – This is the monitoring users group. Members of this group can view
CPM activities. The Vault user who runs the installation is added automatically to this
group. Any other users who should see this information must be added to the group
manually.
This group is added automatically to the PVWAUserPrefs Safe with the following
authorizations:
■ Add passwords/files
■ Retrieve passwords/files
■ List passwords/files
■ Update password value
This group is also added automatically to the PasswordManager_Info Safe with the
following authorizations:
■ View Safe members
■ View audit
■ PVWAUsers – This is the users group for the Password Vault Web Access.
Members of this group can change their Password Vault Web Access preferences.
Users must be added manually to this group.
This group is added automatically to the PVWAUserPrefs Safe with the following
authorizations:
■ Add passwords/files
This group is also added automatically to the PasswordManager_Info Safe with the


■ View audit
■ PVWAGWAccounts – This is a group of gateway accounts that is shared with
Safes that will be accessed through the PVWA. All Safes that are added in the
PVWA are automatically shared with this group. This group is automatically shared
with the PVWAConfiguration Safe.
Safe Ownership
When the Password Vault Web Access environment is created in the Vault, the users
that are created automatically are added to the following Safes:
■ PVWAConfig – The PVWAAppUser is added to this Safe with the following
authorization:
■ Retrieve passwords
■ List passwords
In addition, this Safe is shared with the PVWAGWAccounts group.
■ PVWAUserPrefs – The PVWAMonitor and PVWAUsers groups are added to this
Safe with the following authorizations:
■ List passwords
■ Add passwords
■ Update password values
■ Update password properties
■ PVWATicketingSystem – The PVWAAppUser is added to this Safe with the
■ List passwords
■ PasswordManager_Info – The PVWAMonitor and PVWAUsers groups and the
PVWAAppUser are automatically added to this Safe with the following
authorizations:
■ List passwords
■ View Audit
■ View Safe Members
■ PVWAReports – The PVWAAppUser is added to this Safe with the following
authorizations:
■ Add passwords/Create files
■ Update password value/files
■ Update password/file properties
■ Delete passwords/files
■ Manage Safe members

■ Create/rename folder
■ PVWATaskDefinitions – The PVWAAppUser is added to this Safe with all the
authorizations.
■ PVWAPublicData – The following users and groups are added to this Safe:
■ The Vault Admins group is added to this Safe with all authorizations.
■ The user who initiated the PVWA installation is added to this Safe with all
authorizations. By default, this is the Administrator user.
■ The PVWAAppUser is added to this Safe with the following authorizations:
Configuration files
The following configuration files are copied to the PVWAConfig Safe during environment
creation:
■ PVConfiguration.xml – This configuration file contains parameters for different
configurations of the Password Vault Web Access. These parameters are detailed
later in this chapter.
■ SafeTemplate.xml – This configuration file contains parameters that determine the
default Safe properties that will be applied to the Safes that are created in the PVWA.
These parameters are detailed later in this chapter.
All the parameters in these files can be configured in the System Configuration page in
the PVWA. For more information, refer to the Privileged Account Security
Privileged account properties
When the Password Vault Web Access environment is created in the Vault, all the
account properties that are required for supported devices are created.

Vault Backup Solution

In this section:
Backup Considerations
Backup Software
The type of backup software that your enterprise uses determines the way that you will
back up the Password Vault. The Enterprise Password Vault provides a secure way to
back up your Vault without compromising the sensitive information within.
The Enterprise Password Vault backup solution can be implemented in two scenarios:
■ Replication – The Vault Backup Utility exports the Vault data from the Password
Vault to a computer on the local network. The enterprise global backup system can
then access the files from that computer. The entire backup procedure takes place
within the Vault environment, thus maintaining the highest possible level of security,
and there is no need for any external application to cross the firewall. The contents of
the Vault replica are encrypted, ensuring that they remain highly secure at all times.
This method is recommended.
■ Third Party Backup System – The Password Vault integrates with several backup
applications, and can configure the firewall to permit these applications access to the
Vault backup folders. This introduces external applications to the Vault and
potentially reduces the level of security that the information stored in the Vault
benefits from.
Server Location
If the Server is located in the DMZ, it is recommended that you back it up from within the
enterprise network.
Required Access Rights

Backing up and restoring Safes can be carried out using Vault services. This means that
the Vault has full control over backup and restore actions, which need to be issued by a
CyberArk user who has specific backup rights.
Backup Permissions
Backup rights enable a User to run the EPV Backup utilities. When using these utilities,
the User will be required to supply a username and password. The Vault will then verify
the User’s identity and check that the User has the authorization to backup the selected
Safe. If the User does not have the required authority, the backup operation fails.
If the User carrying out the backup procedure only has access to some of the Safes in the
selected group, only the Safes that he has access to will be backed up. Safes that he
does not have access to will not be backed up.

73 Vault Backup Solution
Note:
It is recommended to use the specific “Backup” user for the backup operation and not
grant each User authorization to perform this procedure
After installation, the Backup User account is disabled. Before using the Backup User,
enable it and update its password.
■ Backup User – The Backup user is a predefined user that is added automatically as
an Owner to every Safe, and only has the access rights required to backup the Safes.
This user makes it easier to organize your backup procedure.
Any user that will initiate a backup process must have the ‘Backup All Safes’ user
authorization on the Safes that he will back up. The predefined ‘Backup’ user has this
privilege, and is also assigned to the ‘Backup Users’ predefined group automatically.
When additional users are added to this group, they must each be given the ‘Backup
All Safes’ authorization separately.
Restore Permissions
To restore a Safe, a User must have the ‘Restore All Safes’ authorization in the Vault.
This means that a User is able to restore all the Safes, but it does not grant him automatic
access to the Safes after they are restored. Only users who have Safe membership will
be able to access restored Safes.
The ‘Restore All Safes’ authorization enables a User to issue the EPV Restore utility and
restore any Safe in the Vault. The predefined Operator user has this permission and can
also restore any Safe in the Vault. When using this utility, the user will be required to
supply his user name and password. The Vault will then verify the user identity and check
his authorizations to administer this specific Safe. If the user does not have the required
rights, the operation will not be carried out.
The user who will restore a full Vault is not required to authenticate to the Vault.
However, the full Vault can only be restored on the Vault machine.
For more information about restoring individual Safes as well as the whole Vault, refer to
the Privileged Account Security Implementation Guide.
Use the CyberArk Backup Process

The CyberArk Vault provides an easy method of exporting the encrypted contents of your
Safes securely to a computer outside the Vault environment. A global backup system can
then access the replicated Safe files in the same way as it would access any other files on
the network.
The Vault’s Backup solution is comprised of several utilities that manage and perform the
backup and restore operations. These utilities can be configured to run automatically
using a scheduling program. Safes backup should be synchronized with your backup
methodology.
Replication
The Vault Backup utility exports the Safe files from the CyberArk Vault to a computer on
the local network where the Backup utility has been installed. The Safes are copied in a

similar format and structure to the one in the Server. The global backup system can then
access the files from that computer. In order to be able to issue the replicate utility in a
Safe, a user must have the ‘Backup All Safes’ user authorization and the ‘Backup Safe’
authorization in the Safe being replicated. A predefined group called ‘Backup Users’ is
created during Vault installation and upgrading, and is added automatically to every Safe
that is created. Each user that is subsequently assigned to this group must be given
backup authorizations manually. This user authenticates to the Vault with a user
credentials file which contains its username and encrypted logon credentials.
As the Backup utility is part of the total CyberArk Vault environment, there is no need for
any external application to cross the firewall. The entire backup procedure takes place
within the Vault environment, thus maintaining the high level of security that is
characteristic to the CyberArk Vault.
Note:
If your Safes are on an NTFS partition, the replicated Safes should also be on an NTFS
partition, and not FAT/FAT32
The following diagram displays the processes that take place during Vault replication.
Vault Replication
Step 1: The Vault Backup utility (PAReplicate.exe) generates a metadata backup in the
Vault’s Metadata Backup folder, then exports the contents of the Data folder and the
contents of the Metadata Backup folder to the computer on which the Backup utility is
installed.
Step 2: After the replication process is complete, the external backup application copies
all the files from the replicated Data folder and the Metadata folder.

Keep the replicated files on the Backup utility machine after the external backup
application copies all the files. The next time you run the Backup utility to the same
location, it will update only the modified files and reduce the time of the replication.
Direct Backup Using a Third Party Backup Solution

A complete Vault can also be backed up and restored by Direct Backup, instead of using
the Replicate utility. This means accessing the Server and copying the Safes, using any
ordinary copying method, such as a local tape, or any existing backup utility. Direct
restore involves copying the Safes back to the ‘Restored Safes' folder.
Users carrying out direct backup require Windows authentication administrator
permissions in order to access the Server. These rights are not controlled by the EPV
and should be part of the site procedures that define where the Server is located and who
can access it.
Before backing up the Safe or Vault directly, the metadata must be prepared using the
prebackup utility before the backup process. When restoring the Safe or Vault directly,
the metadata must be restored using the CAVaultManager utility. For more information,
refer to CAVaultManager.
Backing Up the Safes

The following diagram shows the structure of the folder that contains the Safes.
Safe backup structure
The Safes are stored in the PrivateArk\Safes folder; the metadata files in the Metadata
folder, and the data files in the Data folder. Due to the importance of the information in the
metadata files and locking issues, the backup procedure begins by creating a metadata
backup in the Metadata Backup folder. This ensures that the actual metadata is left
untouched and removes the risk of any changes being made to it.
Before backing up the CyberArk Vault, prepare the metadata for the backup process. If
you use the Vault Backup utility, this is done automatically during the backup process. If
you back up the Safes using a third party application, carry out a pre-backup procedure to
create metadata backup files which are not used by the database and can be backed up
successfully. The pre-backup procedure copies the metadata backup files to a
designated folder from where they are backed up. This ensures that the metadata
remains untouched during Safe activity.

Note:
Immediately after Vault installation or configuration, it is recommended to backup the
Vault’s parameter files (ini files) manually
Install the Vault Backup Utility

The Vault Backup utility provides a full backup for your Safes and Vaults. This enables
you to retrieve them when necessary.
Before Installation
Before you install the Vault Backup utility, make sure that the Backup utility machine has
the following features and capabilities:
■ At least the same disk space as the Vault database.
■ The drive where the replicated files will be stored is NTFS.
■ Accessibility by the Password Vault using the Vault protocol.
■ Accessibility by your Enterprise backup system.
■ Physical security that only permits authorized users to access it.
■ Identical regional and language settings as the Vault machine
Installation
The Vault Backup utility must be installed on a different machine to the Enterprise
Password Vault server.
Installation procedure
the contents of the Replicate folder.
or,
as Administrator.
The Vault Backup utility installation process begins and the PrivateArk
Replicator Setup window appears, as shown below.

Note:
You can exit installation at any time by clicking Cancel. You can return to the
previous installation window by clicking Back, where applicable
to view the License Agreement and accept its terms, as shown below.
to the next step of the installation which enables you to enter user information
for licensing purposes, as shown below.


to select the folder on the computer in which the Backup utility files will be
located, as shown below.

displayed in the Destination Folder area, and proceed to the next step of
the installation,
or,
Click Browse to select another location, then click Next to proceed to the next
step of the installation.
9. Navigate to the required location and click OK. Then, click Next to proceed
to the next step in the installation, which enables you to select the Backup

Folder on the computer in which the Backups will be located, as shown

below.
displayed in the Destination Folder area, and proceed to the next step of the
installation,
or,
Click Browse to select another location, then click Next to proceed to the next
stage of the installation.
Note:
The pathname of the destination folder must not exceed 20 characters
The installation procedure is now carried out. The progress of the installation is
indicated in the displayed progress window.
11. Finally, the following window appears to enable you to complete the
installation,

12. Click Finish to complete the installation.

The name of the Vault Backup utility is PrivateArk Replicator. It is installed in the
Replicate subfolder of the Server installation folder.
Backup utilities
During the PrivateArk Replicator installation, the following utilities are installed in the
Replicate folder of the installation folder.
■ PAPrebackup – Prepares the Safes for backup
■ PAReplicate – Backs up the Safes
■ PARestore – Restores the Safes
PAPrebackup
The PAPrebackup utility prepares the Safes for backup by a third party backup agent. It
carries out the prebackup procedure in the following way:
The metadata is stored in the Metadata sub-folder, and the data files are stored in the
Data sub-folder. Before the backup procedure begins, the pre-backup procedure copies
the metadata files to the ‘Metadata Backup’ folder. If a full backup is requested, a copy of
the entire database is created and stored in the Metadata backup sub-folder. If an
incremental backup is requested, MySQL binary logs that contain the changes made in
the metadata since the last backup are copied to the Metadata backup sub-folder.
The backup process then copies the files from the ‘Metadata Backup’ and ‘Data’ folders
without touching the original metadata files in the Metadata folder.
Any User who has the ‘Backup All Safes’ user authorization and the ‘Backup Safe’
authorization in specific Safes can issue the PAPrebackup command for those Safes.
Use the Backup User to prepare the backup for the entire Vault.
PAPrebackup provides the following options:
PAPrebackup<Vaultfile> <User[/password]>
[/LogonFromFile logonfile]
[/Full | /Incremental

[/FullOnIncrementalFailure]]
[/BackupPoolName
BackupPoolName>]
/?
This usage is explained in the following table and examples:
Option Description
<Vaultfile> The file containing all the information about the Vault and the
Safes within it. By default, this file is called Vault.ini.
<User> The name of the User issuing the command. This User must have
the Backup Safe permission.
[/password] The password of the User specified above. If the User issues this
command without specifying the password and without specifying
the /LogonFromFile parameter, the User is prompted for it before
the command is carried out.
[/LogonFromFile] The pathname of a user credentials file containing an encrypted

password that the utility will use to log on instead of a password.
Note: The password in this credentials file is changed after every
logon.
[/Full] Generates a full metadata backup. This will generate a complete

database backup in the Metadata Backup folder.
[/Incremental] Generates an incremental metadata backup. This will copy

relevant MySQL binary logs to the Metadata Backup folder.
[/FullOnIncremental Prepares a full backup if an incremental backup fails instead of

Failure] simply displaying an error message.
[/BackupPoolName] Specifies a Backup Pool Name. This is used when there are a
number of backup sets for a Vault, or a number of clients used to
backup the server. The Pool Name can be specified in the restore
process, enabling you to distinguish between different backup
sets.
/? Displays the list of options available with this utility.
Note:
PAPreBackup maintains its own ini file. If neither /Full nor /Incremental is specified,
PAPreBackup will attempt to generate an incremental backup. It will only generate a full
backup if this utility has never been used before
For example:
Paprebackup C:\PrivateArk\Server\Vault.ini Backup/Asdf1234 /full
The above example will generate a complete metadata backup in the Metadata folder.
The utility will take all the relevant information about the Vault from the Vault.ini file stored
in C:\PrivateArk\Server. This command is issued by the Backup User, using his
password which is ‘Asdf1234’.

As this example will generate a full backup, it would be scheduled to be executed

regularly, according to the organization backup policy.
PAReplicate
The PAReplicate utility copies the Safe files from the Vault to a specified computer on the
network in a similar structure to that in the Safes folder.
Any User who has the ‘Backup All Safes’ user authorization and the ‘Backup Safe’
authorization in specific Safes can issue this command for those Safes. Use the Backup
User to replicate the entire Vault.
You can use PAReplicate to backup a specific Safe or a group of Safes. When using the
specific backup, the requested Safe data files are copied to the specified location in the
same format as they are stored in the server, and the Vault’s Metadata Backup is copied
to the specified location in the Metadata sub-folder.
PAReplicate can be used as a local backup or as the first step in a backup procedure
being carried out by an application that the Vault does not recognize and therefore would
not be allowed to cross the firewall.
Note:
When PAReplicate is executed, it automatically carries out a pre-backup procedure,
and there is no need to run PAPreBackup separately
PAReplicate provides the following options:

PAReplicate<VaultFile> <User [/password]>
[/LogonFromFile logonfile]
[/SafesPattern pattern]
[/MetadataReplicateFromHour <FromHour>]
[/MetadataReplicateToHour <ToHour>]
[/MetadataOnly | /DataOnly]
[/FullBackup]
[/IncludeUnmodifiedSafesData]
[/BackupPoolName BackupPoolName]
[/TsParmFile TsParmFilePath]
[/IniFile IniFilePath]
</EnableTrace>
/?
This usage is explained in the following table and examples:
Option Description
<Vaultfile > The file containing all the information about the Vault and the Safes
within it. By default, this file is called Vault.ini.
<User> The name of the User issuing the command. This User must have
the Backup Safe permission.
[/password] The password of the User specified above. If the User issues this
command without specifying the password and without specifying
the /LogonFromFile parameter, the User is prompted for it before
the command is carried out.

Option Description
[/LogonFromFile] The pathname of a user credentials file containing an encrypted

password that the utility will use to log on instead of a password.
Note: The password in this credentials file is changed after every
logon.
[/Safespattern] The complete name or part of the Safe to backup. You can use
wildcards to specify more than one Safe. If you do not use this
parameter, all Safes in the Vault will be replicated.
/MetadataReplicate Replicates the metadata from a specific hour.

FromHour
/MetadataReplicate Replicates the metadata until a specific hour.

ToHour
/MetadataOnly Replicates only the metadata backup files, not the data files.
/DataOnly Replicates only the data files, not the metadata.
/FullBackup Forces a full backup (instead of the default incremental backup).
IncludeUnmodified During replication, do NOT skip Safes that were not

SafesData modified/accessed since the previous data replication. This
parameter is used to force PAReplicate to replicate Safes data that
was previously replicated but that was deleted.
/BackupPoolName Specifies a Backup Pool Name. This is used when there are a
number of backup sets for a Vault, or a number of clients used to
backup the server. The Pool Name can be specified in the restore
process, enabling you to distinguish between different backup
sets.
/TsParmFile Specifies an alternative TSParm.ini file. The TSParm.ini file

specifies the target Safe folder for the replication process. This is
used when a client is used to replicate several Vault machines, so
each can have its own replicated Safes folder structure.
/IniFile Specifies an alternative PAReplicate.ini file. The PAReplicate.ini

file maintains replication status, and is managed by PAReplicate.
This is used when a client is used to replicate several Vault
machines, so each can have its own replicated Safes folder
structure.
/EnableTrace Enables a high level of tracing in the PAReplicate.log file.
/? Displays the list of options available with this utility.
Note:
PAReplicate maintains its own ini file. If /FullBackup is not specified, PAReplicate will
attempt to generate an incremental backup. It will only generate a full backup if this
utility has never been used before or if a failure occurs

For example:
Pareplicate C:\PrivateArk\Server\Vault.ini /logonfromfile
backupuser.ini /FullBackup
The above example will replicate the Safes from the Vault to the location specified in the
TSParm.ini file. The utility would take all the relevant information about the Vault from the
Vault.ini file stored in C:\PrivateArk\Server and the logon credentials of the user who will
access the Vault from the ‘backupuser.ini’ credentials file, which is stored in the same
location as the ‘pareplicate’ utility.
As no Safespattern parameter is specified, all the Safes in the Vault will be replicated.
As this example will generate a full metadata backup, it would be scheduled to be
executed regularly, according to the organization’s backup policy.
Logging
Each time PAReplicate is run, the Vault creates a log file that records the process. This
file, called PAReplicate.log, is stored in the PrivateArk\Replicate folder on the machine
where the utility is run, usually the DR machine. When the log file reaches 100MB, it will
automatically be moved into the Logs\Old subfolder and a new log file will be created.
To enable a high level of tracing in the PAReplicate.log, specify the /EnableTrace
parameter in the PAReplicate utility. As most of the information required for simple
troubleshooting is regularly saved in the log file, this parameter is only necessary for
advanced troubleshooting.
In addition, critical log messages are copied to the Microsoft Event log.
PARestore
The PARestore utility enables you to restore Safes that have previously been either
replicated or backed up to the Vault.
The Safe data files are restored to the PrivateArk\Restored Safes folder in the same
structure as that in which they were backed up. After the metadata backup files are
restored to the PrivateArk\Restored Safes\Metadata folder, a synchronization procedure
will take place, after which users will be able to work with the files immediately.
Note:
When you restore a single Safe, its original Owners are not restored with the Safe data.
Safe members must be added manually
Only Users with the ‘Restore All Safes’ authorization in the Vault can restore a Safe. For
more information, refer to Required Access Rights, page 72.
For information about restoring the Vault, refer to the Privileged Account Security


Configure the backup user’s authentication:
1. In the PrivateArk Client, modify the Backup user’s password. Specify or
generate a strong password that contains at least one capital and one
numeric character.
2. Generate a credentials file for the Backup user to enable them to access the
Vault and replicate its contents. For more information, refer to Appendix A:
Creating Credential Files.
Test the Vault backup utility installation
1. On the machine where the Backup utility is installed, from the Replicate
installation folder, enter the following command:
> PAReplicate.exe vault.ini /LogonFromFile <user cred file>
2. Check the replication log to make sure that the Vault was replicated
successfully:
C:\Program Files\PrivateArk\Replicate\Replicate.log
Using a Third Party Backup System

The CyberArk Vault enables you to use a third party backup system to backup a Vault. It
recognizes several backup applications, which are specified during configuration
following installation. This ensures that the firewall protecting the files in the Vault will
recognize the backup application, and permit it access to the backup directory.
The backup server is external to the Vault environment, and as such does not benefit
from the Vault’s high level of security, but relies on Windows authorizations. Therefore, it
is essential that the backup server is totally secure and that only Users who have suitable
authority have access to it, despite the fact that the backup files are encrypted.
The Vault recognizes the following backup applications:
■ Backupexec
■ Netbackup
■ Networker
■ TSM
■ Arcserv
■ EDM
Following installation, the following parameters should be added to DBParm.ini:
■ BackupSoftware=<name of backup software as listed above>
■ BackupServerIp=<the IP address of the backup server>
These parameters enable the Server to identify the processes and default ports used by
the specified application. Different versions of the backup applications listed above might
use different processes and ports, which are not automatically recognized by the Vault. If
your version is not supported by the Vault, or if your backup application does not appear
in the above list, contact your CyberArk support representative.
Due to the importance and uniqueness of the metadata, before the backup procedure
begins, a “copy” is made of the entire metadata which is stored in the Metadata Backup

folder. This ensures that the original metadata is not locked and removes the risk of any
changes being made to the original metadata.
The following diagram depicts the scenario that occurs during backup to a third party
backup application.
Third party backup process
When working with a global backup system, the following scenario occurs:
Step 1: The PrivateArk Prebackup utility (PAPrebackup.exe) creates metadata backup
files and copies them to the Metadata Backup folder.
Step 2: The external backup application copies all the files from the Data folder and the
Metadata Backup folder.
Install third party backup software on the Vault
1. Before installing the Password Vault, install the backup software.
2. Check that the backup server can access the Vault machine.
Following the installation
1. Configure the backup user’s authentication:
a. In the PrivateArk Client, modify the Backup user’s password. Specify
or generate a strong password that contains at least one capital and
one numeric character.
b. Generate a credentials file for the Backup user to enable them to
access the Vault and replicate its contents. For more information,
refer to Appendix A: Creating Credential Files.
2. Create scheduled tasks to replicate the Vault according to your Enterprise
standards.

Backup Guidelines
Depending on your password policies and how frequently the passwords in the Vault are
changed, it is recommended to create two scheduled tasks, as follows:
■ Full replicate – Weekly
■ Incremental – Nightly
If the passwords in the Vault are changed frequently, replications should be carried out at
frequent intervals in order to constantly have an up-to-date replication of all the
passwords.
Schedule these replicates to take place in the middle of the night when there is no Vault
activity.

Disaster Recovery Site

In this section:
Before Installation
Before installing the DR Vault, prepare the following:
Keys – Use the same CyberArk keys as in the Production Vault.
Note:
You will need the Operator CD during Server installation
Version – Use the same CyberArk Vault Server version as the Production Vault.
Customer License - Use the DR Vault license.xml file provided by your CyberArk
support representative especially for the DR Vault.
Note:
If your Safes are on an NTFS partition, the replicated Safes should also be on an
NTFS partition, and not FAT/FAT3
Installation
Before installing the Disaster Recovery service
1. On the Disaster Recovery machine, install a CyberArk Vault Server and
PrivateArk Client, as described in Installing the CyberArk Vault.
2. After you have installed the CyberArk Vault Server on the DR site, start the
DR Vault and check that it is up and running, even though it is an empty
Vault.
3. Stop the CyberArk Vault Server on the DR site.
4. In HA environments, take the PrivateArk Server resource offline:
a. In the Failover Cluster Manager, open Services And Applications.
b. From the list of applications, select CyberArk Vault; in the left-hand
pane the application resources are displayed.
c. Right-click PrivateArk Server resource, then select Take this
resource offline; the PrivateArk Server resource is taken offline and
its status is changed.
Install the CyberArk Vault Disaster Recovery Service
the contents of the Disaster Recovery folder.

89 Disaster Recovery Site
or,
as Administrator.
The Disaster Recovery Vault wizard starts automatically and the CyberArk
Installation window is displayed, as shown below.
Note:
You can exit the CyberArk Disaster Recovery Vault installation at any time by
clicking Cancel. You can return to the previous installation window by clicking
Back, where applicable
3. Click Next to proceed to the next step of the Disaster Recovery Vault
installation, which enables you to view the Disaster Recovery Vault license
and accept the terms of the license agreement, as shown below.

to the next step of the installation which enables you to enter user information
for licensing purposes, as shown below.

to select the folder on the server in which the Disaster Recovery Vault files
will be located, as shown below.

8. Click Next to accept the default location provided by the Disaster Recovery
Vault installation, displayed in the Destination Folder area, and proceed to
the next step of the installation,
or,
Click Browse to select another location, and then click Next to proceed to the
next step of the installation.
9. The next step of the installation prompts you for a password for the DR User,
as shown below.
Note:
NoteThis User should be an Owner with backup permissions on all of the Safes
he might need to replicate to the Disaster recovery site. In addition, this User must
be an Owner on the system Safe (only with backup permissions). It is
recommended to use the ‘DR’ user that has been created in the Vault especially
for this purpose
A user credentials file for automatic logon is created for this Replicate user. This
credentials file contains the specified username and an encrypted version of the
specified password.
10. Click Next to proceed to the next step of the installation where you specify
the Address and the port of the Production Vault, as shown below.

11. Click Next to proceed to the next step of the installation where you click
Finish to complete the Setup.
The CyberArk Vault Disaster Recovery service starts automatically when you
restart the machine.
Check that the installation was successful

■ Open the PADR.log and check that the Disaster Recovery Vault was installed
successfully and a replication was initiated immediately.
■ Later, make sure that one full replication and at least one incremental replication
were carried out. This may take several hours.

Add restrictions to the Protected Credentials file

During installation, a user credential file is generated automatically with the name and
authentication details of the Replicate user, and is stored in the Disaster Recovery
installation folder. This enables automatic Vault replication to the Disaster Recovery site
regularly, according to the ReplicateInterval parameter in PADR.ini.
This credentials file includes a security restriction which specifies that it can only be used
by the DR Vault. To create a credentials file that specifies more security restrictions, use
the CreateCredFile utility in the PADR installation folder. For more information, refer to
Appendix A: Creating Credential Files.
Enable the Disaster Recovery user

The Disaster Recovery User (DR User) is a predefined User that is added automatically
as an Owner to every Safe, and only has the access rights required to replicate the
Safes. The predefined DR User makes it easier to replicate your data to the Disaster
Recovery Vault.
When the DR user is created during installation, the DR User account is disabled. Before
using the DR User, enable it in the Primary Vault and update its password.
Configure the Disaster Recovery Vault environment

■ Configure the Disaster Recovery Vault Environment in the same way as the
Production Vault. This includes the following components:
■ Transparent User Management
■ Authentication
Specify how frequently the DR Vault will be updated

The DR parameter file determines how frequently the Production Vault will be replicated
to the DR Vault. When you set these parameters, take into consideration that the more
frequently a replication is performed, the less chance there is that information will be lost
if the Production Vault stops suddenly. On the other hand, constant replications use Vault
resources and may affect other Vault tasks.
■ In PADR.ini, specify the following parameter:
■ ReplicateInterval – The minimum time interval in seconds between data
replications.
Hide the Vault users hierarchy

Hide hierarchy
1. On the Disaster Recovery server machine, open the Server installation
directory. By default, this is C:\Program Files
(x86)\PrivateArk\Server.
2. Open dbparm.ini and add HideVaultUsersTree=Yes.
3. Save dbparm.ini and close it.

Test the DR Vault Installation

Test the installation
1. Disable the connectivity between the DR Vault and the Production Vault.
2. In the PrivateArk Server console, check that the DR Vault has begun
working as an active Vault. For more information, refer to Check that the
CyberArk Digital Vault started successfully, page 17.
3. In the PrivateArk Client on the DR Vault machine, define the new DR Vault
and check that you can access it with the DR user. For more information,
refer to Defining a Vault in the Privileged Account Security Implementation
Guide.
Reset the DR Vault

After testing the DR Vault installation, reset the DR Vault so that it is ready for a failover
when necessary:
Reset the vault
1. On the DR Vault machine, stop the PrivateArk Server service.
2. In PADR.ini, do the following:
a. Specify the following parameter:
■ Failovermode=no
b. Delete the following parameters:
■ NextBinaryLogNumberToStartAt
■ LastDataReplicationTimestamp
3. Start the CyberArk Vault Disaster Recovery service.
4. Check the PADR.log file to make sure that a replication was initiated
successfully.
Later, make sure that one full replication and at least one incremental replication
were carried out. This may take several hours.

95 Amazon Web Services (AWS)
Amazon Web Services (AWS)

This section describes how to deploy CyberArk's Privileged Account Security (PAS)
solution on Amazon Web Services (AWS). It introduces you to a set of best practices
that will help you define and build a set of security policies and processes for your
organization, so that you can protect CyberArk data and assets in the AWS Cloud. It also
describes how to install and configure PAS on AWS.
This section is for IT operations and security personnel, and assumes that you are
familiar with basic security concepts in the area of networking, operating systems, data
encryption, and operational controls. For more information about securing instances that
run on AWS, refer to the AWS Security Best Practices at
https://aws.amazon.com/whitepapers/aws-security-best-practices/.
This deployment is for customers who run 100% of their infrastructure on AWS or
customers who require CyberArk's Privileged Account Security solution to secure an
environment that is totally isolated or runs in the cloud. For customers who are still
running their data center on premise, it is recommended to run CyberArk's Digital Vault
on premise to mitigate some of the risks mentioned in Security Considerations, below.
In this section:
Security Considerations
While installing the Vault Server on a virtual environment usually works seamlessly in the
CyberArk Secure Platform, it also introduces risks that are not present in a standard
Secure Platform configuration.
A virtual environment implementation provides a remote attack vector, both from outside
of the virtual host environment and from other virtual guest images, bypassing physical
datacenter security layers. This may allow an attacker to obtain the whole guest image of
the Vault server, introducing risks that are not present in a normal Secure Platform
configuration.
Following are the potential security risks associated with a Vault that is hosted on
VM/Cloud and CyberArk’s recommendations to mitigate these risks:
■ An attacker can potentially initiate multiple simultaneous “brute force” password
attacks against existing CyberArk users, using multiple copies of the virtual machine.
Because an attacker can create unlimited copies of the virtual machine, account
lockout mechanisms can be bypassed.
■ An attacker’s ability to reverse-engineer the encryption of the protected data is
increased. To start the Vault application, the attacker must have access to the
encryption keys and, because of this, standard implementation practices call for
placement of the encryption key on the Digital Vault OS file system. In a secure
physical environment, such as an enterprise datacenter, the risk of storing the keys
on the file system is mitigated by physical security layers. However, if a an attacker
takes possession of a virtual machine, he would have access to the operating system,
encryption keys and encrypted data, making reverse-engineering on the encryption
possible.

Note that there are two mitigating controls available for this risk:
■ Utilizing a hardware security module (HSM) to securely store encryption keys off
the Digital Vault OS file system.
■ Mounting of encryption keys manually every time they are required. This
approach will prevent the DR Digital Vault instance from being available
automatically during a disaster.
■ Port 80 needs to be opened to specific AWS addresses
By default, the Vault hardening ensures that outbound access from the Vault is
limited in time and is used only in cases where the Vault needs to access a 3rd party
server for uses such as authentication or provisioning (e.g: LDAP / RADIUS / etc).
This is in order to ensure that even if the Vault somehow becomes infiltrated by a
malicious party, it would be as difficult as possible to exfiltrate any data from it to the
outside world. Hence, while opening ports is required for the health of the AWS
image, it introduces a potential security risk.
Installation
Most of the process for installing the Privileged Account Security solution on AWS is
exactly the same as regular Privileged Account Security installation. However, there are
differences when installing the Digital Vault, the Privileged Session Manager and the
Privileged Session Manager SSH Proxy.
In this section:
Install the Digital Vault

Prerequisites
1. For this installation, prepare two machines. Install Windows 2012 R2 on
each one. These machine will be used for the following:
■ Vault – The Vault will be installed on the first machine.
■ Management - The second machine will be used for remote installation and
Vault management.
2. Make sure that a VPC (Virtual Private Cloud) network is installed on both
machines.
For integration with external applications and utilities, add the suitable security
group rules to your AWS machine.
For example, to add ENE, specify the following rule:
For a list of ports and protocols used by the Vault, refer to the Privileged
Account Security System Requirements document.
3. On the machine that will be used for management, open an RDP connection
to the Vault machine's private IP address. This is usually 172.x.x.x.
Install the Vault
1. Install the Vault on the Vault machine without hardening. This procedure
describes how to perform the hardening procedure manually. For more

97 Amazon Web Services (AWS)
information, refer to the Privileged Account Security Installation Guide.

2. Using a text editor, from the Vault installation folder, in the
Hardening\StandaloneVault subfolder, open the Windows2012Security.inf
file, using the following command:
<Vault Installation Path>\Hardening\StandaloneVault\
Windows2012Security.inf
3. At the end of the [Service General Setting] section, above [Profile

Description], add the following lines:
"xensvc",2,""
"Ec2Config",2,""
"AWSLiteAgent",2,""
This will allow the services that Amazon instances require to operate properly.
4. In the Vault installation folder, in the Hardening subfolder, open the
Hardening.ini configuration file and set HardenWindowsFireWall=No.
5. In C:\, create a new directory called C:\temp\logs. This directory will be used
for the hardening procedure logging.
6. In the Vault installation folder, open the dbparm.ini configuration file and add
the following:
AllowNonStandardFWAddresses=
[169.254.169.250,169.254.169.251,169.254.169.254],Yes,80:out
bound/tcp,80:inbound/tcp
7. Make sure that the “PrivateArk Server” service is down.

8. Harden the firewall manually:
a. At a command line, run the following command as an Administrator:
cd <Vault Installation
Path>\Server\HardeningCAVaultHarden.exe
StandaloneVault c:\temp\logs\ /AllowRDP <The Private
IP address of the Client Machine>
b. Configure the inbound rules - Remove all inbound firewall rules from the
firewall, except rules whose name prefix is dbmain.exe.
c. Configure the outbound rules – Remove all outbound firewall rules, except
rules whose name prefix is dbmain.exe.
d. In the firewall management, add the following new outbound rule :
Allow the connection
Protocol & Port: TCP 80
Remote Addresses: 169.254.169.250, 169.254.169.251,
169.254.169.254
* AWS may require additional IP addresses. For a full list, contact AWS
support .
Profiles: Domain, Private, Public

9. Start the PrivateArk Server service.

10. Make sure that the startup type of the “PrivateArk Server” service is set to
Automatic.
Install the Privileged Session Manager and Privileged Session

Manager SSH Proxy
When installing the Privileged Session Manager and/or the Privileged Session Manager
SSH Proxy on AWS, use the following additional security guidelines, which explain how
to increase security in your PSM/PSMP environment on AWS:
■ In your firewall, add an outbound rule for the PSM servers that blocks all traffic to the
remote 169.254.169.254 IP address. This address exposes the meta-data of the
EC2 instance when accessing it from within the server and, therefore, must be
blocked.
■ Do NOT save any kind of AWS security credentials or certificates locally on the PSM
server.
Install the Privileged Session Manager on AWS
1. Run the standard installation procedure, as described in Privileged Session
Manager for Customers, page 136.
2. After installation, before hardening the PSM server machine, do the
following:
a. Remove the read-only permissions from the PSMHardening.ps1
script. This script is in the Hardening subfolder of the PSM installation
folder.
b. Using Notepad, open the PSM hardening script.
c. In $AWS_FOLDER_PATH, specify the path where Amazon services
(EC2ConfigService, XenTools, etc.) are installed. By default,
Amazon services are installed in C:\Program Files\Amazon.
d. Save the hardening script and close it.
For more information about hardening the PSM server machine, refer to
Harden the PSM server machine, page 160.
Install the Privileged Session Manager SSH Proxy on AWS
1. Run the standard installation procedure, as described in Privileged Session
Manager SSH Proxy.

99 Authenticate to the Privileged Account Security Solution
Authenticate to the Privileged Account Security

Solution
In order to be able to work with the Privileged Account Security solution, users must
authenticate to the Vault using a predefined authentication method. This section
introduces you to the authentication methods that the MSSP supports and describes how
they work.
For more information, refer to the Privileged Account Security Implementation Guide.
In this section:
Define Authentication Methods in PVWA

During installation, the authentication methods that you specify are configured
automatically. However, some of the authentication methods require additional
parameters to be set manually after installation.
Define a default authentication method

The default authentication method for users can be specified during installation.
However, you can change the default authentication method after installation in the
GeneralSettings section of the Authentication Methods parameters:
Define a default authentication method
1. Log onto the PVWA with the Administrator user.
click Options; the Password Vault Options parameters will appear.
3. Expand Authentication Methods, and select GeneralSettings.
4. Set the following parameters to define the default authentication method for
users.
DefaultMethod – The ID of the authentication method that will be
automatically be used when a user connects to the application. After
installation, the default authentication method is CyberArk Password
authentication.
RememberLastUsedMethod – Whether or not the most recently used
authentication method will be stored in a browser cookie and
automatically reused the next time the user displays the PVWA.
5. Click Apply to save the new configurations and apply them immediately,
or,
Click Save to save the new configurations and apply them after the
period of time specified in the RefreshPeriod parameter.

Configure the primary authentication method

During installation, the PVWA is configured to support the authentication methods
selected by the user. You can modify these configurations after installation in the
Authentication Method parameters.
Configure authentication methods
1. In the System Configuration page, click Options, then expand
Authentication Methods; a list of the supported configuration methods is
displayed.
2. Select an authentication method to display its configuration.
3. Set any of the following parameters to modify the authentication method for
users.
Id – The identifier of the authentication module. This parameter is
configured automatically during installation.
DisplayName – The display name of the authentication method that will
be displayed in PVWA.
Enabled – Whether or not the authentication module can be used. This
is configured during installation, depending on whether or not the
authentication method is selected.
LogoffUrl– A URL to redirect to on logoff. This cannot be set during
installation and must be set manually afterwards. Specify the whole
URL, including HTTP/HTTPS. For example,
https://www.company.com.
or,
CyberArk Password Authentication

The CyberArk Vault uses a Shared Secret in order for the Server to identify a person.
This Shared Secret can be a password or a combination of a password and another type
of authentication.
The Vault can enforce a password policy to avoid usage of passwords that can be easily
guessed.
When a user logs on to the Vault, the CyberArk interface sends a logon request to the
Server. The Server and the Client use the two-way challenge-response protocol to prove
to each other that they know the Shared Secret.
As part of the challenge-response protocol, a Session Key is received by the Client if the
authentication is successful. The Client and the Server encrypt the rest of the session
using the random Session Key selected by the Server.
The Vault Administrator creates a password for each new User to enable them to logon
to the Vault. For security reasons, users should change their passwords after logging on
the first time using the password created for them by the Vault administrator.

The System Administrator defines the password rules, such as type of character and
length of password, although the default is a minimum of 6 alphanumeric, mixed case
characters. When users create their own passwords, they can use any combination of
alphanumeric characters that meet these criteria.
Configure the User Account

In the PrivateArk Client, configure the user account to authenticate with password
authentication.
1. Log on to the PrivateArk Client as the predefined Administrator user.
2. Display the User properties of the user to configure, and display the
Authentication tab.
3. From the Authentication method drop-down list, select Password, then click
OK.
Authenticate through the PVWA

Configure Access through the PVWA
1. Log onto the PVWA as the predefined Administrator user.
click Options; the main system configuration editor appears.
3. Expand Authentication Methods; a list of the supported configuration
methods is displayed.
4. Select cyberark and make sure the Enabled property is set to Yes.
or,
Test Password Authentication in the PVWA
1. In the PVWA, in the list of available authentication methods, click Password;
the Password authentication page appears.
2. Type the administrative user’s name and password, then click Sign in; the
PVWA authenticates the user’s password authentication, grants them
access to the PVWA, and displays the accounts that the user is authorized to
view.
Authenticate through the PrivateArk Client

Configure Access through the PrivateArk Client
1. In the PrivateArk Client, right-click the Vault to configure then, in the pop-up
menu, select Properties; the Vault Server Properties window appears.
2. Click Advanced; the Advanced Server Properties window appears.

3. Select PrivateArk authentication, then click OK.

Test Password Authentication in the PrivateArk Client
1. In the PrivateArk Client, double-click the Vault to enter; the Logon to Vault
window appears.
2. Type the administrative user’s name and password in the appropriate edit
boxes, then click OK; the PrivateArk Client authenticates the user’s
password authentication, grants them access, and displays the Safes that
the user is authorized to view.
LDAP Authentication
The CyberArk Vault transparently supports User Accounts and Groups of users whose
details are stored externally in LDAP-compliant directories. In order to maintain the
typically high level of security in the Vault, the security attributes of LDAP User Accounts
and Groups are managed internally.
For information about configuring the Vault to manage users through LDAP, refer to
Configure User Management via LDAP, page 118.
Requirements
Users can authenticate to the Vault with LDAP authentication from Password Vault Web
Access through any of the following directories:
■ MS Active-Directory – Windows 2003 with Service Pack 2, Windows 2008
(native/mixed mode), Windows 2012, Windows 2012 R2, Windows 2016
Note: From the next version, MS Active Directory 2003 will no longer be supported as it has
reached its End of Life by the vendor. Customers using MS Active Directory 2003
may continue using the Digital Vault v9.9.
■ Sun One v5.2
■ IBM Tivoli Directory Server v6.0
■ Novell eDirectory v8.7.1
■ Oracle Internet Directory v10.1.4
This list may be updated frequently as additional directories are certified. Contact
CyberArk Customer Support for information about additional directories that are not
mentioned in the list above.
Configure LDAP Authentication

Users whose details are stored in an LDAP-compliant directory can authenticate to the
Vault directly from the PrivateArk Client or the PVWA. The Vault communicates with
LDAP-compliant directory servers to obtain User identification and security information,
and automatically provisions Vault users based on the external user account and group
membership and attributes.
Configure LDAP Authentication
1. Configure the Vault to recognize LDAP directories. For more information,
refer to Configure User Management via LDAP, page 118.
2. Configure the directories that contain users who will be authorized to access

the PVWA:
a. In the PrivateArk\Server\LDAP folder, open the Directory parameter
file for the directory to configure.
b. In the LDAPDirectoryUsage parameter, add the Authentication
value. This will enable the Vault to authenticate users listed in the
configured directory.
LDAPDirectoryUsage=Authentication
In the following example, the directory is configured for transparent

user management as well as LDAP authentication.
LDAPDirectoryUsage=ExternalObjectsCreation,Authentic
ation

In the PrivateArk Client, configure the user account to authenticate with LDAP
authentication.
Authentication tab.
3. From the Authentication method drop-down list, select LDAP
Authentication, then click OK.

4. Select ldap and make sure the Enabled property is set to Yes.
or,
Test LDAP Authentication in the PVWA
1. In the PVWA, in the list of available authentication methods, click LDAP; the
LDAP authentication page appears.
2. Type the user’s name and password as they are specified in the LDAP

directory, then click Sign in; the Vault authenticates the user’s information in
the LDAP directory, then grants them access to the Vault.

3. Select LDAP authentication, then click OK.
Test LDAP Authentication in the PrivateArk Client
window appears.
2. Type the user’s name and password as they are specified in the LDAP
directory, then click OK; the Vault authenticates the user’s information in the
LDAP directory, then grants them access to the Vault.
RADIUS Authentication
The Vault enables users to log on through RADIUS authentication (Remote
Authentication Dial-In User Service) using logon credentials that are stored in the
RADIUS server. The Vault also supports RADIUS challenge-response authentication, in
which the server sends back a challenge prompting the user for additional logon
information, such as additional authentication information contained on external tokens.
Requirements
In order to enable users to authenticate to the EPV with Radius Authentication, you
require the following:
■ Radius Server
■ Certificate – A Vault certificate to create an initial secured session prior to the
RADIUS authentication. This certificate is optional, but recommended.
■ Radius Secret – A password known to only the RADIUS server and the CyberArk
Vault. This password can contain up to 15 characters.
Configure RADIUS Authentication

The Vault enables users to log on through RADIUS authentication (Remote
Authentication Dial-In User Service) using logon credentials that are stored in the
RADIUS server. The Vault also supports RADIUS challenge-response authentication, in
which the server sends back a challenge prompting the user for additional logon
information, such as additional authentication information contained on external tokens.
Preparation
1. In the RADIUS server, define the CyberArk Vault as a RADIUS client/agent.
For more information, refer to RADIUS server documentation.
2. Gather the following information from the RADIUS server:

IP address of the RADIUS server

Port of the RADIUS server
Host name of the RADIUS client (Vault machine). This name must be
identical to the name you entered for the RADIUS client/agent.
Password secret
Configuration
1. Prepare and install a Vault certificate and private key on the Vault machine:
Note:
For security reasons, it is highly recommended not to use a self-
signed certificate for RADIUS authentication.
The Vault certificate enables the Server to authenticate to a client. You can
obtain a certificate from a Certificate Authority (CA).
If you require a new certificate and private key:
a. Run CACert with the request parameter to generate a request for a
server authentication certificate.
Parameter Description Mandatory
Request Prepares a Certificate Signing

Request (CSR) file.
/ReqOutFile The name of the request output Yes

file.
/ReqOutPrvFile The name of the private key No

output file.
The default value is the full
pathname of the Server
PrivateKey parameter as
specified in DBParm.ini.
/KeyBitLen The bit length of the output No

private key.
The default value is 2048.
/Country The name of the country to No

specify in the certificate. Use a
2-letter code.
/State The full name of the State or No

Province to specify in the
certificate.
/Locality The name of the locality or city to No

specify in the certificate.
/Org The name of the No

organization/company to specify
in the certificate.

/OrgUnit The name of the organizational No

unit name to specify in the
certificate. For example, the
department or section.
/CommonName The Common Name to specify in Yes

the certificate. For example, the
DNS name of the Vault.
Note: Either the
‘/CommonName’ parameter or
the ‘SubjAlt’ parameter, or both,
must be specified.
/SubjAlt The subject alternative names. No

For example,
“DNS:www.cyberark.com,
IP:1.1.1.250”.
Note: Either the
‘/CommonName’ parameter or
the ‘SubjAlt’ parameter, or both,
must be specified.
For more information, refer to CACert.
In the following example, a certificate request will be created for a
Vault named “MyVault.mycompany.com” whose IP address is
1.1.1.250. The request will include details about the location of the
Vault, and the department that it will be used for. The request file will
be stored in “c:\Requests\VaultCert.req”.
cacert request /reqoutfile c:\Requests\VaultCert.req
/country "US" /locality "Boston" /org "My Company"
/orgunit "Management" /commonname
"MyVault.mycompany.com" /subjalt "IP:1.1.1.250"
Note:
The ‘commonname’ parameter must specify the Vault DNS.
When CACert creates the request, it also generates the private key
and saves it in the location specified in the ServerPrivateKey
parameter in DBParm.ini during Vault installation.
If the keys used during installation were copied to the server machine,
the certificate files will be stored in the same folder as the keys.
b. Send the request file to the CA.
c. Download the prepared certificate file, <.cer>, to a local folder on the Vault
server.
d. Run CACert with the install parameter to install the certificate in the Vault,
using the following syntax:

CACert install /CertFileName <certfile.cer>
Install Installs the certificate to be used by the

Vault.
/CertFileName The full pathname of the certificate file to Yes

install.
For example,
CACert install /CertFileName c:\certificates\certfile.cer
If you already have a certificate and private key:

a. Make sure that the certificate has enhanced key usage for the following:
Server authentication
b. Make sure that the certificate has key usage for the following:
Digital Signature
Key Encipherment
c. Make sure that the ‘cn’ specified in the certificate is the Vault DNS.
d. Run CACert with the show parameter to view the certificate information.
e. Export the certificate and private key file to PKCS#12 format.
f. Run CACert with the import parameter to extract the certificate and the
private key from the <.pfx> file and install them in the Vault, using the
following syntax:
CACert import /InFile <certkey.pfx>
Import Imports and installs a certificate from a “.pfx”

file.
/InFile The full path of the file that contains the key Yes
and certificate to import (.pfx).
For example,
CACert import /InFile c:\certificates\certfile.pfx
For more information, refer to CACert.

g. Stop the Vault server.
h. In the Vault installation folder, run CAVaultManager with the
‘SecureSecretFiles’ command, as shown below, to create a file that contains
an encrypted version of the RADIUS secret.
Specify the full path of the file that will contain the encrypted secret, and the
secret itself. This file may be in dat, ini, or txt format.

Parameter Description
SecureSecretFiles Secures the Vault’s secret files.
/SecretType The type of secret to secure. Options are LDAP,

Radius, or HSM.
/Secret The secret. This password can contain up to 15

characters.
/SecuredFileName The name of the file where the secured secret is

stored.
/FileSectionName Name of LDAP host section to secure within the file.

Default is LDAP directory section.
Note:
This parameter is not relevant for Radius
configuration and should not be used to
create the Radius secret file.
For more information, refer to CAVaultManager.

The following example will encrypt the secret RADIUS/Vault password,
which is VaultSecret, and store it in a file called radiusauth.dat in the
current folder.
CAVaultManager SecureSecretFiles /SecretType Radius
/Secret VaultSecret /SecuredFileName radiusauth.dat
Note:
If you don’t specify the secret in the SecureSecretFiles
command, you will be prompted for it.
i. In DBParm.ini, set the RadiusServersInfo parameter. All the details are

specified in the same parameter, separated by semicolons.
In the following example, the IP address of the RADIUS server is 1.1.1.250,
and its port is 1812. The name of the RADIUS client (Vault machine as
entered in the RADIUS server) is ‘vaulthostname’, and the name of the file
that contains the secret password is ‘radiusauth.dat’. In this example, the file
is stored in the current folder, and therefore the full path is not specified.
RadiusServersInfo=1.1.1.250;1812;vaulthostname;radiusauth.
dat
For high-availability: You can specify more than one RADIUS server by
separating the details of each server with a comma.
j. Start the Vault server.
Following Configuration

Store the file that contains the Radius secret for in a Safe for safekeeping. This
file was created with the ‘CAVaultManager SecureSecretFiles’ command.
Configure the user account

In the PrivateArk Client, configure the user account to authenticate with RADIUS
authentication.
Configure the user account
Authentication tab.
3. From the Authentication method drop-down list, select Radius
authentication, then click OK.

4. Select radius and make sure the Enabled property is set to Yes.
or,
Click Save to save the new configurations and apply them after the period of
time specified in the RefreshPeriod parameter.
Test RADIUS Authentication in the PVWA
1. In the PVWA, in the list of available authentication methods, click RADIUS.
2. Type the administrative user’s Username and logon information in the
appropriate edit boxes, then click Sign in; a secure channel is created
between the client and the Vault through which this logon information is sent.
3. If the RADIUS server requires more information to authenticate the user to
the Vault, a RADIUS Challenge window appears, prompting you for it.
4. Specify the additional logon details, then click OK; the RADIUS server
authenticates you to the Vault.



3. Select RADIUS authentication; in the Secured session properties, the
Trust self-signed certificates option is selected. This enables users to log
onto the Vault with self-signed certificates.
For testing, do not select Allow third party authentication with self-
signed certificate.
4. Click OK.
Test RADIUS Authentication in the PrivateArk Client
window appears.
2. Type the administrative user’s Username and logon information in the
appropriate edit boxes, then click OK; a secure channel is created between
the client and the Vault through which this logon information is sent.
3. If the RADIUS server requires more information to authenticate the user to
the Vault, a RADIUS Challenge window appears, prompting you for it.
4. Specify the additional logon details, then click OK; the RADIUS server
authenticates you to the Vault.

111 Install the MSSP
Install the MSSP

After you have installed the Digital Vault, CPM, and PVWA, you can convert the Vault
into a multi-tenant environment and create the MSSP.
Convert to a Multi-Tenant Vault

Convert to a Multi-Tenant Environment
1. On the Vault server, run the script that converts the Vault to a Multi-tenant
Vault and determines which Safes are available for customers.
a. You will receive the Vault Multi Tenancy Scripts folder from your
CyberArk representative. Copy the following files to a local folder on
the Vault machine server:
Enable vault in multi tenancy mode.enc
Make safes as shared safes in multi tenancy mode.enc
Vault hardening.bat
b. At a command line, as an administrator, run the "Vault
hardening.bat" batch script file using the script password that you will
receive from your CyberArk representative to use as an argument, as
shown in the following example. The password is located in the “Multi-
Tenants-Scripts” folder.
"Vault hardening.bat" <Multi-Tenants-Scripts.txt
content>
c. Verify that both scripts completed successfully - you will see the
following message: PrivateArk Server service was started
successfully.Check that no errors appeared and that the Vault server
is running.
2. You will receive the MSSP installation package from your CyberArk
representative as a zip file. Save it in on your local computer, extract it to the
PVWA installation folder, then do the following:
a. Double-click setup.exe,
or,
On systems that are UAC-enabled, right-click Setup.exe, then select
Run as Administrator.
The installation process begins and the Setup window appears.

If you have not already closed any open Windows applications, it is

strongly advised that you do so at this point.
Note:
You can exit installation at any time by clicking Cancel.
You can return to the previous installation window by
clicking Back, where applicable.
b. Click Next to proceed to the next step of the installation, which

enables you to view the CyberArk license and accept the terms of the
License Agreement.
c. Read the license agreement, then click Yes to accept its terms and
proceed to the Ready to Install window.

d. Click Install to begin the installation process; the installation process

begins and the Vault's connection details window appears.
e. Specify the name and password of the Vault Admin user who will
create the MSSP environment in the Vault, then click Next; the
installation process will now build the MSSP environment in the Vault
and on the PVWA machine.
f. After the MSSP environment has been created, the Setup Complete
window appears.

g. Click Finish to complete installation of the CyberArk Privileged

Account Security Solution for MSSPs.
3. Define the MSSP admin users:
If the MSSP users do not require LDAP:
In the PrivateArk Administrative Client, create the MSSP admin user
with full Vault permissions. Add this user as member of the MSP Admins,
Vault Admins and PVWAMonitor groups.
If the MSSP users require LDAP:
a. Log onto the PVWA as an administrator user, and use the
LDAP wizard to configure LDAP. For more information, refer to
Configure User Management via LDAP, page 118.
b. Update the Directory Map:
i. Log onto the PrivateArk Administrative Client as a Vault
administrator.
ii. From the Tools menu, select Administrative Tools, then
Directory Mapping; the Directory Mapping for Vault
window appears.
iii. From the Map list, Select Vault Group Mapping, then
click Update; the New/Update Directory Map window
appears.

iv. Depending on whether this Map will create users, groups,

or both, select Users, Groups, or both.
v. Select Users; the User Template button becomes active.
vi. Click User Template to display the New Directory Map
window and specify the user properties that will be given to
the External User Account when it is created.
vii. In the General tab, set the User type to EPVUser; the
following message appears:

viii. Click Yes then enable a quota, if necessary. To monitor

this user type’s activity, select Send email notification if
component is not connected.
ix. In the Authentication tab, set the authentication method to
LDAP Authentication.
x. In the Authorizations tab, select the Vault authorizations
that will be allocated to users created with this Map.
xi. In the Time Limitations tab, specify the time allocations that
will be allocated to users created with this Map.
xii. When you have finished specifying the Directory Map, click
OK; the Directory Map is updated and New/ Update
Directory Map window appears again.
xiii. Click OK and then Close.
c. Add the MSSP Admins External group as member of the MSP
Admins group:
i. In the PrivateArk Administrative Client, select Tools >
Administrative Tools > Users and Groups…
ii. Select the MSP Admins group in the Vault. Click Update.
iii. In the Update Group window click Add . Select LDAP
Groupto open the Add External Group window.
iv. Click Add from LDAP . Select the MSP Admins external
group.
d. Add the MSP Admins External group as member of Vault
Admins group:
ii. Select the Vault Admins group. Click Update.
iii. In the Update Group window click Add. Select LDAP
Group to open the Add External Group.
iv. Click Add from LDAP. Select the MSP Admins external
group.
e. Add the MSP Admins External group as member of
PVWAMonitor group:

ii. Select the PVWAMonitor group. Click Update.

iii. Click Add. Select LDAP Group to open the Add
External Group window.
iv. Click Add from LDAP. Select the MSP Admins external
group.
f. Log off from the PrivateArk Administrative Client.
g. Log onto the PVWA as an administrator user, then select
Administration > LDAP Integration > LDAP. Set
AddDomainToUserName to Yes, then click OK to save the
changes.
h. In the PVWA, select Administration> LDAP Integration>
LDAP> Directories, then select the MSSP's LDAP Directory. In
DomainName , set the domain name that will be used when
logging into the system with an LDAP user, then click OK to save
the changes.
4. If a certificate was installed to support the SSL secured communication,
configure the SSL secured communication:
a. In the PVWA Server, by default, in
C:\inetpub\wwwroot\PasswordVault\MSP, open the msp
web.config file, change the value of
TenantManagementAddress and MspManagementAddress to
https://<MACHINE_NAME>.<Machine Full Domain
Name>/PasswordVault/.
b. In IIS Default Web Site > PasswordVault/msp > SSL settings,
verify that Require SSL is checked.
c. In IIS Default Web Site > PasswordVault > SSL settings, verify
that Require SSL is checked.
5. If the PVWA was installed on a non-default partition/folder/port:
a. On the PVWA server machine, in [Installation
Drive]:\InstallationFolder\MSP, open the msp web.config file.
b. Change the values of TenantManagementAddress and
MspManagementAddress to http://ServerIP:Port/PVWA_
<ApplicationNameGivenDuringPVWAInstallation>}/.

Configure User Management via LDAP

The Privileged Account Security solution can be configured to manage users
transparently through a centralized User database. In large organizations, this is an
extremely efficient way of managing Users and streamlining administration. The
Privileged Account Security solution is a full LDAP (Lightweight Directory Access
Protocol) client, which communicates with LDAP-compliant directory servers to obtain
User identification and security information. This enables the automatic provisioning and
creation of unique and individual users based upon the external group membership and
attributes.
The Privileged Account Security solution communicates with LDAP compliant Directory
servers to obtain user identification and security information. This enables automatic
users and groups provisioning, providing transparent user management. Users are
provisioned with their user information (such as full name and email address), and also
with their security information such as groups. The latter can provide transparent access
control management as users can be given permissions in the vault based upon their
LDAP group membership.
For more information about configuring LDAP authentication, refer to LDAP
Authentication, page 102.
In this section:
Configure Transparent User Management
Before configuring the Vault

Create a Vault user in the LDAP Directory
A user in the External Directory enables the Vault to access the External directory and
retrieve information about users and groups. This user is not required to create or modify
any details.
■ In the External Directory, create an account for this user with ‘read only’ permissions.
Give this user permission to read the directory tree locations that contain the users
and groups that require access to the Vault.
Manage the Vault user's LDAP credentials in the Privileged Account Security
solution (optional)
The Vault user’s LDAP credentials account can be managed in the Privileged Account
Security solution. This enables you to store the user’s credentials securely in the Vault
and manage them automatically. These credentials can be used for other EPV tasks that
require LDAP connectivity, such as CPM auto-detection, and saves the need to define
two accounts – one for the Vault’s LDAP connectivity and one for the CPM. For more
information about auto-detection, refer to the Privileged Account Security
■ These credentials are created automatically in the Vault when the LDAP integration
is configured.

119 Configure User Management via LDAP
Configure the Vault to recognize LDAP directories

The CyberArk Vault can be configured to recognize LDAP directories using parameter
files that specify the directories that the Vault will recognize. Depending on how the
directory is specified, the Vault can work in either of the following ways:
■ Defining each directory separately – A parameter file that specifies exact details
of a directory can be created. A separate file is required for each directory that the
Vault will recognize.
■ Locating directories using LDAP referrals – The Vault can be configured to
work with the built-in LDAP referrals capability in the active directory.
Users who belong to the Vault Admins group can configure LDAP directories in the
Vault.
Configure the Vault to recognize LDAP directories
1. Configure LDAP over SSL connections:
On the Vault machine, import the CA Certificate that signed the certificate used
by the External Directory into the Windows certificate store to facilitate an SSL
connection between the Vault and the External Directory (recommended).
Note: For security reasons, it is highly recommended not to use a self-signed
certificate for LDAPS connections.
a. Display the Microsoft Management Console.
b. From the File menu, select Add/Remove Snap-in; the Add/Remove
Snap-in window appears.
c. Click Add; the Add Standalone Snap-in window appears.
d. Select Certificates, then click Add; the Certificates snap-in window
appears.
e. Select Computer Account, then click Next; the Select Computer window
appears.
f. Select Local Computer, then click Finish; the Add Standalone Snap-in
window appears.
g. Click Close; the Add/Remove Snap-in window appears and displays
Certificates (Local Computer).
h. Click OK; the main Console window appears.
i. Expand Certificates (Local Computer), then expand Trusted Root
Certification Authorities; the Certificates folder appears.
j. Select Certificates, then from the Action menu, select All Tasks, then
Import …; the Certificates Import Wizard appears.
k. Click Next; the File to Import window appears.
l. Select the certificate file to import, then click Next; the Certificate Store
window appears.
m. Select Place all certificates in the following store, then click Next; the
Completing the Certificate Import Wizard window appears and displays the
details of the selected certificate.
n. Click Finish; the selected certificate is imported to the computer account
and can now be used to authenticate external users to the CyberArk Vault.

Note: By default the Vault automatically sets the Distinguished Name of external
users. If the external user has a certificate in the external directory, the
Distinguished Name will be taken from the certificate. If not, the user DN in
the directory will be set.
To specify a user’s DN manually in the PrivateArk Client, in the relevant
Directory.ini file specify the following parameter:
UseLDAPCertificatesOnly=no
o. In the %WINDOWS%\System32\Drivers\Etc\hosts file, define the DNS of
the LDAP host, in order to prevent the firewall from blocking it.
Note: If the firewall is configured to allow DNS traffic, this step is not required.
1. Configure LDAP integration:
All the External Directories that the Vault will support must be defined so that
the Vault will recognize each External Directory and be able to work with it. The
LDAP Integration wizard enables you to configure External Directories in the
PVWA.
Note: The LDAP setup wizard will be enabled if no LDAP directories have been
defined. To rerun the LDAP Setup Wizard, delete all the defined directories in
the LDAP Integration configuration editor, then invoke the LDAP Setup Wizard
again in the System Configuration page.
a. Log onto the PVWA as an administrator user. Make sure that this user
belongs to the Vault Admins group so that you have the required
permissions to configure LDAP integration.
b. Click ADMINISTRATION to display the System Configuration page,
then click Setup Wizard.
The Setup Configuration wizard displays the Vault setup page.
By default, LDAP integration is selected.

c. Click Next; the LDAP Configuration Setup page appears.
d. Specify the following parameters to configure the LDAP connection to an

External Directory:
■ Name – The name of the External Directory that the Vault will
recognize. After external users and groups have been defined from the
specified directory, this parameter must not be changed.
■ Directory Type – The name of the directory profile file that represents
the profile the Vault should use when working with the specified LDAP
directory. Choose from a list of predefined directory profiles. By default,
MicrosoftADProfile.ini is specified.
■ Address – The IP address of the host server where the External
Directory exists. If the Vault will use an SSL connection to connect to the
External Directory, this name must match the subject that appears in the
Directory certificate.
Note: The server name and its IP address must also appear in the “Hosts” file
of the Windows\System32\Drivers\etc folder.
■ Port – The port that will be used to access the specified server. The
standard port for SSL LDAP connections is 636, and for non-SSL LDAP
connections is 389.
■ LDAP Bind User – The full Distinguished Name of the Bind user. For
Microsoft Active Directory, you can specify the Windows user name
instead of the full Distinguished Name. This user must be a member of
the same AD Domain group(s) as the external users and groups that will
be defined in the Vault.
■ LDAP Bind Password – The password for the user specified in the
Bind User field.
■ LDAP Bind Context – The base context of the External Directory.
e. Click Test; the Setup Configuration Wizard runs a syntax and integrity
check of the specified External Directory parameters and selected profile
file.
This test must be performed before you can continue to the next step, so
that you can define the LDAP default mappings.
Note: If a message indicating that the Server is down is displayed, the hosts file
might not be configured correctly or that the Vault cannot access the DC.
Make sure that the IP address is specified correctly in the hosts file in order
to resolve the server name.

f. After the syntax and integrity check has finished successfully, click Save
and Continue; the second LDAP Configuration Setup page appears.
You can map typical Privileged Account Security roles to groups in the
LDAP or AD directory. Users who belong to these LDAP groups will be
automatically assigned to the relevant roles in the Privileged Account
Security system.
This step is optional, and in case the default roles are not suitable for the
organization, this step can be completed later through the PrivateArk Client.
For more information, refer to Managing Directory Maps in the Privileged
g. Specify LDAP groups for the following roles:
■ Vault Admins – This is a highly privileged role for users who will manage
the Vault Server.
■ Auditors – This role represents auditor users and automatically gives
them access to information such as audit logs, reports and session
recordings.
■ Users – This is a default role for the rest of the Privileged Account
Security users. It allows users to login to the system, but does not give
them any permissions. These can be given later through Safe
membership
External groups will be created in the Vault for these LDAP groups and
default mapping rules will be automatically created for them. In addition,
each external group is added to a corresponding Vault group, as listed in the
following table:
External group Vault group
Vault Admins Vault Admins and PVWAMonitor
Auditors Auditors
Users No mapping to any Vault group

To define more advanced mapping configurations, refer to Managing
Directory Maps in the PAS Implementation Guide.
h. Click Finish; the configuration for the specified LDAP directory is saved.
You can view the LDAP configurations and modify them manually in the
LDAP Integration configuration. For more information, refer to the
Privileged Account Security Implementation Guide.

Configure the Vault to Recognize Multi-lingual External Directories

The CyberArk Vault recognizes multi-lingual external directories. Each Vault can
recognize English and one other language.
1. In the Control Panel, select Regional and Language Options, then display the
Advanced tab.
2. Select the additional language to recognize, then click OK.
3. Restart the computer.
Synchronize External Users and Groups in the Vault with the External
Directory
The following parameters in DBParm.ini determine the way External Users and Groups
in the Vault will be synchronized with the External Directory.
■ To specify the synchronization schedule between the External users and groups in
the Vault with the External Directory, add the following parameter:
AutoSyncExternalObjects
This parameter determines if and when the Vault’s External users and groups will be
synchronized with the External Directory. It specifies four parameters, as follows:
■ Whether or not to synchronize the Vault’s External users and groups with the
External Directory
■ The number of hours in one period cycle.
■ The hours during which the synchronization will take place.
The default parameter value specifies that the Vault’s External users and groups will
be synchronized with the External Directory once in a 24-hour cycle between the
hours of 1 and 5, as follows:
AutoSyncExternalObjects=Yes,24,1,5
■ To update details of the Vault’s External users and groups with the External
Directory, add the following parameter:
ExternalObjectsUpdatePolicy
This parameter specifies whether or not the synchronization process between the
Vault’s External users and groups and the External Directory will update the Vault’s
External users and groups.
The default parameter value specifies that External users and groups will be updated
with any changes in the External Directory, as follows:
ExternalObjectsUpdatePolicy=UpdateAll
■ To delete External users or groups in the Vault if they do not exist in the External
Directory or if they do not match any Directory Map in the Vault, add the following
parameter:
ExternalObjectsDeletionPolicy
This parameter specifies the deletion policy to use during synchronization with the
External Directory. The optional values for this parameter specify that External users
and groups in the Vault will be deleted under the following conditions:
■ If they do not exist in the External Directory,

■ If they do not match an External Directory map in the Vault.

Specify one of the following acceptable values:
■ DeleteNone – No external objects are deleted during the synchronization
process.
■ DeleteNonExisitng – External objects that were not found in the external
directory will be deleted during the synchronization process.
■ DeleteNonMatched – External objects that do not match an external directory
map in the Vault will be deleted during the synchronization process.
■ DeleteAll – External objects that were not found in the external directory as well
as external objects that do not match an external directory map in the Vault will be
deleted during the synchronization process. This is the default value.
ExternalObjectsDeletionPolicy=DeleteAll
The following table lists several scenarios and the valid value for each one.
DeleteAll DeleteNonExisting DeleteNonMatched DeleteNone
Scenario: External Directory is offline/network is down/configured directory hosts not

reachable/… User doesn't exist in the External Directory / was deleted from directory
Delete Delete Delete Not Deleted

reachable/… There is no matching Directory Mapping for the User
Delete Not Deleted Delete Not Deleted

reachable/… User is disabled in the External Directory
Not Deleted Not Deleted Not Deleted Not Deleted

reachable/…User is expired in the External Directory
Not Deleted Not Deleted Not Deleted Not Deleted

reachable/…User was moved from the directory

reachable/… User was modified in the directory
Sync error Sync error Sync error Sync error

reachable/… Directory set for this User or Group does not exist (e.g. directory ini file was
removed, directory name setting in this file was changed)

reachable/…The mapping directory in the vault was modified

DeleteAll DeleteNonExisting DeleteNonMatched DeleteNone

reachable/… External Directory is offline/network is down/configured directory hosts not
reachable/…
Sync error Sync error Sync error Sync error

Upgrade the MSSP to v9.10

This topic describes how to upgrade your current MSSP environment from v9.9.5 to
v9.10.
Before upgrade
On the PVWA server, in the PasswordVault\MSP folder, backup the MSSP
Web.config. By default, this folder is C:\inetpub\wwwroot\PasswordVault\MSP.
Upgrade
1. On the PVWA server, create a new folder and copy the MSSP Installation zip file
to it, then extract the installation package.
2. Display the contents of the Server folder, then start the installation procedure:
Double-click Setup.exe,
or,
On systems that are UAC-enabled, right-click Setup.exe, then select Run as
Administrator.
3. The installation process begins and the following Setup window appears.
If you have not already closed any open Windows applications, it is strongly
Note:

127 Upgrade the MSSP to v9.10
You can exit installation at any time by clicking Cancel. You can return
to the previous installation window by clicking Back, where
applicable.
4. Click Next to proceed to the next step of the installation, which enables you to
view the CyberArk license and accept the terms of the License Agreement.
5. Read the license agreement, then click Yes to accept its terms and proceed to the
Ready to Install window.
6. Click Install to begin the installation process; the installation process begins and
the Vault's connection details window appears.

7. Specify the name and password of the Vault user who will create the MSSP
environment in the Vault, then click Next; the installation process will now build the
MSSP environment in the Vault and on the PVWA machine.
The following message appears.
Click OK to continue the process.

8. After the MSSP environment has been created, the Setup Complete window
appears.

9. Click Finish to complete installation of the CyberArk Privileged Account Security

Solution for MSSPs.
Following upgrade
After upgrading the MSSP environment in the Vault and on the PVWA machine, replace
the new MSSP Web.config with the old web.config and update it:
1. On the PVWA Server, copy the backed up web.config file to the
PasswordVault\MSP folder, by default
C:\inetpub\wwwroot\PasswordVault\MSP, to replace the file that was placed
there during upgrade.
2. Open the MSSP web.config file, and change the value of
PasswordManagerInstallationPath to CPM\CreateEnvFiles
3. Restart the IIS.

Convert Customer Authentication from LDAP to RADIUS

This topic describes how to convert the existing customer authentication method from
LDAP to RADIUS after upgrade.
1. Run the following REST commands:
a. Login
URL
https://<FullDomainName>/PasswordVault/api/auth/cyberark/logon
Resource Information
HTTP method POST
Content type application/json

Body parameters
{username: "<MSSPAdmin UserName>", password:

"<MSSPAdminPassword>", newPassword: null, type:
"cyberark", secureMode: false}
For more details, refer to the Privileged Account Security Web Services
SDK Implementation Guide.
b. Change from LDAP to Radius:
URL
https://<FullDomainName>/PasswordVault/api/RadiusDetails
HTTP method POST

Body parameters
{
"TenantId": "<Customer UniqueID>",
"Address": "<Radius Server IP>",
"Port": 1812,
"Hostname": "",
"Secret": "<Radius Client Shared Secret>"
}
For more details, refer to Add RADIUS Server, page 239.

2. Login into the PrivateArk Administrator Client as an MSSP Admin User.

a. From Tools, select Administrative Tools and then Directory Mapping…
b. Select the specific map name then click Update.
c. In the New/ Update Directory Map window, click User Template.
d. In the Authentication tab, change the authentication method to RADIUS
Authentication.
e. Click OK.
3. Update the authentication method for the existing LDAP users in the Vault. You
can either delete all existing LDAP users in the customer's location or update the
authentication method of each of the existing LDAP users.
Delete all existing LDAP users from the customer's location
a. In the PrivateArk Administrator Client, select Tools > Administrative
Tools > Users and Groups.
b. In the Users and Groups tree, expand the customer's location.
c. Select the Vault user that corresponds to each LDAP user and click
Delete. Repeat this to delete each user from the Vault.
d. Click Close.
Update the existing LDAP users in the customer's location
a. In the PrivateArk Administrator Client, select Tools > Administrative
Tools > Users and Groups.
b. In the Users and Groups tree, expand the customer's location.
c. Select the Vault user that corresponds to each LDAP user and click
Update; the Update User window appears.
d. In the Authentication tab, change the authentication method to Radius
authentication, then click OK.
e. Repeat these steps for each LDAP user in the location, then click Close.
Enable RADIUS authentication for the customer
a. Log onto the PVWA as an MSPAdmin user.
b. In the ADMINISTRATION page, select Options > Authentication
Methods > Radius, and set Enabled to Yes.
c. Click OK to save this change.

132
Customer Management
This section describes how to install and configure the Customer's environment for
CyberArk's PAS offering for MSSP.
Note:
To create the MSSP environment successfully, Install the CPM before
installing the PSM.
In this section:
System Requirements
Install the CPM for customers
Privileged Session Manager for Customers
Add Customers
The Customer Environment
Log on to the MSSP
Disable Customers
Generate Customer Reports
Ongoing Customer Maintenance
Auditing

System Requirements
This section lists the specifications for the Customer's (tenant) servers used in
CyberArk's PAS offering for MSSP.
A single machine is required for the PSM and CPM Server.
Recommended server specifications

This section summarizes the recommended hardware and software specifications for the
CPM and PSM servers that are installed in the Customer's environment.
CPM and PSM server

The customer environment supports up to 500 managed accounts. The following
specifications are relevant for this size implementation. Installing the server on a virtual
machine requires allocating virtual hardware resources that are equivalent to the physical
hardware specifications.
Software specifications
Windows 2012R2
Internet Explorer 8.0, 9.0, 10.0 and 11.0
.NET Framework 4.5.2
Remote Desktop Services (RDS) Session Host
Note:Make sure you have the required number of RDS CALs to enable you to
access the RDS server. For more information, refer to Connecting to the PSM
server with Microsoft Remote Desktop Services (RDS) Session Host in the
Privileged Account Security Installation Guide
Remote Desktop Gateway (optional)

Before installing the PSM, make sure that the Users group has the Allow Logon
Locally Windows permission in the local security policy. This ensures that the
PSMShadowUsers group created during PSM installation will have the required
permissions. Alternatively, you can set this local security policy permission for the
PSMShadowUsers group directly after PSM installation.
Intel Pentium IV (or compatible) or higher
16GB RAM
25GB free disk space for installation, and additional 20GB space for temporary
workspace
TCP/IP connection to the Digital Vault Server

134 Install the CPM for customers
Server Virtualization
Installing the PSM server on a virtual machine requires allocating virtual hardware
resources that are equivalent to the physical hardware specifications. For details, see
the CyberArk Managed Security Service Provider Solution Implementation Guide
The maximum concurrency is lower (up to 40%) when installing the PSM server on a
virtual machine.
Install the CPM for customers

The Central Policy Manager (CPM) automatically enforces enterprise policy by
managing passwords on remote machines and storing the corresponding passwords in
the Vault, with no human intervention, according to the organizational policy. It enables
organizations to change, verify, and reconcile passwords on remote machines.
This topic describes how to install CPM for customers on your dedicated server for the
PAS offering for MSSP.
Install CPM for customers
1. You will receive the Central Policy Manager installation package from your
Service Provider.
2. Copy the "Central Policy Manager" installation folder to a local folder on the
CPM server.
Note:
Specify a folder name without spaces.
3. In the PVWA, display Accounts > Files, and search for the CPM-
DeployFiles file.
4. From the [Customer_Unique_ID]-Install Safe, download the CPM-

DeployFiles-[Customer_Unique_ID].zip to the local folder on the CPM
server and unzip it to that folder.

5. Run the CPM_SilentInstall batch file.

Display the contents of the local folder , then start the installation procedure:
■ Double-click CPM_SilentInstall
or
■ On systems that are UAC-enabled, right-click CPM_SilentInstall, then
select Run as Administrator.
Note:
By default, the CPM will be installed in C:\Program Files (x86). To install
it in a different folder, open the CMD interface and change the
environment variable of %ProgramFiles(x86)% so that it points to the
required folder(for example: D:\Program Files (x86)). Then run the CPM_
SilentInstall batch file from the CMD, and it will be installed in the new
location.

136 Privileged Session Manager for Customers
Privileged Session Manager for Customers

Privileged Session Manager (PSM) enables organizations to secure, control and monitor
privileged access to network devices by using the Vault technology to manage privileged
accounts and record all IT administrator privileged sessions on remote machines.
In this section:
Considerations installing PSM

The scope of your implementation determines where the PSM server will be installed and
how many PSM servers you require. The following considerations will help you define the
size and the capacity of your implementation.
Planning capacity
The amount of storage in the Vault that is required for storing session recordings must be
planned before installation. The following considerations will help you determine the
amount of Vault storage that you will need.
Consideration Description
Size of session The number of activities performed during each session

recordings and the session type (GUI or Text) determine the size of
each recording. Typically, recordings vary from 50-250
KB/minute
Activity in your enterprise The number of concurrent sessions that the PSM will
create and store in the Vault determine the size of your
implementation.
Recordings Retention The length of time that recordings will be retained

Period according to your enterprise audit policy.
The following sample scenario shows how to calculate the required space in the Vault for
a PSM implementation:
PSM implementation
Consideration Enterprise requirement
requirement
Activity in your enterprise The sample enterprise’s

IT consists of 100
employees who manage
their Windows machines.
Size of session recordings The amount of required The number of daily

recorded IT activities is minutes in session
estimated to be 100 daily recordings – 100 * 10 =
sessions of 10 minutes 1,000 minute
each.
Recordings Retention The enterprise’s audit The number of days to

PSM implementation
Consideration Enterprise requirement
requirement
Period policy requires session retain the recordings – 365

recordings to be kept for 3 * 3 = 1,095.
years.
The estimated required (1,000 * 1,095) * 250

space (kb/min) = ~273GB
Determine the hardware required for PSM

The PSM must be installed on the same machine as the CPM.
Recommended settings for installing PSM on a virtual machine

When installing PSM on a virtual machine, it is recommended to apply the following steps
in order to ensure optimal PSM performance:
In VMware based environments, install VMware Tools on every PSM VM.
Reserve enough VM resources to avoid a potential situation in which the virtual
machine on which PSM is installed does not receive enough resources:
It is recommended to set a fixed amount of processing power reservation (MHz
reservation) on the VM. You can examine the amount of expected processing power
that will be utilized in day-to-day use by the PSM in your environment and reserve
processing power accordingly.
In VMware, you can determine the amount of processing power that is utilized by
installing VMware Tools and examining a PerfMon counter called [VM Processor -
>Effective VM Speed in MHz].
Similarly to processing power reservation, make sure that enough memory is
allocated for the PSM VM machine at any given time.
It is recommended that the latest version of the Virtual Machine is used for the PSM
VM. This will ensure that the most updated virtual hardware available is used.
Windows 2012 R2 currently supports the latest available VMware virtual hardware
and, therefore, is the recommended operating system.
For VMware based environments, version 5.5 and above, make sure hyper-
threading is enabled in the BIOS for processors that support it.
Connect to the PSM server with Microsoft Remote Desktop Services

(RDS) Session Host
Make sure you have the appropriate RDS CAL licensing. PSM can work with any RDS
CAL License scheme (either per user or per device). For more information about
purchasing an RDS CAL, contact your Microsoft representative.

Connect to the PSM Server with Microsoft Remote Desktop Gateway

(Terminal Services Gateway)
PSM can be configured to work with the Microsoft Remote Desktop Gateway
(TSGateway) which tunnels the RDP session between the user and the PSM proxy
machine using HTTPS protocol (port 443), providing a secure connection without
needing to open the firewall. All information that is transferred between the user and the
PSM proxy machine is encrypted and protected by the HTTPS protocol, which enables
secure cross-network and remote access. For more information about Microsoft Remote
Desktop Gateway, refer to http://technet.microsoft.com/en-us/library/cc731264.aspx.
For details about configuring the PSM to work with a Remote Desktop Gateway, see
Secure Remote Access using a Remote Desktop Gateway.
Establish connections through PSM when NLA authentication is

enabled on the PSM Server
When establishing connections through the PSM to target systems, users can either
connect through the PVWA or any RDP client application installed on their desktop.
In environments where NLA authentication is enabled on the PSM server, the system is
configured to enable only one form of connection establishment: PVWA or RDP client
application.
■ To allow users to connect through an RDP client application when NLA
authentication is enabled on the PSM server, no specific configurations are required.
■ To allow users to connect through the PVWA portal, an external tool and additional
configurations are required.
For details, see the Privileged Account Security Implementation Guide .
Establish connections through PSM from a Unix/Linux device

You can access the PSM from a Unix/Linux device in one of the following ways:
Connect through the PVWA portal from a Unix/Linux device using an external tool.
For details, see the section Configuring PSM Connections and EPV RDP
Connections that require an External Tool in the Privileged Account Security
Implementation Guide
Connect from any desktop platform, including Unix/Linux, using a standard RDP client
application.
Supported PSM connection methods

This table describes the PSM connection methods you can use with different PSM
implementations.

Standard RDP
Client from the
External Tool RDP RDP File with
(HOB)
HTML5 users’ desktop
File RemoteApp
(no
RemoteApp)
ü ü
*PSM
Protocol 1
ü ü ü
*PSM
Protocol 1
ü ü ü ü
ü ü ü ü ü
ü ü ü ü ü
ü ü ü
Note:
The PSM Protocol 1 does not support connections using RDP files, the RemoteApp
user experience, or connections directly from the user's desktop.

Pre-installation tasks
This topic describes prerequisites to the PSM installation.
Verify that all installed components and applications are compatible. The compatible
versions of the Privileged Account Security Suite components are listed in the Privileged
Account Security System Requirements document .
Ready the PSM server machine

The following section describes prerequisites for the PSM server machine.
Windows 2008 R2 or Windows 2012 R2
Remote Desktop Services (RDS) Session Host Role
Verify that Windows update KB2999226 is installed.
Verify you have the required number of RDS CALs to enable you to access the RDS
server. For more information, refer to Connect to the PSM server with Microsoft
Remote Desktop Services (RDS) Session Host, page 137.
Windows 2012 R2
RDS setup must include PSM-specific configurations, as described in the following
sections:
To install the PSM in an environment without load balancing, set up RDS as
described in Pre-installation tasks, page 140.
To install PSM in an environment with load balancing, set up RDS as described in the
Privileged Account Security System Installation Guide.
Remote access
To enable secure remote access, install Remote Desktop Gateway (RD Gateway). This
is optional.
Make sure that the Remote Desktop Session Host feature is installed on the PSM
machine.
Note:
For information about Setting up RDS on Windows 2008R2 or Windows 2012R2, refer
to the Microsoft documentation.
To benefit from RemoteApp user experience validate the following:

PSM must be installed on Windows 2012R2
RDP client v6.1.7601 or above (RDP protocol version v7.1 or above) on end user
machines.
Install PSM server on a virtual machine

If you install the PSM server on a virtual machine, make sure you allocate virtual
hardware resources that are equivalent to the PSM's physical hardware specifications.

PSM License
RDS on a PMS server

This procedure describes how to set up RDS on a PSM server on Windows 2012 R2 in
an environment without load balancing.
RDS on a PMS server
1. In the Server Manager, display the Dashboard, then select Add Roles
and Features.
2. In the Add Roles and Features Wizard window, select Installation Type,
then click Next.
3. In the Installation Type window, select Remote Desktop Services
installation, then click Next.
4. In the Deployment type window, select Standard deployment, then click

Next.

5. In the Deployment Scenario window, select Session-based desktop

deployment, then click Next.
6. Select the server where the new roles will be installed:

a. In the Specify RD Connection Broker server window, select the
current server, then click Next.
b. In the Specify RD Web Access server window, select the current
server, then click Next.
c. In the Specify RD Session Host servers window, select the
current server, then click Next.
7. In the Confirm selection window, select Restart the destination server
automatically if required, then click Deploy.

8. After the server has restarted, add a session collection:

a. In the Server Manager, select Remote Desktop Services, then
Collections.
b. Select Tasks, then Create Session Collection, and then click
Next.
c. In the Collection Name window, specify the collection name, then
click Next.
d. In the RD Session Host window, select the current PSM server,
then click Next.
e. In the User Groups window, remove all user groups. Add a group or
a user that you trust to connect to the PSM server via RDP (for
example, the administrator user that you are currently logged on
with), then click Next.
f. In the User Profile Disks window, clear Enable user profile disks,
then click Next.
g. Click Create.
9. Make sure that the current server is the only server associated with your
session collection.
Note:
The RemoteApp feature requires a connection broker and a session collection to
be associated with it. This is required, whether a connection broker is used for
load balancing or not. If these prerequisites are not set up, the PSM installation
will not be able to install the RemoteApp feature. If this happens, you can repair
the installation and add the RemoteApp feature at a later stage, after setting up
the prerequisites.

Install the Privileged Session Manager

This section describes how to install the Privileged Session Manager.
Installation notes
Install the PSM server on a separate machine from the Vault server.
Enable File and Printer Sharing for Microsoft Networks on the server during
PSM installation. This is required to set the PSMInitSession.exe application as a
RemoteApp application. You can disable it again after the installation is complete.
The PSM server is installed as a Windows service called CyberArk Privileged
Session Manager.
Install the PSM for a Managed Service Provider customer

Installation by the MSSP administrator
1. In the MSSP Customer Management Console, add a customer. Select the
PSM service.
2. Log into PVWA as the MSSP Admin user and set the following PSM
configuration :
a. Make sure that Live Monitoring is disabled: Navigate to
ADMINISTRATION > Options > Privileged Session
Management > General Settings > Server Settings > Live
Sessions Monitoring Settings, and set Enable=No.
b. Make sure that Secure Connect is disabled: Navigate to
Management > General Settings > Server Settings > Secure
Connect Settings, and set Enable=No.
c. Configure Privileged Session Management UI: Navigate to
Management UI and check the following settings:
ConnectPSMWithRDPActiveX=Never
UseRemoteApp=No
d. Set the Recording Safe path of the customer's PSM machine:
Navigate to ADMINISTRATION > Options > Privileged Session
Management > General Settings > Recorder Settings, and set
LocalRecordingsFolder=C:\Program Files
(x86)\CyberArk\PSM\Recordings.
3. Click OK to save changes.
4. Install the PSM on the Customer server. For more information, refer to
Installation by the customer administrator, page 145.
5. Update the PSMServer name and IP:

Note:
This section must be performed after the customer has installed PSM.
Log into PVWA as the MSSP Admin user and set the following PSM
configuration:
a. Navigate to ADMINISTRATION > Options > Privileged Session
Management > Configured PSM Servers > PSMServer_
<Customer_ID>, and set Name=PSM Server on <machine
name>.
b. Navigate to ADMINISTRATION > Options > Privileged Session
Management > Configured PSM Servers > PSMServer_
<Customer_ID> > Connection Details > Server, and set
Address=<Machine IP>.
c. Click OK to save changes.
In multiple PVWA environments:
a. Log onto the PrivateArk Administrative Client with the MSSP Admin
user.
b. Add the current MSSP Admin user to the [prefix]-PSMMaster
group.
c. Add the PVWAAppUserX user to the [prefix]-PSM Safe with the
following permissions:
List Files
Retrieve Files
Update Files
d. Add the PVWAAppUser2 user to the [prefix]-PSMSessions Safe
with the following permissions:
Create Files
Installation by the customer administrator
You will receive the PSM installation package from your Service Provider. Install the
Privileged Session Manager for your MSSP customer environment, accepting all the
default settings.
Before beginning installation, logon as a domain user who is a member of the local
administrators group.
Installation by customer adminstrator
1. Create a new folder on the PSM server machine. From the installation CD,
copy the contents of the Privileged Session Manager folder to your new
folder .
Display the contents of the Privileged Session Manager folder.
Double-click Setup.exe or,

On systems that are UAC-enabled, right-click Setup.exe, then select Run

as Administrator.
The PSM installation wizard appears and displays a list of prerequisites that
are installed before the PSM installation continues.
3. Click Install to begin the installation process; the installation process begins
and the Setup window

Note:
You can exit installation at any time by clicking Cancel. You can return to
the previous installation window by clicking Back, where applicable.
Agreement.

information.
Next to proceed to the Destination Location window, which enables you to
select the folder on the PSM server where the PSM will be installed.

7. Click Next to accept the default location provided by the installation.

Click Next to proceed to the Recordings Folder window, which enables you
to select the folder on the PSM server where PSM recordings will be saved
temporarily before they are uploaded to the Vault.
Note:
The Recordings Folder may require a large amount of disk space, depending on
the number of recordings that are stored there before being uploaded into the
Vault.
Take into consideration that, by default, the recordings folder is on the System
disk under Program Files and you may want to change it to a different location.

8. Click Next to accept the default recordings folder provided by the installation.
Click Next to proceed to the Password Vault Web Access Environment
window, which enables you to specify the name of the PVWA Configuration
Safe.
9. Click Next to accept the default name of the PVWA Configuration Safe
provided by the installation.

Click Next; the installation automatically installs the Oracle Instant Client,
then displays the Vault Connection Details window where you specify the
connection details of the Vault server.
10. When prompted to specify the Vault Address, leave it empty and click Next.
The following message will appear:
Click Yes to continue installation.

11. Click Finish to complete the Privileged Session Manager installation.
12. Restart the PSM server. You can also restart the PSM server at a later
stage.

Activate the PSM for the MSSP Customer

Do the following to activate the Privileged Session Manager:
Download the PSM activation files
1. Log into PVWA with the customer admin user, go to Accounts > Files and
search for PSM-DeployFiles.
2. From the [Customer_Unique_ID]-Install Safe, download the PSM-
DeployFiles-[Customer_Unique_ID].zip to a local folder on the PSM
server.
3. Unzip the deployment files in that folder.
Copy files
1. Copy the basic_psm.ini file to C:\Program Files
(x86)\CyberArk\PSM replacing the existing file.
2. Copy the Vault folder content (psmapp.cred, psmgw.cred and Vault.ini) to
C:\Program Files (x86)\CyberArk\PSM\Vault replacing the existing file.
Update PSMConnect and PSMAdminConnect passwords
1. On the PSM machine, open Local users and groups.
2. Right-click on PSMConnect user. Select Set password.
3. Log into PVWA with the customer admin user and display the Accounts
page. Click Search to display all the accounts.
4. Copy the PSMConnect password and paste it into the Set password
window.
5. Right-click on PSMAdminConnect user. Select Set password.
6. In the PVWA, copy the PSMAdminConnect password and paste it in the
Set password window.
Update PSMConnect and PSMAdminConnect passwords objects
1. In the PVWA, update the address and LogonDomain for the PSMConnect
and PSMAdminConnect password objects.
2. Select both password objects. Select Modify > Edit.
3. Set Address to the IP of the PSM machine.
4. Set LogonDomain to the PSM machine name.
Start the service
After you have updated the PSM server IP, manually start the CyberArk
Privileged Session Manager Service:
Go to Start > Administrative Tools > Services and right-click CyberArk
Privileged Session Manager, then select Start.

Post installation tasks

This section describes several procedures that are done after installing the PSM. Some
tasks are mandatory, while others are recommended.
Note:
This step is mandatory.
During installation, a log file called PSMInstall.log is created to monitor the installation
process and to enable you to ensure that the Privileged Session Manager was installed
successfully.
This log file is created in the Temp folder and it contains a list of all the activities
performed when the PSM environment in the Vault is created during the installation
procedure. Other log files that are used for internal purposes are created in the same
folder during installation.
Disable the screen saver for the PSM local users
Note:
During installation, the following two Windows users are created for the PSM
environment on the PSM machine:
User Description
PSMConnect A Windows user that is created in order to start PSM sessions on

the PSM machine.
PSMAdminConnect A Windows user that is created in order to monitor live privileged

sessions.
After the PSM has been installed successfully, the Screen Saver for these users must be
disabled.
Disable the screen saver for the PSM local users
1. Display the Microsoft Management Console (MMC).
2. From the File menu, select Add or Remove Snap-ins; the Add or Remove
Snap-ins window appears.

3. Select Group Policy Object, then click Add; the Select Group Policy Object
window appears.
4. Click Browse; the Browse for a Group Policy Object window appears.

5. In the Users tab, select the PSMConnect user, then click OK; the Select Group
Policy Object window appears
6. Click Finish; the Add or Remove Snap-ins window appears.
7. Select Group Policy Object, then click Add; the Select Group Policy Object
window appears.
9. In the Users tab, select the PSMAdminConnect user, then click OK; the Select
Group Policy Object window appears.
10.Click Finish; the Add or Remove Snap-ins window appears.
11.Click OK; the main MMC window appears and displays the User configurations
for the PSMConnect user.
12.Select the following parameter:
User Configuration\Administrative Templates\Control
Panel\Personalization\Enable Screen Saver

13.Disable the screen saver for the PSMConnect user and the
PSMAdminConnect user.
Configure users for PSM sessions
Note:
This step is performed automatically as part of the installer process and only needs to
be done if you make manual changes.
The PSMConnect and PSMAdminConnect Windows users are created on the PSM
Server machine during PSM installation.
Configure PSMConnect and PSMAdminConnect users for PSM sessions
1. In Windows 2012R2: In the Computer Management console, expand System
Tools.
In Windows 2008R2: In the Server Manager, expand Configuration.
2. Display Local Users and Groups, and then Users; the Users’ details are
displayed.
3. Configure the PSMConnect user:

a. Right-click on the PSMConnect user and select Properties; the

PSMConnect Properties window appears.
b. In the General tab, select Password never expires.
Note:
The PSMConnect password can be managed by the CPM and is changed
periodically.
c. In the Sessions tab, specify the following:

■ In End a disconnected session, specify 1 minute.

■ In Active session limit, specify Never.
Note:
You can configure the maximum PSM session duration in PSM configuration in
the PVWA.
■ Select Disconnect from session, in the section When a session

limit is reached or connection is broken.
■ Select From originating client only, in the section Allow
Reconnection.
d. Click OK to save the new settings.
4. Configure the PSMAdminConnect user:
a. Right-click on the PSMAdminConnect user and select Properties; the
PSMAdminConnect Properties window appears.
b. In the General tab, select Password never expires.
Note:
The PSMAdminConnect password can be managed by the CPM and is changed
periodically.

c. In the Sessions tab, specify the following:
■ In End a disconnected session, specify 1 minute.

■ In Active session limit, specify Never.

Note:
You can configure the maximum PSM session duration in PSM configuration in
the PVWA.
■ In When a session limit is reached or connection is broken, select

Disconnect from session.
■ In Allow reconnection, select From originating client only.
d. Click OK to save the new settings and return to the Server Manager
window.
Connect to a target system directly from desktop

End users that need to connect through PSM to their target systems using an RDP Client
application, must be members of the RemoteDesktopUsers group in the PSM server.
This membership does not allow them to actually log into the hardened PSM server, but
only to connect remotely to it.
Enable maintenance users to logon remotely

Maintenance users who need to logon remotely to the PSM server must be members of
the RemoteDesktopUsers group in the PSM server and must also be added to the list of
users with the “Allow log on through Remote Desktop Services” permission in the
Windows security policy. For more information about updating this setting, refer to the
relevant section:
■ For in-domain installations: in Harden the PSM server machine, page 160, refer to
Post installation tasks, page 153, step 4.
■ For out of domain installations: in Harden the PSM server machine, page 160, refer
to Post installation tasks, page 153, step 5.
Harden the PSM server machine
Note:
The PSM hardening procedure on the PSM server machine enhances PSM security.
The PSM Hardening script is copied to the PSM machine as part of the installation, to the
<PSM installation folder>\Hardening folder. The instructions below describe how to
install it.
Note:
When installing the PSM on AWS, refer to Amazon Web Services (AWS), page 95, before
hardening the PSM server machine.
For details on how to harden the PSM server, see Harden the PSM server, page 162

Configure the PSM users’ passwords

This procedure describes how to configure the PSMConnect and PSMAdminConnect
users’ passwords so that they are managed by the CPM.
Configure the PSM Users’ Passwords
1. Click POLICIES to display the Policies page, then click Access Control
(Safes); a list of Safes is displayed.
2. Assign the PSM Safe to the relevant CPM:
a. In the Safes List, select PSM; the Safe Details page for the PSM Safe
appears.
b. Click Edit; the Edit Safe page for the PSM Safe appears.
c. In Assigned to CPM, select the CPM that will manage the PSM Safe, then
click Save; the PSM Safe will be assigned to the specified CPM.
3. Assign the PSMConnect and PSMAdminConnect users’ accounts to the
WinServerLocal platform. For the first PSM that is installed, by default, this
account is called PSMServer. Accounts for subsequent PSM servers are called
according to the name of the machine where the PSM is installed.
a. In the Accounts List, select the PSMConnect account; the Accounts Details
page for the selected password appears.
b. Click Edit; the Edit Account page appears.
c. In the Policy ID drop-down box, select WinServerLocal.
d. Repeat this step for the PSMAdminConnect account.
Parameter Value
FromHour 2
ToHour 5
Parameter Value
VFFromHour 2
VFToHour 5
4. Click Apply to save the changes and apply them immediately.
(Optional) Configuration in implementations with multiple PVWAs

Where a single PSM server has been installed in implementations that are configured for
multiple PVWAs, enable all the PVWA application users, by default
PVWAAppUser<X>, to access the following Safes as a Safe owner, with the Safe
owner permissions listed for each:
Safe Safe Owner Permissions
PSM ■ List Files/List accounts


Safe Safe Owner Permissions
PSMUnmanagedSession ■ List Files/List accounts

Accounts ■ Create Files/Add accounts
■ Manage Safe Owners/Manage Safe Members
This will enable users to view the PSM Secure Connect
page and connect to any machine through PSM using any
account, including those that are not managed in the
CyberArk Vault. For details, see Connecting with Secure
Connect in the Privileged Account Security Implementation
Guide
PSMLiveSessions ■ List accounts

This will enable users to view the PSM live monitoring
feature in an environment with multiple PVWAs. For details
about live monitoring, see Monitoring Live Sessions in the
PSMSessions ■ Create Files

This will enable PSM connections through the Password
Vault Web Access.
Harden the PSM server

The PSM hardening procedure on the PSM server machine enhances PSM security.
The PSM Hardening script is copied to the PSM machine as part of the installation, to the
<PSM installation folder>\Hardening folder.
Note:
This step is mandatory
The table below summarizes the stages in the hardening procedure and the
tasks involved for each stage. Details for each step are in the following
sections.
Stage Tasks
Run the hardening 1. Enable PowerShell scripts , page 164

script, page 164
2. Modify the PSM hardening script, page 164
You can modify the PSM hardening script to
configure either of the following scenarios:
■ Enabling PSM to connect to Web applications
■ Hardening a PSM cluster
3. Run the PSM Hardening Script, page 165Run the

Stage Tasks
PSM Hardening Script, page 165

4. Review the PSM hardening script output log file,
page 165Harden the PSM server, page 162
After running the 1. Hide PSM local drives in PSM sessions, page 166
hardening script,
It is recommended to hide the PSM local drives to
page 166
prevent end users who connect via the PSM, from
accessing the PSM local drives.
2. Block Internet Explorer developer tools , page 168
3. Block the Internet Explorer context menu , page 168
Set up AppLocker 1. Verification before running the AppLocker script,

rules, page 169 page 169
2. Run the AppLocker script, page 169
3. Return the security level for running PowerShell after
running the AppLocker script, page 170
Automatic 1. Import a GPO file to an 'In Domain' Active Directory

hardening in 'In domain, page 170
Domain'
2. Harden the PSM server, page 162
deployments, page
170 3. Link GPO to a dedicated OU containing CyberArk
servers, page 177
Linking (enabling) the GPO on the servers need to be
done only after the servers are installed and
configured according to installation and
implementation guides, assuming the customer
would like to have a dedicated OU for PSM servers.
Automatic 1. Import an INF file to the local machine, page 178

hardening in 'Out of
2. Apply advanced audit, page 179
Domain'
deployments, page
178
General routine 1. Update your Operating System, page 181

configurations for 'In
2. Install an Anti-Virus solution, page 181
Domain' and 'Out of
Domain' 3. Validate proper server roles, page 181
deployments, page 4. Restrict network protocols, page 181
181
5. Rename default accounts, page 182
Configure the PSM 1. Configure automatically , page 182

server in 'In Domain'
2. Configure manually , page 182
deployments, page
182
Configure 'Out of 1. Automatically configure Out of Domain PSM

Domain' PSM servers, page 184

Stage Tasks
servers, page 184 2. Manually configure Out of Domain PSM servers -

administrative templates, page 184
3. Manually Add User Changes for Installation, page
185
Note:
Configure the PSM Users’ Passwords' When installing the PSM on AWS, refer to the
section on AWS in the Privileged Account Security Installation Guide Amazon Web Services Amazon
Web Services before hardening the PSM server machine.
Run the hardening script

Perform the following procedures to run the hardening script.
Enable PowerShell scripts
This configuration will enable PowerShell scripts to run on the PSM machine.
Enable PowerShell scripts on the PSM machine
1. To check the current PowerShell script execution policy, open the
PowerShell window, then run the command Get-ExecutionPolicy.The
command will return a RemoteSigned status.
Get-ExecutionPolicy
2. If the command does not return the RemoteSigned status, run the following
command to allow local PowerShell scripts to run
Set-ExecutionPolicy RemoteSigned –force
For more information about this command, refer to PowerShell's man page.
Modify the PSM hardening script
Modify the script
1. Remove the read-only permissions from the PSM hardening script file
PSMHardening.ps1.
2. Open the the PSM hardening script using Notepad and proceed with the
following options:
3. To enable the PSM to connect to Web applications change the value of
$SUPPORT_WEB_APPLICATIONS to $true. This does not harden
Internet Explorer.
4. To harden a PSM cluster:
a. In the $PSM_VAULT_FILE_PATH parameter, specify the shared
Vault folder and/or the Vault file that is not under the PSM directory
path.

b. In the $PSM_RECORDING_PATH parameter, specify the shared

recording folder and/or recording directory that is not under the PSM
directory path.
Run the PSM Hardening Script
Run hardening script
1. In a PowerShell window, open the folder PSM installation >\Hardening
folder.
CD “C:\Program Files (x86)\CyberArk\PSM\Hardening”
2. To start the script, run the following command:
./PSMHardening.ps1
Review the PSM hardening script output log file

Review the hardening script
1. Check the log for errors.
2. If the log contains errors, refer to the # Error Codes section in the
hardening script for troubleshooting suggestions. If you cannot solve the
problem, contact your CyberArk support representative.
3. If the PVWA is installed on the same machine, check that the script
recognized and modified the PVWA folders’ permissions.
4. If the script did not recognize the PVWA, or a warning message was written
in the log, modify the permissions manually as follows:
Object User Permission
C:\CyberArk PSMConnect PSMAdminConnect Deny All Access
C:\InetPub PSMConnect PSMAdminConnect Deny All Access
5. Return the security level for running PowerShell scripts to the same status as
it was before you ran the script. For example, to set the execution policy to
Restricted, run the following command:
Set-ExecutionPolicy restricted
For more information about this command, refer to PowerShell's man page.

After running the hardening script

Perform the following procedures to after running the hardening script.
Hide PSM local drives in PSM sessions
1. Open the Microsoft Management Console (MMC).
2. From the File menu, select Add or Remove Snap-ins; the Add or Remove
Snap-ins window appears.
3. From the Available snap-ins area, select Group Policy Object Editor, and
then click Add. The Select Group Policy Object window appears.

5. Click the Users tab, then select the group Non-Administrators, and then
click OK; the Select Group Policy Object window appears.
6. Click Finish; the Add or Remove Snap-ins window reappears.
7. Click OK to close this window; the main MMC window reappears and shows
the User configurations for the Non-Administrators group.

8. Navigate to User Configuration\Administrative Templates\Windows

Components, then:
■ For Windows Server 2012: select File Explorer, then in the Settings
pane, double-click Hide these specified drives in My Computer, and
then select the Enabled radio button.
■ For Windows Server 2008: select Windows Explorer, then in the
Settings pane, double-click Hide these specified drives in My
Computer, and then select the Enabled radio button.
Block Internet Explorer developer tools
This procedure blocks Internet Explorer development tools when connecting to web sites
through the PSM.
Internet Explorer developer tools are blocked in the PSM in order to prevent end users
who connect via the PSM from accessing it.
Block Internet Explorer development tools
1. From Start, run the following executable: gpedit.msc; the Local Group Policy
Editor window appears.
2. In Computer Configuration, select Administrative Templates; a list of
available templates is displayed.
3. In the list of templates, double-click Windows Components, and then
double-click Internet Explorer; a list of settings is displayed.
4. Double-click Toolbars.
5. Double-click Turn off Developer Tools, then in the settings window, select
Enabled.
6. Click OK.
Block the Internet Explorer context menu
This procedure blocks Internet Explorer context menus when connecting to web sites
through PSM.
The Internet Explorer context menu in the PSM is blocked in order to prevent end users
from adding the developer tools.

Block Internet Explorer context menus

1. From Start, run the following executable: regedit.exe; the Registry Editor
window appears.
2. Display the contents of the following key: HKEY_LOCAL_MACHINE \
SOFTWARE \ Policies \ Microsoft \ Internet Explorer \ Restrictions.
3. Change the value of the DWORD NoBrowserContextMenu to 1.
Set up AppLocker rules

To create a hardened and secure PSM environment, the system must limit the
applications that can be launched during a PSM session. To do this, the PSM uses the
Windows AppLocker feature, which defines a set of rules that allow or deny applications
from running on the PSM machine, based on unique file identities. These rules specify
which users or groups can run those applications.
The PSM installation includes an AppLocker script which enables PSM users to invoke
internal PSM applications, mandatory Windows applications, and 3rd party external
applications that are used as clients in the PSM.
All AppLocker rules are defined in the PSMConfigureAppLocker.xml file in the PSM
installation folder > Hardening. If your environment includes executables that must be
allowed, in addition to those that are built-in to the PSM installation, such as PSM
Universal Connectors executables, you must edit this file to add rules that will allow these
executables.
Verification before running the AppLocker script
1. Make sure that the organizational GPO AppLocker policy is not enabled on
the PSM machine.
2. Configure the PSM machine to allow PowerShell scripts to run:
a. Open a PowerShell window, then run the Get-ExecutionPolicy
command to check the current PowerShell script execution policy, as
shown in the following example.
b. The command will return the RemoteSigned status.
Get-ExecutionPolicy
c. If the above command doe not return the RemoteSigned status, run
the Set-ExecutionPolicy command to allow local PowerShell scripts
to run, as shown in the following example:
Set-ExecutionPolicy RemoteSigned –force
For more information about this command, refer to the PowerShell man page.
Run the AppLocker script
1. In the PSM installation folder, remove the read-only permissions from the
PSMConfigureAppLocker.xml file.
2. Open the PSMConfigureAppLocker.xml configuration file and edit the

PSM AppLocker configuration manually.

a. Make sure that the paths specified in the file specify the PSM
installation folder path.
b. If your environment includes executables that must be allowed, in
addition to those that are built-in the PSM installation, such as PSM
Universal Connectors executables, add a rule for each executable
to allow it on the PSM sesrver.
3. Run the Automatic PSM AppLocker Configuration Script to set the
AppLocker and ensure that PSM users can only run approved applications.
This script enables PSM users to invoke internal PSM applications and
mandatory Windows applications. The PowerShell script that configures the
AppLocker Rules is called PSMConfigureAppLocker.ps1. This
PSMConfigureAppLocker.ps1 script file is located in the folder PSM
installation > Hardening
Open a PowerShell window, then use the following commands to start
the script:
CD “C:\Program Files (x86)\CyberArk\PSM\Hardening”

./PSMConfigureAppLocker.ps1
Return the security level for running PowerShell after running the AppLocker
script
After running the AppLocker script, you can return the security level for running
PowerShell scripts to the same status as it was before you ran the AppLocker script.
For example, to set the execution policy to restricted, run the following command:
Set-ExecutionPolicy restricted
For more information, refer to PowerShell's main page.
Automatic hardening in 'In Domain' deployments

This section describes the automatic hardening procedure for In Domain deployments,
including each file type and its configuration, as well as the procedures for applying and
editing these files in a customer's environment.
Note:
This step is relevant for PSM servers installed on Windows 2012 R2
Import a GPO file to an 'In Domain' Active Directory domain

1. Open the Group Policy Management Console (GPMC.msc) on your
domain.
2. Expand Group Policy Management, then the <yourDomain> forest, and
then Domains.

3. Expand <yourDomain>, then right-click Group Policy Objects and select

New.The New GPO window appears.
4. In the Name field, specify the name of the new GPO (for example,
CyberArk PSM Hardening), then click OK.
5. In the Group Policy Objects, right-click the newly created GPO then select
Import Settings….

The Import Settings Wizard appears.
6. In the Welcome to the Import Settings Wizard window, click Next. The
Backup GPO window appears.

You do not have to configure backup as this GPO is new.

7. Click Next. The Backup location screen appears.
8. Click Browse, and select the location of the folder where the hardening
settings are stored. For example, CyberArk PSM Hardening - GPO
Settings on the CD Image.
Note:
Be sure to unzip the folder where the hardening settings are stored.
9. Then click Next. The Source GPO window appears.

10. Select the Hardening GPO, for example, PSM Hardening GPO, then click
Next. The Scanning Backup window appears.
11. Click Next. The Completing the Import Settings Wizard window appears.

12. Click Finish. The Import window appears and shows the progress of the
GPO import.
13. When the GPO import process is complete, click OK.

Add applicable accounts to the GPO object.
1. In the Group Policy Management Console, under Group Policy Objects,
right-click the newly created GPO and click Edit.

2. Navigate to the folder: Computer Configuration > Policies > Windows

Settings > Security Settings > Local Policies > User Rights
Assignments.
3. Double click Allow log on locally and in the Add User or Group window,
add the PSMShadowUsers group.
4. Double click Allow log on through Remote Desktop Services.

a. Add the PSMConnect and PSMAdminConnect users as shown in the
left screenshot below.
b. If the PSMConnect and PSMAdminConnect users are domain
users, add a <Domain> prefix, as shown in the left screenshot below.

To ensure that unauthorized users will not gain access to the PSM server, make
sure that this setting is only allowed for PSMConnect and PSMAdminConnect
users and for maintenance users who are required to log on remotely to the
PSM server.
Link GPO to a dedicated OU containing CyberArk servers
1. Make sure all Servers are located under a dedicated OU, so the GPO will
not affect any other server.
2. In the Group Policy Management Console, right-click the OU, then select
Link an Existing GPO.
3. Select the relevant GPO, for example, PSM Hardening, then click OK.

Automatic hardening in 'Out of Domain' deployments

This section describes how to apply automatic hardening procedures in 'Out of Domain'
deployments.
Note:
This step is relevant for PSM servers installed on Windows 2012 R2
Import an INF file to the local machine

1. Copy the relevant INF hardening file to the local machine (CyberArk
component).
2. In a command line, run gpedit.msc.

3. Display Computer Configuration, then display Windows Settings.

4. Right-click Security Settings, and Import Policy.
5. Browse to the folder where the INF hardening file is located, for example,
CyberArk PSM Hardening, and open it.
Apply advanced audit

1. Copy the relevant Advanced Audit.csv file to the local machine (CyberArk
component).

3. Display Computer Configuration, then display Windows Settings, and

expand Security Settings.
4. Expand Advanced Audit Policy Configuration, then right-click System
Audit Policies – Local Group Policy Object, and select Import
Settings.
5. Browse to the folder where the Advanced Audit.csv is saved, and open it.

General routine configurations for 'In Domain' and 'Out of Domain'

deployments
This section describes configuration that must be performed in 'In Domain' deployments
as well as in 'Out of Domain' deployments.
Update your Operating System
Microsoft releases periodic updates (security updates and service packs) to address
security issues that were discovered in Operating Systems. Make sure your Operating
System is updated to the latest version.
You can install the updates in either of the following ways:
Manually install updates and service packs.
Automatically install with Server Update Services (WSUS), which is located on a
corporate network.
Install an Anti-Virus solution
In today’s world, the pace of virus development is very fast. Servers without anti-virus
protection are exposed to two risks:
Server infected with viruses that might damage the server and the entire network.
Trojan horses that are planted to allow remote control of the server and to all the
information on it.
Install an Anti-Virus solution and update it as needed.
Validate proper server roles
Server roles can be set using the Server Manager. Ensure that the unnecessary roles
are not installed on the server
Restrict network protocols
Install only the required protocols and remove unnecessary ones.
For example, only TCP/IP are necessary, and ensure that no additional protocols such
as IPX or NetBEUI are allowed.

Rename default accounts

It is recommended to change the names of both the Administrator and the guest to
names that will not testify about their permissions.
It is also recommended to create a new locked and unprivileged Administrator user name
as bait.
Configure the PSM server in 'In Domain' deployments

This section describes how to configure the PSM Server in 'In Domain' deployments.
Configure automatically
1. Install the PSM hardening GPO as described in Harden the PSM server,
page 162. The GPO should be imported during the installation process.
2. You will receive the hardening package from CyberArk as a zipped file.
Unzip this file so that you can import the hardening GPO.
Configure manually
1. If smart cards are not used with the PSM server(s), use the following to
disable this feature:
Note:
Customer's discretion is required!
Policy Setting
Services
Vulnerability: Unnecessary services are expose the server to vulnerabilities and
increasing the attack surface
Smart Card Disabled
Smart Card Removal Policy Disabled
a. To Harden via a Group Policy Object (GPO),

Create a new group policy object (Services): Computer Configuration →
Policies → Windows Settings → Security Settings → System Services
Policy Setting
Services
Vulnerability: Unnecessary services expose the server to vulnerabilities
and increase the attack surface
Do not allow smart card device Enabled

redirection
b. To Harden via a Group Policy Object (GPO), do the following:

Policies → Administrative Templates → Windows Components → Remote
Desktop Services → Remote Desktop Session Host → Device and
Resource Redirection

2. To Enable the Firewall, do the following:
Note:Customer's discretion is required!
Assuming all required network rules for proper PSM functioning are known
(user machines, target machines and other servers and services), it is
recommended to enable the Windows firewall.
Policy Setting
Services
Vulnerability: Unnecessary services expose the server to vulnerabilities and increase
the attack surface.
Windows Firewall Enabled
a. To Harden via a Group Policy Object (GPO):

Policies → Windows Settings → Security Settings → System Services
3. To Disable Terminal Services Redirection, do the following:
Note:
Customer's discretion is required!
If Clipboard/Drive/Printer redirection are not being used, disable them.

Policy Setting
Terminal Service Hardening

Vulnerability: Clipboard mapping enables the client to transfer a virus or a
malicious application to the server as well as copy configuration or sensitive data
from the server back to the client machine. There is a risk of infecting to the whole
network or damaging the system.
Do not allow Clipboard redirection Enabled
Do not allow drive redirection Enabled
Do not allow printer redirection Enabled
a. To Harden via a Group Policy Object (GPO)

Policies → Administrative Templates → Windows Components → Remote
Desktop Services → Remote Desktop Session Host → Device and
Resource Redirection

Configure 'Out of Domain' PSM servers

Use the following procedures to configure PSM Servers in ‘Out of Domain’ deployments.
Automatically configure Out of Domain PSM servers
1. Install the PSM hardening INF and CSV files as described in Harden the
PSM server, page 162.
2. You will receive the hardening package from CyberArk as a zipped file.
Unzip this file so that you can import the hardening INF and CSV files.
Manually configure Out of Domain PSM servers - administrative templates
To manually configure the Terminal Services, do the following:
Policy Setting
Services
Administrative Templates → Windows components → Remote Desktop Services →

Remote Desktop Session Host → Connections
Automatic reconnection Disabled
Configure keep-alive connection Enabled

interval Keep-Alive interval:1
Deny logoff of an administrator Enabled

logged in to the console session
Set rules for remote control of Enabled

Remote Desktop Services user Full Control without user's permission
sessions
Do not allow LPT port redirection Enabled
Do not allow supported Plug and Enabled

Play device redirection

Remote Desktop Session Host → Remote Session Environment
Remove "Disconnect" option from Enabled

Shut Down dialog
Remove Windows Security item Enabled

from Start menu

Remote Desktop Session Host → Security
Do not allow local administrators to Not Defined

customize permissions
Require secure RPC Enabled

communication
Set client connection encryption Enabled

level Encryption Level: High Level

Policy Setting

Remote Desktop Session Host → Session Time Limits
End session when time limits are Enabled

reached
Set time limit for active but idle Not Defined

Remote Desktop Services
sessions
Set time limit for disconnected Enabled

sessions Set to one minute

Remote Desktop Session Host → Temporary folders
Do not delete temp folders upon exit Disabled
Do not use temporary folders per Disabled

session
Customer's discretion is required when changing the following policies!
Policy Setting
Services
Remote Desktop Session Host → Device and Resource Redirection
Do not allow Clipboard ■ If this feature is used: Not defined

redirection ■ If this feature is not used: Enabled
Do not allow COM port ■ If this feature is used: Not defined

Do not allow drive ■ If this feature is used: Not defined

Manually Add User Changes for Installation

1. At a command line, run gpedit.msc.


2. Expand Local Policies, then select User Rights Assignment.
3. Add the PSMShadowUsers group to the Allow log on locally list.

4. Add the PSMConnect / PSMAdminConnect users to the Allow log on
through Remote Desktop Services list. To ensure that unauthorized
users will not gain access to the PSM server, this setting must only be
allowed for the PSMConnect and PSMAdminConnect users, and for
maintenance users who are required to logon remotely to the PSM server.
You will have to redefine this setting after each PSM server upgrade. Make
sure that the effective policy, including configurations made at domain level,
defines this setting as described above.
Move PSMConnect and PSMAdminConnect Users to your Domain

(Optional)
During PSM installation, the PSMConnect and PSMAdminConnect users are created
on the PSM server machine and given specific user properties.

If necessary, after installing the PSM successfully, you can manually rename these
users. For example, in a Load Balancing environment when there is a need to use
domain users instead of the local PSM users, you can change the PSM users and define
the domain users.
Note:
To allow live session monitoring in an environment with load balanced PSMs and an RD
connection broker, the PSMAdminConnect user must be a local user.

Create the PSMConnect and PSMAdminConnect users

Create PSMConnect and PSMAdminConnect in your domain
1. In the domain, create two users that will be used instead of the local
PSMConnect and PSMAdminConnect users.
Note:
To support older Windows clients and servers, the User logon name (pre-
Windows 2000) setting must contain fewer than 20 characters
2. Make sure that the new domain users both belong to the built-in group called
Remote Desktop Users. This enables them to log onto the PSM machine.
3. Make sure thathe PSM server machine belongs to the domain where the
new users are listed.
Configure the domain users

To configure the domain users do the following:
Set user properties for PSMConnect user, page 188
Set user properties for PSMAdminConnect user, page 192
Set user properties for PSMConnect user
Set user properties for the PSMConnect Domain User
1. On the domain controller, display the Properties window for the
PSMConnect domain user.
2. In the Environment tab, do the following:
a. Select Start the following program at logon:.

b. In Program file name, specify the full path of the PSMInitSession.exe.
The default full path is:
C:\Program Files
(x86)\CyberArk\PSM\Components\PSMInitSession.exe
c. In Start in, specify the folder where the PSMInitSession.exe will be

run. The default folder is:
C:\Program Files (x86)\CyberArk\PSM\Components
d. Make sure that all the Client devices checkboxes are clear.

3. In the Remote Control tab, do the following:
a. Select Enable remote control.

b. Clear Require user’s permission.
c. In the Level of Control options, select an option to determine
whether or not other users will be able to monitor or control the
PSMConnect domain user’s sessions:
View the user's session – Enables live monitoring of PSM sessions.
Interact with the session – Enables live monitoring and taking over
PSM sessions.
4. In the Account tab, to Limit the PSMConnect domain user to log in to PSM
servers only:
a. Click Log On To.

The Logon Workstations window appears.

b. Select The following computers, then click Add, to add the PSM
machine.
c. Click OK.

5. In the Account tab options, select the following:
User cannot change password
Note:
IMPORTANT!: Customers managing PSMConnect and
PSMAdminConnect user credentials with CPM must make
sure that a reconcile account is associated with the user
account in order for password rotation to succeed. For
details, see Post installation tasks, page 153.
Password never expires

6. In the Sessions tab, specify the following:
In End a disconnected session, specify 1 minute.

In Active session limit, specify Never.
Note:
You can configure the maximum PSM session duration in PSM
configuration in the PVWANote
Select Disconnect from session, in the area When a session limit is

reached or connection is broken.
Select From originating client only, in the area Allow
Reconnection.
Set user properties for PSMAdminConnect user
Set user properties the PSMAdminConnect Domain User
1. On the domain controller, display the Properties window for the
PSMAdminConnect domain user.
2. In the Environment tab, set the following properties:

a. Select Start the following program at logon:.

b. In Program file name, specify the full path of the
PSMInitSession.exe. The default full path is:
C:\Program Files
(x86)\CyberArk\PSM\Components\PSMInitSession.exe
c. In Start in, specify the folder where the PSMInitSession.exe will be

run. The default folder is:
C:\Program Files (x86)\CyberArk\PSM\Components
d. Make sure that all the Client devices checkboxes are clear.
3. In the Remote Control tab, do the following:

a. Select Enable remote control.

b. Clear Require user’s permission.
c. In the Level of Control options, select an option to determine whether or
not other users will be able to monitor or control the PSMConnect domain
user’s sessions:
View the user's session – Enables live monitoring of PSM sessions.
Interact with the session – Enables live monitoring and taking over PSM
sessions.
4. In the Account tab, to limit the PSMConnect domain user to log in to PSM
servers only:
a. Click Log On To.

The Logon Workstations window appears.

b. Select The following computers, then click Add, to add the
PSM machine.
c. Click OK.
5. In the Account tab options, select the following:

■ User cannot change password

IMPORTANT!
Customers managing PSMConnect and PSMAdminConnect user
credentials with CPM must make sure that a reconcile account is
associated with the user account in order for password rotation to
succeed. For more information, refer to Post installation tasks, page 153.
■ Password never expires

a. In the Sessions tab, specify the following:
In End a disconnected session, specify 1 minute.

In Active session limit, specify Never.
Note:
You can configure the maximum PSM session duration in
PSM configuration in the PVWA
Select Disconnect from session, in the area When a session

limit is reached or connection is broken.
Select From originating client only, in the area
Allow Reconnection.
Configure the Remote Desktop Session on the PSM

The following procedure configures the PSMAdminConnect domain user so that it can
monitor or control the PSMConnect domain user.
Configure on Windows 2008 R2, page 198, see directly below
Move PSMConnect and PSMAdminConnect Users to your Domain (Optional), page
186

Configure on Windows 2008 R2

As the PSM server v8.5 can be installed on Windows 2012 R2, which no longer includes
the RDS Host Configuration tool, configure the remote desktop session (RDS) on the
PSM in either of the following ways:
■ Configure the RDS Host Configuration Tool for Windows 2012R2 Server using a
2008 Server, page 198
■ Configure the RDS Directly on a Windows 2012R2 Server, page 199
Configure the RDS Host Configuration Tool for Windows 2012R2 Server using
a 2008 Server
1. Use the tsconfig.msc tool to connect to the PSM server:
a. Log onto a Windows 2008 server using a Domain administrator.
b. From a command line, run tsconfig.msc.
c. Right-click RD Session Host Configuration then, from the pop-up
menu, select Connect to Remote Desktop Session Host Server
The Select Computer window appears.
d. Select Another computer, then specify the hostname or IP of the

PSM server, then click OK.
2. Continue with step 3 in Configure on Windows 2008 R2, page 198.

Configure the RDS Directly on a Windows 2012R2 Server

1. Configure the RDS from a command line, using the wmic tool to connect to
the PSM server:
2. Add the DOMAIN\PSMAdminConnect object to the PermissionsSetting
in the RDP-Tcp options, using the following command:
wmic.exe /namespace:\\root\CIMV2\TerminalServices PATH

Win32_TSPermissionsSetting WHERE (TerminalName="RDP-
Tcp") CALL AddAccount "DOMAINNAME\PSMAdminConnect",0
3. Add the Remote Control permission for the PSMAdminConnect user,

using the following command:
wmic.exe /namespace:\\root\cimv2\TerminalServices PATH

Win32_TSAccount WHERE "TerminalName='RDP-Tcp' AND
AccountName=' DOMAINNAME\\PSMAdminConnect'" CALL
ModifyPermissions TRUE,4
4. Restart the Remote Desktop Services Service for the change to take effect.
Do this in one of the following ways:
■ Run the following commands:
a. Net stop termservice
b. Net start termservice
Or
■ Restart the PSM server machine.
Rename the PSM users

The following procedure describes how to rename the PSM users in the PSM server to
domain users with the same names.
Rename the PSM users to domain users
1. Stop the PSM server.
2. In the PVWA, display the Accounts list.
3. On the Search toolbar, click Go to begin a search for all the accounts that you
have access to. Leave the search field empty to search for all managed
accounts.
4. In each PSMConnect and PSMAdminConnect account, change the
following properties:
LogonDomain – Specify the name of the new domain.
UserName – Specify the new username of the PSM user.

3. Click Save to save the new account properties.

4. Set the password of the PSMConnect domain user’s account in the Vault.
5. Delete the PSMConnect and/or PSMAdminConnect users on the PSM
server as they are no longer needed.
6. Restart the PSM.
Allow PSMConnect and PSMAdminConnect domain users to logon

remotely to the PSM server
Allow remote logon to the PSM server

3. Expand Local Policies, then select User Rights Assignment.

4. Add the PSMConnect and PSMAdminConnect users to the Allow log on

through Terminal Services list.
Configure the PSM hardening script
1. Remove the read-only permissions from the PSMHardening.ps1 file.
2. Using Notepad, open the PSM hardening script. By default, it is stored in the
following location:
C:\Program Files
(x86)\CyberArk\PSM\Hardening\PSMHardening.ps1
3. Change the value of the $PSM_CONNECT_USER variable from

"$COMPUTER\PSMConnect" to the new domain user name, using the
following pattern: "<domain name>\<domain username-psmconnect>". For
example, if the new domain user is called PSMConnectDomain, specify
"Domain.com\PSMConnectDomain".
4. Change the value of the $PSM_ADMIN_CONNECT_USER variable from
"$COMPUTER\PSMAdminConnect" to the new domain user name, using
the following pattern: "<domain name>\<domain username-
psmadminconnect>". For example, if the new domain user is called
PSMAdminConnectDomain, specify
"Domain.com\PSMAdminConnectDomain".
5. In a PowerShell window, open the PSM_INSTALLATION\Hardening
folder and run the PSM hardening script, using following command:
./PSMHardening.ps1.
Configure permissions for the PSMConnect domain user in the PSM

server
Configure permissions for the PSM server

1. Make sure the PSMConnect domain user has access to the shared
recording folder, by default PSM\Recordings, with the following special
permission:
Create files/write data
2. Make sure that access is allowed for this folder only and does not include
subfolders and files.
3. Make sure the PSMConnect domain user is denied all other access rights to
the shared recording folder, its subfolders and files. This should have been
set by the PSM Hardening Script.
4. Make sure the PSMConnect domain user has access to the components log
folder, by default PSM\Logs\Components, with the following special
permission:
Create files/write data
5. Make sure that access is allowed for this folder only and does not include
subfolders and files.
Configure the PSM AppLocker script

Configure the PSM AppLocker script
1. Using Notepad, open the PSM AppLocker script. By default, it is stored in the
following location:
C:\Program Files
(x86)\CyberArk\PSM\Hardening\PSMConfigureAppLocker.ps1
2. Change the value of the $PSM_CONNECT variable from "PSMConnect" to
the new domain user name, using the following pattern: "<domain
name>\<domain username-psmconnect>". For example, if the new domain
user is called PSMConnectDomain, specify
"Domain.com\PSMConnectDomain", as shown below.
$PSM_CONNECT = "Domain.com\DomainPSMConnect"
3. Change the value of the $PSM_ADMIN_CONNECT variable from

"PSMAdminConnect" to the new domain user name, using the following
pattern: "<domain name>\<domain username-psmadminconnect>". For
example, if the new domain user is called PSMAdminConnectDomain,
specify "Domain.com\PSMAdminConnectDomain", as shown below.
$PSM_ADMIN_CONNECT = "Domain.com\DomainPSMAdmin"
4. In a PowerShell window, open the PSM_INSTALLATION\Hardening

folder and run the PSM AppLocker script, using following command:
./PSMConfigureAppLocker.ps1

Harden the PSMConnect and PSMAdminConnect domain users

The following procedure describes the recommended security configurations that limit
domain users and enhance their security level.
Harden domain users
1. Best practice: Deny the PSMConnect and PSMAdminConnect domain
users from reading and listing all the descendant Active Directory objects.
a. In the Active Directory, display the Active Directory Users and
Computers window.
b. Right-click the domain to which the PSM users belong and select
Properties; the Properties window appears.
c. In the Security tab, click Advanced.The Advanced Security Settings
window appears
d. Add the PSMConnect and PSMAdminConnect domain users, then

click Permission Entry; the Permission Entry window appears.
Permission Entry
e. Add the PSMConnect and PSMAdminConnect domain users, then
click Permission Entry; the Permission Entry window appears.
f. From the Apply to drop-down list, select All descendant
objects.Deny the following permissions:List contentsRead all
properties
g. Click OK.

As a result of the above procedure, user group policies cannot be applied for
these users. If you still choose to deny these permissions for the PSMConnect
and PSMAdminConnect domain users, deny them permission to list contents
and read all properties on every Active Directory OU apart from
CN=System/CN=Policies (which can be accessed through the ADSI Edit tool).
2. Enable the PSMConnect and PSMAdminConnect domain users to log on to
the PSM machine only. For details, see Configure the domain users, page
188.
3. Recommendation: In a group platform that is applied on every machine in
the domain except the PSM server, add a Deny rule that prevents the
PSMConnect / PSMAdminConnect domain users from logging in to domain
machines. These users will only be able to log onto the PSM server.

Privileged Session Manager Environment
The Environment on the Privileged Session Manager Server

During installation, all the files that are required by the PSM on the machine where it is
installed are copied to folders and subfolders that are created especially for this
environment.
Privileged Session Manager Application
By default, the main Privileged Session Manager folder, ‘PSM’, is created under
C:\Program Files (x86)\CyberArk. However, this location can be changed during
installation. The following diagram shows the folder structure of the ‘PSM’ folder after
The PSM folder contains the following files:

■ Basic_psm.ini – The basic PSM configuration file that contains the information
required to start working with PSM. For more information about the configuration
parameters in this file, refer to Privileged Session Manager Parameter File.
■ CAPSM.exe – The PSM service executable.
■ Internal files – This folder contains additional files that are required for internal PSM
use.
It also contains the following subfolders:

■ Components – This folder contains a configuration file and all the executable files
required to run the PSM.
■ Hardening – This folder contains the files that are required for the AppLocker
configureation script.
■ Logs – This folder contains the PSM activity log files. For more information about the
PSM log files, refer to PSM Activity Logs in the Privileged Account Security
Implementation Guide. During installation, the service user is given write permissions
for this folder and the PSMShadowUsers group is given create and write
permissions.
■ Recordings – This folder stores the session recordings temporarily until they are
uploaded to the Vault. During installation, the service user and the
PSMShadowUsers group are given write permissions for this folder.
This folder has the following subfolder:
■ Errors – This folder contains recording and other files that were stored in the
Recordings folder, but which could not be recovered and uploaded to the Vault.
Reasons for this can include the following:
■ Abnormal termination of the PSM, such as when a process was terminated
externally.
■ Faulty configuration leading to issues such as UAC pop-ups or a screensaver
lock.
■ Technical issues, such as insufficient disk space.
■ Other unexpected errors.
■ The files in the Errors folder cannot be played. They can be sent to CyberArk
for recovery.
■ Temp – This folder contains files that are used by the PSM for internal processing.
■ Vault – This folder contains the Vault parameter file which specifies which Password
Vault will be accessed by the PSM. To update Vault parameters after installation,
open the Vault.ini file in this folder and specify the changes. For more information,
refer to Vault Parameter File, page 278
This folder also contains the CreateCredFile utility that is used to create the user
credentials file that enables the PSM user to log onto the Password Vault. This utility
is used automatically by the installation, and should not be used in normal installation
scenarios. For more information about the CreateCredFile utility, refer to Appendix
A: Creating Credential Files.
Privileged Session Manager User
During installation, the following user is created in the PSM environment:
■ PSMConnect – A Windows user created in order to create the PSM environment on
the PSM machine.
■ PSMAdminConnect – A Windows user created in order to monitor live privileged
sessions.
Privileged Session Manager Group
During installation, the following group is created in the PSM environment:
■ PSMShadowUsers - An internal group that contains local PSM users. The PSM
creates a local PSM user called "PSM-<user-id>" for each Vault user who connects

to the PSM, and automatically adds these local users as members to this internal
group.
Add Customers
The MSSP Customer Management Console enables MSSP administrators to create
and manage customers, and provide secure IT services to customers. All MSSP
administrators have access to all customer locations where they can perform
administrative tasks.
The main MSSP console page displays the customers that have already been created
and gives you the option to add new customers. Only MSSP administrators have access
to this page where they can view all customers.
Each customer is displayed on its own card, with the customer logo and the services that
the customer has subscribed to. You can also view the customer's report directly from
this card. For more information, refer to Generate Customer Reports, page 221
MSSP administrators can add new customers (tenants) to the system, and begin
providing them with secure IT services. Customer users can either be added from the
CyberArk Digital Vault or from an Active Directory.
Add customer users from an Active Directory
The CyberArk Digital Vault must be configured to integrate with the Customer’s
Active Directory so that users can be managed through LDAP mapping. Only users
who are listed in the Active Directory can be added. The default ports for MSSP
integration with MicrosoftAD are:
■ 636 - For a secure LDAP connection (default)
■ 389 - For a non-secure LDAP connection

208 Add Customers
Add customers manually

The MSSP administrator requires the following:
■ All permissions at Vault level
■ All permissions at Safe level in the customer's Safes
Note:
After the Safes have been created, change users' permissions
according to the tasks that they perform.
■ Membership in the following groups:

■ Vault Admins
■ PVWAMonitor
■ MSP Admins
When a customer is added in the MSSP Customer Management Console, a unique ID is
assigned to the customer. This ID is used to identify the customer throughout the system,
in Safes and security groups. During the process, a set of Safes is automatically created
to store different account types (Local Windows accounts, Unix account, etc.). The
system combines the name of the customer with the name of the Safe to produce a
unique Safe name. For example, a Safe for Customer A whose unique ID is ComA
would be ComA-Windows-Local.
In addition, the following user groups are added as owners of the customer Safes with
the following permissions:
User group Permissions
Customer This user is added with full permissions in all Safes except the
administrator group Manage Safe permission.
Note:
The customer administrator will not be able to edit
the Safe name, see other customers' CPMs and
provide OLAC permissions.
Customer auditor This user is added with the following permissions:

group
■ List accounts
■ View audit log
A customer IT user is not automatically added as an owner to any Safe. The customer
administrator adds the IT user to each Safe individually, according to their business role.

Before Creating Customers

Add customers using the default LDAPS connection
Before adding customers using the default LDAPS connection, make sure that
LDAPS is configured in the customer's Active Directory.
Note:
For security reasons, it is highly recommended not to use a self-signed
1. Configure LDAP over SSL connections:

On the Vault machine, import the CA Certificate that signed the certificate used
by the External Directory into the Windows certificate store to facilitate an SSL
connection between the Vault and the External Directory (recommended).
Note: For security reasons, it is highly recommended not to use a self-signed
a. Display the Microsoft Management Console.
b. From the File menu, select Add/Remove Snap-in; the Add/Remove
Snap-in window appears.
c. Click Add; the Add Standalone Snap-in window appears.
d. Select Certificates, then click Add; the Certificates snap-in window
appears.
e. Select Computer Account, then click Next; the Select Computer window
appears.
f. Select Local Computer, then click Finish; the Add Standalone Snap-in
window appears.
g. Click Close; the Add/Remove Snap-in window appears and displays
Certificates (Local Computer).
h. Click OK; the main Console window appears.
i. Expand Certificates (Local Computer), then expand Trusted Root
Certification Authorities; the Certificates folder appears.
j. Select Certificates, then from the Action menu, select All Tasks, then
Import …; the Certificates Import Wizard appears.
k. Click Next; the File to Import window appears.
l. Select the certificate file to import, then click Next; the Certificate Store
window appears.
m. Select Place all certificates in the following store, then click Next; the
Completing the Certificate Import Wizard window appears and displays the
details of the selected certificate.
n. Click Finish; the selected certificate is imported to the computer account
and can now be used to authenticate external users to the CyberArk Vault.
Note: By default the Vault automatically sets the Distinguished Name of external
users. If the external user has a certificate in the external directory, the
Distinguished Name will be taken from the certificate. If not, the user DN in
the directory will be set.

210 Add Customers
To specify a user’s DN manually in the PrivateArk Client, in the relevant

Directory.ini file specify the following parameter:
UseLDAPCertificatesOnly=no
o. In the %WINDOWS%\System32\Drivers\Etc\hosts file, define the DNS of
the LDAP host, in order to prevent the firewall from blocking it.
Note: If the firewall is configured to allow DNS traffic, this step is not required.
Create a customer
The MSSP admin user can create customers in the MSSP Customer Management
Console. The default console is: https://<host
name>/PasswordVault/v10/logon.
Note:
This URL is case-sensitive. Make sure you specify it exactly as it appears above.
Create a customer in the MSSP console

1. Log onto the MSSP Customer Management console as an
MSSP administrator.
2. Click Add Customer; the New Customer page appears.
3. Specify the following details:

Details Description
General details
Company The name of the customer's company.

This field is required.
Logo The company logo as a jpg file up to 12K
Contact The name of the customer administrator.

name
Contact The email address of the customer administrator.

email
Customer A unique ID for the customer, which will be added as a prefix to

Details Description
unique ID all customer’s Safes. Specify 1-5 alphanumeric characters that

will uniquely identify this company in the system.
This field is required.
Services
Services The CyberArk service that will be provided to the customer.

Possible options are:
■ EPV (selected by default)
■ PSM
■ EPM
Provision Whether or not the system will search the customer's Active
LDAP users Directory for the user to add.
automatically If this option is enabled, the following connection details are
displayed.
LDAP connection details
Note:
Specify these detailsexactlyas they appear in the organizational Active
Directory.
Address The FQDN or IP address of the customer’s domain.
Domain The name of the customer's domain.
Bind user The user that will be used to connect to the customer's Active
Directory. It is recommend to create a new read-only user,
specifically for this binding.
Bind The password that will be used to authenticate the customer's

password LDAP connection user.
Base context The full distinguished name of the domain from where the
LDAP mapping will retrieve the object’s information. For
example, for the ou "people" in company.com domain:
ou=people,dc=company,dc=com
Use secure Whether or not an SSL connection will be used to connect to

connection the customer's Active Directory. By default, this option is
selected.
Note:
Make sure that the secure connection certificate is
installed before adding the customer.
AD groups mapping

212 Add Customers
Details Description
Note:
Specify these detailsexactlyas they appear in the organizational Active
Directory.
Customer The customer's admin users group in the Active Directory. Use
admins the Distinguished Name format.
Customer The customer's auditor group in the Active Directory. Use the
auditors Distinguished Name format.
Authentication Method
CyberArk Users will authenticate to the system using their CyberArk

password. This option only appears when Provision LDAP
users automatically is not activated.
LDAP Users will authenticate to the system through LDAP. This

option only appears when Provision LDAP users
automatically is activated.
RADIUS Users will authenticate to the system through RADIUS.
RADIUS authentication (UDP protocol)
IP address IP address of the RADIUS server
Port Port of the RADIUS server
Host name Host name of the RADIUS client (Vault machine). This name
(optional) must be identical to the name you entered for the RADIUS
client/agent.
Secret Password secret
4. Click Add Customer; the customer's secure location is created in the Vault.
You can easily identify this location as its name includes the customer's unique
ID. This same ID is also used to create the customer's Safes.
5. Add additional users, such as IT users, to the customer's Safes, giving those
users only the permissions required to perform their tasks. For more
information, refer to Adding and Managing Safe Owners in the Privileged
6. If Provision LDAP users automatically is not selected, in the PrivateArk
Client, create the customer admin user with following settings:
Setting Value
User name <name>@CompanyName
User type EPV user
Location The customer's unique ID
Authentication Password
method Select User Must Change Password at Next Logon

Setting Value
Group membership Add the user as a member of the customer's admin

group.
View customer details

After adding customers to the MSSP, users who belong to the MSP admins group can
view their details in the MSP Console.
View customer details
■ Click the customer logo; the Customer Details page appears and displays all the
information that was specified when the customer was created.

214 The Customer Environment
The Customer Environment

When a customer is added in the MSSP Customer Management Console, a default
environment is created for them that includes Safes and platforms.
Safes
The following Safes are created for each user. The customer's unique ID is added as a
prefix to each Safe name.
[Customer ID]-Windows-local-prod
[Customer ID]-Windows-local-test
[Customer ID]-Domain-admin-prod
[Customer ID]-Domain-admin-test
[Customer ID]-Unix-admin-prod
[Customer ID]-Unix-admin-test
[Customer ID]-Unix-root-prod
[Customer ID]-Unix-root-test
[Customer ID]-Network-devices-prod
[Customer ID]-Network-devices-test
[Customer ID]-Databases-prod
[Customer ID]-Database-test
[Customer ID]-Marketing
[Customer ID]-Finance
[Customer ID]-Cloud-prod
[Customer ID]-Cloud-test
[Customer ID]-Hypervisor-prod
[Customer ID]-Hypervisor-test
[Customer ID]-General-prod
[Customer ID]-General-test
The MSSP administrator can create additional Safes manually. For more information,
refer to Adding and Managing Safes in the Privileged Account Security Implementation
Guide.
Platforms
During the MSSP installation, a predefined set of platforms is created. Accounts
associated with these platforms may be managed automatically by the CPM that is
dedicated for the specific customer environment.
The MSSP administrator can change the platform settings and tailor them to customers'
requirements. All changes in platforms affect all customers.
The following common configurations will affect all platforms in the MSSP environment:
■ Password length will be set to 16 characters.

■ All platforms will be configured to support PSM connections. In addition, the PSM
server will be configured to support the PSM server of the specific customer
(PSMServer_{CustomerID}) and the recordings will be saved in the customer
specific safe ({CustomerID}-PSMRecording).
Note: The PSM's Live Monitoring functionality is not supported in this version.
For more information about configuring the Master Policy and platforms, refer to the
The following platforms are created automatically for customers when they are created in
the MSSP Customer Management Console:
For accounts that do not require CPM management:
■ Windows Server Local Accounts no auto change
■ Windows Desktop Local Accounts no auto change
■ Windows Domain Account no auto change
■ Unix via SSH no auto change
■ Unix via SSH Keys no auto change
■ Oracle Database no auto change
■ Microsoft SQL Server no auto change
■ Microsoft Azure Management no auto change
■ Cisco Router via SSH no auto change
■ Amazon Web Services - AWS no auto change
■ Amazon Web Services - AWS Access keys no auto change
For accounts whose password needs to be changed every 30 days without any
special workflow:
■ Windows Server Local Accounts 30 days change
■ Windows Desktop Local Accounts 30 days change
■ Windows Domain Account 30 days change
■ Unix via SSH 30 days change
■ Unix via SSH Keys 30 days change
■ Oracle Database 30 days change
■ Microsoft SQL Server 30 days change
■ Microsoft Azure Management 30 days change
■ Cisco Router via SSH 30 days change
■ Amazon Web Services - AWS 30 days change
For accounts whose password needs to be changed every 30 days and the
reason must be specified when the account is accessed:
■ Windows Server Local Accounts 30 days change and specify access reason
■ Windows Desktop Local Accounts 30 days change and specify access reason
■ Windows Domain Account 30 days change and specify access reason
■ Unix via SSH 30 days change and specify access reason
■ Unix via SSH Keys 30 days change and specify access reason
■ Oracle Database 30 days change and specify access reason
■ Microsoft SQL Server 30 days change and specify access reason
■ Microsoft Azure Management 30 days change and specify access reason

216 The Customer Environment
■ Cisco Router via SSH 30 days change and specify access reason
■ Amazon Web Services - AWS 30 days change and specify access reason
For accounts whose password needs to be changed every 30 days and dual
control is required to access accounts:
■ Windows Server Local Accounts 30 days change and dual control
■ Windows Desktop Local Accounts 30 days change and dual control
■ Windows Domain Account 30 days change and dual control
■ Unix via SSH 30 days change and dual control
■ Unix via SSH Keys 30 days change and dual control
■ Oracle Database 30 days change and dual control
■ Microsoft SQL Server 30 days change and dual control
■ Microsoft Azure Management 30 days change and dual control
■ Cisco Router via SSH 30 days change and dual control
■ Amazon Web Services - AWS 30 days change and dual control
Note: When dual control is activated, the customer administrator has permission to confirm
other customer users' requests.
The customer will be able to manage accounts and connect to the target devices through
the Privileged Session Manager.
Password Upload Utility

The Password Upload utility uploads multiple password objects to the Privileged Account
Security solution, making the Vault implementation process quicker and more automatic.
This utility works by uploading passwords and their properties by bulk into the Vault from
a pre-prepared file, creating the required environment, when necessary. It is run from a
command line whenever a password upload is required.
During installation, this utility is copied to the MSP/Utilities folder. For information about
running this utility and onboarding accounts, refer to Onboarding Accounts, page 242.

Log on to the MSSP

As the MSSP administrator, you can log onto the Customer Management Console to
manage customers and track their activities. In addition, you can navigate to the PVWA
without having to authenticate again and change system configuration, providing Vault
administration services to customers quickly.
Log on to the MSSP
1. Log onto the MSSP Console as the MSSP admin.
2. In the top right corner, click Configuration to display the PVWA.
The default landing page in the PVWA will be displayed. For more
information, refer to the Privileged Account Security Implementation Guide.
3. To return to the MSSP Console and display the Customers List, in the top
right corner, click Customer management.

218 Disable Customers
Disable Customers
MSSP administrators can disable existing customers (tenants) and prevent them from
benefiting from the MSSP. When the customer is disabled, all the customer's users are
disabled too and the customer cannot access their environment. The customer card still
appears in the MSSP console, but it is disabled and no activities can be performed for
them.
Note: After a customer has been disabled, it cannot be enabled again.
To Disable Customers
1. In the MSSP console, move the cursor over the card of the customer to disable; the
Disable customer drop-down option appears.
2. Click Disable customer; the following message appears:

3. Click Disable to disable the customer,

or,
Click Cancel to return to the MSSP console with no changes.
Extracting Content for Customers

After a customer has been disabled and cannot access their accounts through the
MSSP, the MSSP admin can enable customers to extract account details from the Vault.
The CyberArk Extraction utility extracts accounts that contain either passwords or
SSH keys.
This utility is installed as part of the MSSP package and is in the MSP/Utilities folder.
To Export Accounts
For the MSSP admin:
1. Log onto the MSSP console as the MSSP admin and disable the customer.
2. Create a CyberArk user:
a. Log onto the PrivateArk Administrative Client as an MSSP admin user.
b. In the Tools menu, select Administrative tools and then Users and Groups.
c. Select the Location of the disabled customer, then click New user, and specify
the following user details:
■ Name - The name of the customer user who will run the extract utility.
■ Type - The type of CyberArk user. Specify EPV.
■ Password - The password that this user will use to authenticate to the Vault.
d. Clear User must change password at next logon.

220 Disable Customers
e. Add the user to the disabled Customer admins group.

3. Copy the Extraction.zip package from the MSP/Utilities folder, and share it with the
customer admin.
For the Customer admin:
1. On the customer's CPM server, do the following:
a. Create a folder called C:\ExtractAccountData and copy Extraction.zip to it.
b. Extract the contents of the Extraction.zip package to the C:\ExtractAccountData
folder (not a sub-folder). The name of the utility executable is extract.exe.
c. Use the CreateCredFile utility to create a credential file called user.ini for the
CyberArk user who is a member of the customer's admin group, created in step 2
by the MSSP admin. Make sure the credential file is created in the same folder as
the extract.exe utility.
i. In the C:\ ExtractAccountData folder, open the CMD line and run the
following command:
CreateCredFile.exe user.ini
ii. At the relevant prompts, specify the name and password of the user who will
run the extraction utility.
iii. At all subsequent prompts, press Enter, as none of these field are required.
For more information about the CreateCredFile utility, see Creating Credential Files
in the Privileged Account Security Installation Guide.
2. Copy the Vault.ini file from C:\Program Files(x86)\CyberArk\Password
Manager\Vault (default folder) to C:\ ExtractAccountData.
3. In C:\ ExtractAccountData, open the CMD line and run the following command:
extract.exe -m {customer_unique_identifier} -e {customer_unique_
identifier}PasswordMgr
Specify the customer unique identifier as provided by MSSP admin.

The utility will generate a list of accounts stored in the customer's Safes.
4. When the script has finished running, a csv file called 'Output.csv' will be created in
the folder where the utility is, and the details of all the customer's accounts will be
listed in it.
Another file called Files.csv will be created in the same folder, and will list all the files
that were found in the Safes. To receive the files listed in Files.csv, contact the
MSSP admin who will send them to you.
For the MSSP admin:
1. After the customer has finished exporting their accounts, disable the customer user
that was created to run the export utility.
a. Log onto the PrivateArk Administrative Client as an MSSP admin user.
b. In the Tools menu, select Administrative tools and then Users and Groups.
c. Select the Location of the disabled customer.
d. Select the user who ran the export utility, then click Update; the Update User
window appears.
e. Select Disable user, then click OK.

Generate Customer Reports

MSSP administrators can view a customer inventory report in Excel for each customer.
This enables them to view all the privileged accounts that are stored in the system and
run the billing process based on the number of accounts. This inventory report is
scheduled to run every night for each customer. By default, the name of the report
comprises the unique ID of the customer and the name of the report. For example, the
inventory report that is generated each night for a customer called Company A, whose
unique ID is ComA, is called ComA-Privileged Accounts Inventory.
To View a Customer's Inventory Report

In the Customer List, find the customer whose report you want to view and click
Download Report; the most recently generated report will be downloaded.
The following example shows a generated report:

222 Ongoing Customer Maintenance
Ongoing Customer Maintenance

Add New Safes for Customers
The MSSP administrator can manually create Safes, in addition to those that are created
automatically when a Customer is created.
To Add Safes
In the PVWA:
1. Log onto the PVWA as a user with the Add Safes permission.
2. In POLICIES, click Access Control (Safes) to display a list of existing Safes.
3. Click Add Safe.
4. Specify the name of the Safe and a description, if required. To allocate the safe to the
customer, add the Customer's unique ID as a prefix to the Safe name.
5. Set additional Safe settings as described in Adding Safes in the PVWA in the
6. Click Save. The Safe will be created in the Vault. By default, this Safe is created in
the top level of the Vault Locations hierarchy. Move it manually to the Customer's
Location.
In the PrivateArk Administrative Client:
1. Log onto the PrivateArk Client as a user with the Add/Update Users permission.
2. Find the customer’s Safe, then press SHIFT+Enter to open it. Right-click and select
Properties.
3. In the General tab, click Browse and select the customer's Location.
4. Click OK to close the Safe.
Add New Platforms for Customer Workflows

The MSSP administrator can create unique platforms for customers to meet their specific
segregation needs and workflows.
To Create a Platform in the PVWA

1. Logon to the PVWA as the MSSP admin user.
2. In ADMINISTRATION, click Platform Management to display a list of existing
platforms.
3. Duplicate an existing platform that is similar to the one you want to create. For more
information, refer to the Privileged Account Security Implementation Guide.
4. Change the platform settings so that it defines the exact settings for the customer.
5. Expand Automatic Password Management , and select General.

6. In the AllowedSafe property, specify the Customer's unique ID and the exact name
of the Safe where this platform will be applied, or a wildcard, as shown in the
following examples:
■ CustomerA-Finances
■ CustomerA*
Note: By default, the value of the AllowedSafe parameter is .*, which means that all
customers can use this platform. This step describes how to restrict the platform to a
specific customer only.
Auditing
Each time a new customer is added or disabled, the MSSP creates an audit record.
MSSP administrators can then see who managed customers and check that they were
created or disabled successfully in the Activities Log report. This is a log of all the
activities that have taken place in the Safe(s). This report can be filtered according to
user, target system, specified period, and a variety of other criteria.
Users who have the following authorizations can generate this report:
■ User related activities – Audit Users in the Vault
Note: Users can generate this report for users in the same level or lower in the Vault
hierarchy.
and
■ Safe/Account related activities – View Audit in Safes that will be included in the
report
To View MSSP activities in the Activities Log
1. Click REPORTS to display the My Reports page.
2. Click Generate Report; the Report wizard appears.
3. Select the report to generate, then click Next; the Filter Options page appears.

224 Auditing
This page enables you to specify filters for the report. Select Managed Service
Provider Admin User Activities.
4. Click Next; the Schedule Report page appears.
This page enables you to schedule reports for automatic and manual generation, and
specify which users can access them.
5. In the Report Recurrences section, specify the filters that determine how frequently
this report will be generated.
6. In the Subscribers section, add the users who will be able to access the generated
report. The name of the user who is currently defining the report is already listed in
the Subscribers list.
7. Select Notify me if errors occur to send a notification to the user generating the
report if an error occurs and it cannot be generated.
8. Click Finish; the report is now generated and is displayed in the Generated Reports
tab in the My Reports page.

Reports only contain the information that the user who generated the report is
authorized to access. Any other information will not be included in the report,
regardless of the specified properties in the Reports parameters.
This report includes the following output:
Details Description
Action The activity that was audited. Optional values are:

■ Create customer Succeeded
■ Create customer Failed
■ Disable customer Succeeded
■ Disable customer Failed
User The name of the administrator who created/disabled the customer.
Reason Details about how the customer was created/disabled:

■ Status: Whether or not the customer was created/disabled. Values are
success or failure.
■ Customer: The location of the customer in the MSSP's Vault hierarchy.
■ Reason: If the customer could not be created/disabled, this explains why.
Time The date and time when the customer was created/disabled.
Alert Whether or not the customer creation/disable failed. Optional values are:
■ Yes - The customer creation/disable failed.
■ No - The customer was created/disabled successfully.
For more information about generating reports, refer to the Privileged Account Security

226
MSSP REST API
In this section:
Add Customer
Disable Customer
List Customers
Get Customer Details
Add RADIUS Server

Add Customer
This method adds a customer to the MSSP environment.
The user who runs this web service requires the following permission in the Vault:
■ Manage users
URL
Note:
Make sure there are no spaces in the URL.
https://<IIS_Server_Ip>/PasswordVault/msp/api/customers
HTTP method POST
Header parameter
Parameter Authorization
Type String
Description The token that identifies the session, encoded in BASE 64.
Valid values A session token that was returned from the “Logon” method.
Body parameters
{
"Name":"<customer name>",
"UniqueID":"<ID>",
"ContactName":"<name>",
"ContactEmail":"<email>",
"Logo":"[image-encoded-as-base64]",
"SupportedServices":["<service>","<service>"],
"AuthenticationType":"<Type>",
"LdapDetails":
{
"Address":"<IP>",
"DomainName":"<domain>",

228 Add Customer
"ConnectionUser":"<user>",
"ConnectionPass":"<password>",
"Port":"<port>",
"BaseContext":"<base context>CN=<cn>,DC=<dc>,DC=<dc>",
"AdminsGroupDN":"<group name>",
"AuditorsGroupDN":"<group name>"
"UseSecureConnection":"<false/true>"
}
"RadiusDetails":
{
"Address":"<IP>",
"Hostname":"<name>",
"Port":"<port>",
"Secret":"<secret>"
}
}
Parameter Name (mandatory)
Type String
Description Name of the customer (tenant) to add.

■ The following characters aren’t allowed: \/:*<>".|
Valid values -
Parameter UniqueID (mandatory)
Type String
Description A unique ID that will identify the customer in the system.
Valid values 1-5 characters
Parameter ContactName
Type String
Description The customer's contact person for MSSP (customer admin).
Valid values -
Parameter ContactEmail
Type String
Description The email of the customer's contact person for MSSP (customer admin).
Valid values -
Parameter Logo
Type String
Description Customer logo jpg file encoded as Base64.
Valid values -

Parameter SupportedServices
Type StringArray
Description The services supported by the MSSP for this customer (EPV, PSM, EPM).
Valid values EPV, PSM, EPM
Default EPV
Parameter AuthenticationType (mandatory)
Type String
Description The authentication that will be used by the customer to authenticate to the
PVWA.
Valid values CyberArk, LDAP, RADIUS
LdapDetails
Parameter Address (mandatory if AuthenticationType is set to LDAP)
Type String
Description The address of the customer's organizational Active Directory.
Valid values -
Parameter DomainName (mandatory if AuthenticationType is set to LDAP)
Type String
Description The name of the customer's domain in the Active Directory.
Valid values -
Parameter ConnectionUser (mandatory if AuthenticationType is set to LDAP)
Type String
Description The user that will be used to connect to the customer's Active Directory.
Valid values It is recommend to create a new read-only user, specifically for this binding.
Parameter ConnectionPass (mandatory if AuthenticationType is set to LDAP)
Type String
Description The password that will be used to authenticate the customer's LDAP
connection user.
Valid values -
Parameter Port
Type Integer
Description AD port
Valid values 1-5 numeric characters
Default If useSecureConnection=false, the default is 389

If useSecureConnection=true, the default is 636

230 Add Customer
Parameter BaseContext (mandatory if AuthenticationType is set to LDAP)
Type String
Description The full path to the directory from where the LDAP mapping will retrieve the
object's information. For example, for the "people" ou in the company.com
domain: ou=people, dc=ad, dc=com, dc=company
Valid values Specify these details exactly as they appear in the organizational Active
Directory.
Parameter AdminsGroupDN (mandatory if AuthenticationType is set to LDAP)
Type String
Description The customer's admin users group in the Active Directory. Use the
Distinguished Name format.
Directory.
Parameter AuditorsGroupDN (mandatory if AuthenticationType is set to LDAP)
Type String
Description The customer's auditor group in the Active Directory. Use the
Distinguished Name format.
Directory.
Parameter useSecureConnection
Type boolean
Description Whether or not a secure connection will be used.
Valid values true/false
Default true
radiusDetails
Parameter address (mandatory if AuthenticationType is set to RADIUS)
Type String
Description IP address of the customer's RADIUS server.
Valid values IP address
Parameter hostname
Type String
Description Host name of the RADIUS client (Vault machine). This name must be
identical to the name you entered for the RADIUS client/agent.
Valid values Valid hostname
Parameter port (mandatory if AuthenticationType is set to RADIUS)
Type Integer

Description Port of the RADIUS server.
Valid values Valid port
Parameter secret (mandatory if AuthenticationType is set to RADIUS)
Type String
Description RADIUS password secret.
Valid values RADIUS secret

232 Disable Customer
Disable Customer
This method disables a specific customer in the MSSP environment.
■ Manage users
URL
Note:
The following characters are not supported in URL values: + & %
https://<IIS_Server_Ip>/PasswordVault/msp/api/customers/
{CustomerUniqueID}/disable
The following mandatory value is required in the URL:

Parameter CustomerUniqueID
Type String
Description The customer's unique ID in the MSSP.
HTTP method POST
Header parameter
Type String
Body parameters
{
}

Result
{
}
List Customers
This method returns a list of the customers in the MSSP environment.
■ Audit users
URL
Note:
https://<IIS_Server_Ip>/PasswordVault/msp/api/Customers?offset=
{number of results to skip}&limit={number of results to take}

Parameter offset
Type String
Description The number of customers to skip.
Parameter limit
Type String
Description The maximum number of customers to list.
HTTP method GET
Header parameter
Type String

234 List Customers
Result
{
[
{
"Name":"<customer>",
"UniqueID":"<ID>",
"Status":"<status>"
},
{
"Name":"<customer>,
"UniqueID":"<ID>",
"Status":"<status>"
},
...
]
}
Parameter Name
Type String
Description Name of the customer (tenant).
Parameter UniqueID
Type String
Description A unique ID that identifies the customer.
Parameter Logo
Type String

This file size is limited to 12KB.
Type StringArray
Description The services supported by the MSSP for the customer.
Valid values EPV, PSM, EPM
Parameter Status

Type StringArray
Description The current state of the customer.
Valid values Enabled, Disabled, Deleted

236 Get Customer Details
Get Customer Details

This method returns information about a specific customer in the MSSP environment.
The user who runs this web service must belong to the following group in the Vault:
MSP admins
URL
Note:
https://<IIS_Server_Ip>/PasswordVault/msp/api/customers/{CustomerUniqueID}

Parameter CustomerUniqueID
Type String
Description The customer's unique ID in the MSSP.
HTTP method GET
Header parameter
Type String
Description The token that identifies the session, encoded in BASE 64. .
Result
{
"Name":"<customer>",
"UniqueID":"<ID>",
"ContactName":"<name>",

"ContactEmail":"<email>",
"Status":"<status>",
"LdapDetails":
{
"Address":"<IP>",
"DomainName":"<domain>",
"ConnectionUser":"CN=<cn>,CN=<cn>,DC=<dc>,DC=<dc>",
"Port":"<port>",
"BaseContext":"CN=<cn>,DC=<dc>,DC=<dc>",
"AdminsGroupDN":"CN=<cn>,CN=<cn>,DC=<dc>,DC=<dc>",
"AuditorsGroupDN":"CN=<cn>,CN=<cn>,DC=<dc>,DC=<dc>"
}
}
Parameter Name
Type String
Description Name of the customer (tenant)
Parameter UniqueID
Type String
Description A unique ID that identifies the customer.
Parameter ContactName
Type String
Description The customer's contact person for MSSP (customer admin).
Parameter ContactEmail
Type String
Description The email of the customer's contact person for MSSP (customer admin).
Parameter Logo
Type String
Type StringArray
Description The services supported by the MSSP for this customer.
LdapDetails
Parameter Address
Type String

238 Get Customer Details
Description The address of the customer's organizational Active Directory.
Parameter DomainName
Type String
Description The name of the customer's domain in the Active Directory.
Parameter ConnectionUser
Type String
Description The user that is used to connect to the customer's Active Directory.
This is a read-only user, specifically for this binding.
Parameter ConnectionPass
Type String
Description The password that is used to authenticate the customer's LDAP connection
user.
Parameter Port
Type Integer
Description AD port
Parameter BaseContext
Type String
Description The full path to the directory from where the LDAP mapping retrieves the
object's information. For example, for the "people" ou in the company.com
domain: ou=people, dc=ad, dc=com, dc=company
Parameter AdminsGroupDN
Type String
Description The customer's admin users group in the Active Directory in Distinguished
Name format.
Parameter AuditorsGroupDN
Type String
Description The customer's auditor group in the Active Directory in Distinguished Name
format.
Return Codes
Status code 404
Description The specified customer wasn't found

Add RADIUS Server

This method adds a RADIUS server to the MSP environment for an existing tenant.
URL
Note:
https://<IIS_Server_Ip>/PasswordVault/api/RadiusDetails
HTTP method POST
Header parameter
Type String
Body parameters
{
"TenantId": "<tenant>",
"Address":"<x.x.x.x>",
"Port":"<port>",
"Hostname":"<hostname>",
"Secret":"<secret>"
}
Parameter TenantID (mandatory)
Type String
Description Uniquely identifies the customer in the system
Valid values 1-5 alphanumeric characters

240 Add RADIUS Server
Parameter Address (mandatory)
Type String
Description The address of the customer's RADIUS server.
Valid values IPv4 or IPv6 (IPv6 should be supported only when Vault will support IPv6)
Parameter Port (mandatory)
Type Integer
Description The RADIUS server port
Valid values 1-5 numeric characters between 1 and 65535.
Parameter Hostname
Type String
Description The RADIUS server hostname
Valid values Up to 255 characters
Parameter Secret (mandatory)
Type String
Description The RADIUS secret
Valid values Up to 255 characters
Return Codes
Status code 400
Description The IP format is not valid

241
Customer End User Guide
Customers can perform the following activities in the PVWA:

■ Logging On - Log on to the PVWA using your user name in the following format:
name@company. For example, Scott@company.com.
■ Upload accounts - Use the Password Upload Utility to upload accounts in bulk. This
utility is installed as part of the MSSP package and is in the MSP/Utilities folder. For
more information, refer to the Privileged Account Security Implementation Guide.
■ Account Activities - Use, Manage and Connect with onboarded accounts to
access your target devices.
■ Add owners to Safes - Control access to target devices using Safe owners.
■ Allow 3rd party vendors to use privileged accounts to connect to target machines:
a. Add the 3rd party user in your organization's Active Directory.
b. Add this user as an owner of the Safe where the privileged account that they
need to use is stored, with the following permission:
■ Use accounts - Enables users connect through PSM without viewing
passwords
■ Retrieve accounts - Enables users to copy passwords to target machines.
c. Send a direct link to the privileged account to the 3rd party user.
For a description of account activities, Safe owners and permissions, and connections
through PSM, refer to the Privileged Account Security Implementation Guide.

Onboarding Accounts
The Password Upload utility uploads multiple password objects to the Password Vault,
making the Vault implementation process quicker and more automatic. This utility works
by uploading passwords and their properties into the Password Vault from a pre-
prepared file, creating the required environment, when necessary. It is run from a
command line whenever a password upload is required.
For details about creating the Vault environment and the password file to upload, refer to
Password Upload Utility, page 269.
To Onboard Accounts
The Password Upload utility is copied to the MSP/Utilities folder during installation.
Perform all the steps in the following procedure in this folder.
1. Open config.ini and remove the following keys:
DefaultTemplateSafe=Default Template
GWAccounts=PVWAGWUser
2. Open the Vault parameter file and specify the parameters of the Vault into which the
password objects will be uploaded. For more information, refer to Vault Parameter
File, page 278.
3. To run the utility automatically, so that you do not have to supply the user name and
password, create a user authentication file for the user who will run the utility. Create
the credential file in the MSP/Utilities folder with the Password Upload utility.
a. Open the CMD line and run the following command:
CreateCredFile.exe user.ini
b. At the relevant prompts, specify the name and password of the user who will run
the extraction utility.
For more information about the CreateCredFile utility, refer to Creating Credential
Files in the Privileged Account Security Installation Guide.
4. Open the password file and specify the password objects and their properties to
upload to the Vault, then save the file in Comma Separated Values (CSV) format.
For more information, refer to Creating the Password File in the Privileged Account
Security Implementation Guide.
5. Open the configuration file and specify the parameters that will enable the utility to
upload the password file to the Vault.
■ Specifically, make sure you set CPMUserAdminRights=yes.
For more information, refer to Configuring the Password Upload Utility.
6. At a command line prompt, run the Password Upload utility.
PasswordUpload Conf.ini
For more information, refer to Running the Password Upload Utility in the Privileged

243 Safe Members
Safe Members
Users who have access to Safes are called Safe members. Each Safe member is given
permissions in the Safe that enable them to perform tasks on accounts and files in the
Safe. These permissions are given to each Safe member individually and give you
flexibility to grant different permissions to different Users. Each Safe member can be
given a unique set of permissions that is explicitly for their tasks and is not relevant for any
other Safe member.
Permissions for Safe members
Permission Enables the Safe Member to …
Access - Access accounts in the Safe, including the following tasks:
Use Accounts Use accounts in the Safe. Users who have this authorization
can do the following:
■ Log onto a remote machine transparently through a PSM
connection from the Accounts List by clicking the Connect
with account icon.
■ Log onto a remote machine transparently through a PSM
connection from the Account Details page or from the
Versions tab by clicking the Connect button.
Note:
To log onto remote machines transparently through
a non-PSM connection, users require the ‘Retrieve
accounts authorization as well.
Retrieve Retrieve and view accounts in the Safe. Users who have this
accounts authorization can do the following:
■ View the password in the Account Details page and the
Versions tab by clicking the Show button in the password
content panel. If the platform attached to the account
doesn’t permit users to view the password, the user
requires the ‘Manage Safe’ authorization.
■ Copy the password in the Account Details page by clicking
the Copy button. If the platform attached to the account
doesn’t permit users to view the password, the user
requires the ‘Manage Safe’ authorization.
■ Display the password in the Accounts list by clicking the
Show/Copy password icons. If the platform attached to
the account doesn’t permit users to view the password, the
user requires the ‘Manage Safe’ authorization.
■ Log onto a remote machine transparently through the
PVWA. Platforms can be configured not to display the
password value to end users, but only allow the transparent
connection.

■ Save files by clicking the Save As button in the Files List,

File Details and File Versions pages.
■ Open files that are stored in the Password Vault through the
Files List, File Details and File Versions pages.
List accounts View Account lists. Users who have this authorization can do
the following:
■ View the Accounts or Files list.
Account Management - Perform account management tasks, including the following

tasks:
Add accounts Add accounts in the Safe.

Users who are given this authorization in PVWA automatically
receive Update password properties as well.
■ Add accounts in the Accounts List and Account Details
page by clicking Add Account.
■ Manage account groups and platforms in the CPM tab of the
Account Details page by clicking Add New or Change.
Update Change password values as well as the contents of files. Users

password value who have this authorization can do the following:
■ Change password values manually in the Account Details
page by clicking the Change button.
■ Undelete accounts in the Account Details page of the
deleted account by clicking the Undelete button. This is
only relevant during the file retention period.
■ Manage account copies that are linked to accounts and are
stored in the same Safe by clicking Add or Edit in the
account usage tab.
■ Upload files to the Password Vault by clicking the Upload
button in the Files Details page.
Update Update existing account properties. This does not include

password adding new accounts or updating password values. Users who
properties have this authorization can do the following:
■ Update a selected account’s properties in the Account
Details page by clicking the Edit button.
■ Manage logon and reconcile accounts in the CPM tab of the
Account Details page with the Associate, Add New, and
Clear buttons.
■ Manage account groups and platforms in the CPM tab of the
Account Details page.
■ Save any account property values that are specified in the
Remote connection details window for transparent
connections when the user connects to a remote machine
from the Accounts List, Account Details page, or the
Versions tab.

245 Safe Members
Initiate CPM Initiate password management operations through the CPM,

password such as changing passwords, verifying, and reconciling
management passwords. Users who have this authorization can initiate CPM
operations password management operations in the Accounts List and the
Search results page, as well as the Account Details page by
clicking Change, Verify, or Reconcile on the toolbar. In the
Change Password window, the ‘Manually selected password’
option will be enabled if the user has the ‘Determine next
password value’ authorization.
Specify next Specify the password that will be used when the CPM changes
password value the password value. Users who have this authorization can do
the following:
■ Specify the next password that will be used as a password
value in the Change Password and Immediate Password
Change pages.
If the user does not have this authorization, the ‘Manually
selected password’ option will be disabled and the CPM will set
a new randomly generated password.
Note:
This authorization can only be given to users to have
the Initiate CPM password management operations
authorization.
Rename Rename existing accounts in the Safe in the Advanced section

accounts of the Edit Account page.
Delete Delete existing passwords in the Safe. Users who have this
accounts authorization can do the following:
■ Delete the account in the Account Details page by clicking
the Delete button.
■ Delete account copies that are linked to Windows accounts
and are stored in the same Safe by clicking Delete in the
password usage tab.
Unlock Unlock accounts that are locked by other users. Users who
accounts have this authorization can do the following:
■ Unlock accounts that are locked by other users in the
Account Details page by clicking Release on the toolbar,
This is only relevant when the Enforce check-in/check-out
exclusive access policy rule is configured.
■ Unlock accounts that are locked by other users in the
Advanced section of the Edit Account page by clicking
Release. This is only relevant when the Enforce check-
in/check-out exclusive access policy rule is configured.

■ Unlock files that are locked by other users in the File Details
page by clicking Unlock on the toolbar.
Workflow
Authorize Give “confirmation” to a Safe members requesting permission to

password enter a Safe. Users also require the ‘List accounts’ authorization
request to see the Request details of the password requests waiting for
their confirmation.
Access Safe Access the Safe without confirmation from authorized users.
without This overrides the Safe properties that specify that Safe
confirmation members require confirmation to access the Safe.
Advanced - Perform folder related activities in the Safe, including the following tasks:
Create folders Create folders in the Safe.
Delete folders Delete folders from the Safe.
Move accounts/ Move accounts and folders in the Safe to different folders and
folders subfolders.
Add Safe members

Users who are authorized to Manage Safe Members in a Safe can add existing Vault
users and groups, as well as users in external LDAP directories, as Safe members in the
PVWA and specify Safe authorizations.
Add Safe members
1. In the Safes list, select the Safe where you will add a Safe member, then click
Members; the Safe Details page appears.
2. In the Members tab, click Add Member; the Add Safe Member window
appears.

247 Safe Members
The default authorizations that will be given to the new Safe Member are
selected. These authorizations can be configured in the Default Safe
Authorizations in the Web Access Options in the System Configuration page.
For more information, refer to Configuring the System through PVWA.
3. In the Search edit box, enter either part of the name of the user or group to add
as a Safe member or the whole name. You can also leave the Search edit box
empty to search for all users.
4. In the Search In drop-down box, select Vault, then click Search; a list of users
and groups in the Vault whose names match the specified keyword is displayed.
5. Select the user or group to add as a Safe member, then select the
authorizations that they will have in the Safe. Select the checkbox next to the
title of the authorizations group to select all the authorizations in that group.
6. Click Add; the selected user or group is added and confirmation appears at the
bottom of the screen.
7. Click Close; the Safe Details page appears and displays the new Safe member
in the Members list.

Add Safe members from LDAP

If the Vault is configured to support transparent user management, users that are
configured in an LDAP directory can be added through the PVWA.
Add Safe Members from LDAP
1. Display the Safe Details page for the Safe where you will add a Safe member.
2. In the Members tab, click Add Member; the Add Safe Member window
appears.
3. In the Search In drop-down box, select the External Directory where the user
that you will add as a Safe member is defined.
4. In the Search edit box, enter either part of the name of the user or group to add
as a Safe member or the whole name. You can also leave the Search edit box
empty to search for all users.
5. Click Search; a list of users in the specified external directory whose names,
user ID or email match the keyword and the relevant Vault LDAP mapping rules
is displayed.
6. Select the user to add as a Safe member, then select the authorizations that
they will have in the Safe. Select the checkbox next to the title of the
authorizations group to select all the authorizations in that group.
7. Click Add; the selected user is added and confirmation appears at the bottom of
the screen.
8. Click Close; the Safe Details page appears and displays the new Safe member
in the Members list.
For more information about managing users in external directories, refer to Transparent
User Management.

249 Safe Members
Manage Safe members

Update Safe member authorizations
Users who are authorized to Manage Safe Members can update existing Safe
Member authorizations.
1. In the Safe Details page, in the Members tab, click the name of the Safe
member to update; the Update Safe Member window appears.
2. Update the Safe authorizations for this Safe member. Select the checkbox next
to the title of the authorizations group to select all the authorizations in that
group.
3. Click Save; the user’s authorizations in the Safe are updated and the Safe
Details page is displayed again.
Remove Safe Members
1. In the Safe Details page, in the Members tab, use the horizontal scroll bar to
scroll to the end of the Safe Member authorizations; you can see the Remove
Member icon.

2. Click the Remove Member icon in the row of the user to remove; a message
appears prompting you for confirmation.
3. Click OK to remove the user from the list of members for this Safe,
or,
Click Cancel to return to the Safe Members list without removing the user from
it.

251
Troubleshooting
If you encountered an error when adding a customer, verify the following:

1. Customer admins and auditors groups are configured in the customer's active
directory.
2. All LDAP connection details are correctly populated in the form.
3. The logo file size is up to 12K.
To further troubleshoot errors when adding a customer, check the following logs on the
PVWA server:
■ Customer Management Console log:
■ C:\Windows\Temp\MSP\msp.log
■ CPM Customer environment creation logs:
■ C:\Windows\Temp\MSP\CPMInstallationLogs\[CustomerID]\cpmdebug.log
■ C:\Windows\Temp\MSP\CPMInstallationLogs\[CustomerID]\cpmsilent.log
■ C:\Windows\Temp\MSP\CPMInstallationLogs\[CustomerID]\CPMInstall.log
■ C:\Windows\Temp\MSP\CPMInstallationLogs\[CustomerID]\cpmmsi.log
For additional assistance contact your CyberArk support representative.

252
Appendices
This chapter contains the following:

Daily Activities
CreateCredFile Utility
Vault Parameter File

Daily Activities
The following table lists the responsibilities of the MSSP administrator and Customer
administrator.
MSSP Customer
Category Activity
admin admin
Login Login with full name Yes Yes

(name@company)
Account Add account No Yes

management
Edit account No Yes
Assign logon/reconcile account No Yes
Move account No Yes
Delete account No Yes
Connect with PSM No Yes
Manually verify credentials No Yes
Manually change credentials No Yes
Manually reconcile credentials No Yes
Onboard bulk accounts No Yes

Note: This task is performed with the
Password Upload Utility. The
MSSP Admin might be
required to create a CyberArk
user for the customer as LDAP
authentication is not currently
supported.
Recordings No Yes
General configuration Update Master policy Yes No
Manage platforms Yes No
Administration Yes No
Reports Billing report according to the number Yes No

of target devices
Customer Add customer Yes No

management
Disable customer Yes No
Manually create customer Safes Yes No

Note: Most customer Safes are

254 Daily Activities
MSSP Customer
Category Activity
admin admin
created automatically. Safe

owners must be added
manually to any additional
Safes that are created.
Manage customer Safe owners û Yes
Manage CyberArk users Yes û

Note: This is not relevant to users
who are mapped automatically
from LDAP.

CreateCredFile Utility
The Vault interfaces access the Vault with a user credential file that contains the user’s
Vault username and encrypted logon information. This user credential file can be created
for password, Token, PKI, or Radius authentication with a utility that is run from a
command line prompt. It can also create a credentials file for authentication through a
Proxy server.
User credential files can specify restrictions which increase their security level and
ensure that they cannot be used by anyone who is not permitted to do so, nor from an
unauthorized location. The updated CreateCredFile utility can enforce any of the
following restrictions:
■ Specific application – The credentials file can only be used by a specific CyberArk
application or module. This can be specified for Password, Token, or PKI
authentication but not for Proxy authentication. For more details about specific
applications, refer to CreateCredFile Utility.
■ Specific path – The credentials file can only be used by an executable located in a
certain path.
■ IP address or hostname – The credentials file can only be used on the machine
where it is created.
■ Operating System user – The credentials file can only be used by an application
started by a specified Operating System user.
These restrictions are specified during the credentials file creation process.
Credential files that were created in versions prior to version 4.5 with the CreateAuthFile
and CreateCredFile utilities can still be used. However, they do not contain the increased
security restrictions that are included in the CreateCredFile utility that is released with this
version.
Credentials files that are created with restrictions will not be supported by CyberArk
components from previous versions.
Before creating or updating the user credential file, make sure that you are familiar with
the user’s authentication details in the Vault as you will be required to provide logon
credentials to generate the encrypted credentials file.
To run the CreateCredFile utility, perform the following actions:
Credential File Security

Credential files are protected using the following mechanisms:
1. The encrypted token (320-bit) is changed on a daily basis. This means that a
credential file that was used today will not be usable tomorrow.
2. The encrypted token is encrypted using AES 256-bit key that comprises the following
parts:
a. Random salt that is stored in the credential file (160-bit). This randomness
assures that each credential file is encrypted with a unique key.
b. Environmental key material:

256 CreateCredFile Utility
■ Client id – Ten characters that identify a specific component

■ OS user – The ID of the OS user who runs the component
■ IP address of the local machine
■ Application – The specific application or module that will use the credentials
file.
c. The key is generated by a secure hash (SHA1) of the above key materials.
3. You can protect your credential files even more using the appropriate operating
system permissions.
Specify Applications
The following CyberArk applications can be specified in a user credentials file:
Application ID
Central Policy Manager CPM
Password Vault Web Access PVWA
Password Vault Web Access application user PVWAApp
OPM and Credential Provider AppPrv
Privileged Session Manager application user PSMApp
CyberArk Replicator/Restore/Prebackup CABACKUP
Disaster Recovery Vault DR
Event Notification Engine ENE
PrivateArk Client WINCLIENT, GUI
CyberArk CLI PACLI
CyberArk ActiveX API XAPI
CyberArk .Net API NAPI
Export Vault Data EVD
CyberArk Encryption Utility CACrypt
Create User Credentials Files

The CreateCredFile utility is located in the CyberArk\Utilities installation folder. It can be
used to create a user credential file for password, RADIUS, Token, or PKI authentication
with a utility that is run from a command line prompt.
It can also create a user credential file for authentication through a Proxy server.
The CreateCredFile utility uses the following syntax:
CreateCredFile <FileName> <command> [command parameters]

Unix
Parameter Specifies
Command
Filename Filename The name of the user credential file to

create or update, specifically user.cred.
Password Password Indicates that the credential file will be

created with password authentication
details.
/Username -username Sets the username in the credential file.

This parameter is required. If you do not
specify it in the command, you will be
prompted for it.
/Password -password The password that will be encrypted in the

credential file.
prompted for it.
/UseOSProtected Use Operating System protected storage

Storage for credential file secret (Windows only).
Valid values are Machine, User and No.
By default, this parameter is set to No.
User Use protected storage that is accessible

only to the user who is logged on and
invoked the CreateCredFile utility.
Machine Use protected storage that is accessible

only for the machine where the
CreateCredFile utility was invoked.
None Do not use operating system protected

storage.
-DisableSync Whether or not passwords in user

/DisableSyncPasswo PasswordToDR credential files will be replicated to all DR
rd sites before they are replaced.
ToDR By default, this parameter is set to ‘No’,
which makes sure that user credential files
on all DR sites (if they exist) are
synchronized with the Production Vault
and that users will be able to continue
working with the Vault seamlessly after a
failover. If this parameter is changed to
‘Yes’, passwords will be replaced in
credential files regardless of whether or
not they have been replicated to all DR
sites.
/ExternalAuth -externalauth The type of external authentication that

will be used to authenticate users to the
Vault.
Radius -radius Creates a user name-password credential

Unix
Parameter Specifies
Command
file for use with RADIUS server.
LDAP -ldap Creates a user name-password credential

file for use with an LDAP directory.
No -no This credential file will not be used with

either a Radius server or an LDAP
directory.
/AppType -apptype A unique application ID that specifies the

<Application ID> <application id> application that will be able use this file.
/ExePath <Path> -exepath <path> The full path of the executable that will be
able to use this file.
Notes:
■ On UNIX machines, if the executable
will be executed from the PATH you
can specify only the name of the
executable. Otherwise, specify the
complete path.
■ When you specify PVWA, specify the
full path of the web server executable,
e.g.
c:\windows\system32\inetsrv\w3wp.e
xe.
/IpAddress -/ipaddress The IP address of the current machine.

When this parameter is specified, the
credentials file will specify the IP address
of the current machine and will only
authenticate the user to the Vault from the
current machine.
Note: Specify either the ‘IPAddress’
parameter or the ‘ClientHostName’
parameter. You cannot specify both.
/ClientHostname -/clienthostname The hostname of the current machine.

credentials file will specify the hostname
authenticate the user to the Vault from a
machine with the specified hostname.
/OSUsername -osusername The name of the Operating System user

<Operating <operating who will be able to use this file.Notes:
System User name> system user ■ On UNIX machines, specify only the
name> username.
■ On Windows machines, specify the
username in “domain_

Unix
Parameter Specifies
Command
name\username” format.
■ When the application is executed as a
Windows service that uses local
system permissions, specify “nt
authority\system”. The quotation
marks are required because of the
space in “nt authority”.
/DisplayRestrictions - When this parameter is specified, the

displayrestrictio generated credentials file will specify all
ns the restrictions in a readable manner. This
will enable users to understand the exact
restrictions on the file.
Token Creates a user credential file with a key

stored on a token.
/Username Sets the username in the credential file.

prompted for it.
/Password The password that will be encrypted in the

credential file.
prompted for it.
/DLLpath Specifies the DLL file path used by the

token device.
prompted for it.
/PIN Specifies the PIN code required by the

token device.
prompted for it.
/ExternalAuth The type of external authentication that

will be used to authenticate users to the
Vault.
Radius Creates a credential file for use with

RADIUS server.
LDAP Creates a credential file for use with an

LDAP directory.
No This credential file will not be used with

either a Radius server or an LDAP
directory.

Unix
Parameter Specifies
Command
/InitToken Initializes the token device for use with

CyberArk password authentication. This
parameter must be specified the first time
you use a token device to store a
CyberArk password encryption key.
/AppType A unique application ID that specifies the

<Application ID> application that will be able use this file.
/ExePath <Path> The full path of the executable that will be

Notes:
complete path.
full path of the web server executable.
/IpAddress The IP address of the current machine

current machine.
/ClientHostname The hostname of the current machine.

/OSUsername The name of the Operating System user

<Operating who will be able to use this file.
System User name> Notes:
■ On UNIX machines, specify only the
username.

Unix
Parameter Specifies
Command

/DisplayRestrictions When this parameter is specified, the

generated credentials file will specify all
the restrictions in a readable manner. This
PKI Creates a credential file based on a PKI

certificate.
/CertIssuer Personal certificate issuer.
/CertSerial Personal certificate serial number.
/PIN Specifies the PIN code required to access

the certificate.
This parameter is required if the certificate
is stored on a Token.
/AppType A unique application ID that specifies the

<Application ID> application that will be able use this file.

Notes:
complete path.
/IpAddress The IP address of the current machine.

current machine.
/ClientHostname The hostname of the current machine.


Unix
Parameter Specifies
Command


<Operating who will be able to use this file.
System User name> Notes:
■ On UNIX machines, specify only the
username.

PROXY Creates a credential file based on PROXY

authentication.
/ProxyUser The name of the Proxy user.

prompted for it.
/ProxyPassword The password that will be decrypted in the

credential file.
prompted for it.
/ProxyAuth Domain The domain name of the Proxy user.

Notes:
complete path.
/IpAddress The IP address of the current machine.

Unix
Parameter Specifies
Command

current machine.
/ClientHostname -/clienthostname The hostname of the current machine.


<Operating who will be able to use this file.Notes:
System User name> ■ On UNIX machines, specify only the
username.

/? Lists the available options.

The following instructions explain how to create a user credential file. The examples used
in these instructions run the utility from the Utilities subfolder, and create a credential file
called ‘user.cred’.
Note:
The text typed by the user appears in bold.

Create the User Credential File for Password Authentication

1. At the command line prompt, run the CreateCredFile.exe utility. You must specify
the username and password to the Vault. You can also specify whether or not Radius
authentication will be used.
For extended security on Windows systems, store the secret of the credential file in
Windows protected storage by using the /UseOSProtectedStorage parameter.
Use the following guidelines when protecting the secret in the Windows protected
storage:
■ When the user who creates the credential file is the only user who will
use it: Store the credential file secret in the user's Windows protected storage by
specifying the /UseOSProtectedStorage User parameter. This ensures that
only the user who created the credential file will be able to access its secret.
■ For CyberArk services or when the user that created the credential file is
not the user that will use it: Store the credential file secret in the machine's
Windows protected storage by specifying the /UseOSProtectedStorage
Machine parameter. This ensures that the credential file secret will only be
accessible from the machine where it was created.
Example:
>createcredfile.exe user.cred Password /username Paul
/password Pass /ExternalAuth radius
/UseOSProtectedStorage Machine
The above example shows that this credential file will be called ‘user.cred’, and will
contain an encrypted password for the Vault user called ‘Paul’. The credential file's
secret will be stored in the machine's Windows protected storage. The file can be
used to log onto the file with Radius authentication.
If you do not specify the command parameters, username, password, and radius,
you are prompted for them now. An example of this appears in the following
example:
Example:
Vault Username [mandatory] ==> Paul
Vault Password (will be encrypted in credential file) ==>
*******
Radius server will be used for authentication (yes/no) [y]
==> yes
The user’s credential file will now be created and saved in the current folder.
Command ended successfully

Create the User Credential File using a Token

The Vault supports logon with a password that has been encrypted by a key on a USB
token or a Smartcard. This password is stored in the user’s credential file, and is
decrypted by the external token for logon.
Any PKCS#11 token can be used for this type of authentication, as long as it meets all of
the following criteria:
■ The token must be a hardware token.
■ The token is accessible through the PKCS#11 interface.
■ Access to the token is only possible after supplying a PIN.
■ The token supports RSA with 1024 or 2048 bit key length.
■ The token must be able to perform encryption and key generation in hardware.
These instructions are for creating a user credential file with a new external token.
1. Attach the token to the computer.
■ If you are using a USB token, place the token in the USB port.
■ If you are using a Smartcard, place the card in the Smartcard reader.
2. At the command line prompt, run the CreateCredFile.exe utility. You must specify
the username and password to the Vault, the full path of the PKCS#11 dll file that will
encrypt the password, and the PIN that is required by the token device. You can also
specify
Example:
>CreateCredFile.exe user.cred token /username Paul
/password Pass /dllpath i:\windows\system32\eTpkcs11.dll
/pin PinPass
The above example shows that this credential file will be called ‘user.cred’, and will be
created with a key that is stored on a token. ‘Paul’ is the user who will be specified in
the credential file, together with his password, asdf. The dll path used by the token
device is specified, as well as the PIN that is required to access the token device.
If you have not specified the username, password, dll path and password, you are
prompted for it now.
Example:
Vault Username [mandatory] ==> Paul
Vault Password (will be encrypted in credential file) ==>
*******
Path of Token dll [mandatory] ==>
i:\windows\system32\etpkcs11.dll
Pin code required by the Token device ==> ********
Radius server will be used for authentication (yes/no)
[optional] ==> no
Initialize the Token (yes/no) [optional] ==> no
3. To initialize the token, type yes,

or,
If the token has already been initialized with the CreateCredFile utility, type no.
The user credential file is now created and saved in the current folder.
Create the User Credential File for PKI Authentication

The user can create a user credential file for logon with a PKI certificate. Before creating
the credential file, the authentication certificate must be imported into the Microsoft
Windows certificate store. For more details, refer to CreateCredFile Utility.
Note:
A PIN to access a PKI certificate can only be used in a Windows 2000 environment or
higher.
■ At the command line prompt, run the CreateCredFile.exe utility.
Example:
CreateCredFile.exe user.cred PKI /certissuer CN=MyCompany_
CA /certserial "1963f68d00000000017c" /Pin PinPass
/AppType PACLI /ExePath "C:\Program
Files\PrivateArk\Client\PACLI.exe" /IPAddress /OSUsername
my_dom\Paul
/DisplayRestrictions
The above example shows that this credential file will be called ‘user.cred’, and will be
created based on a PKI certificate. The certificate issuer for this credential file is
MyCompany_CA and the certificate detail serial number is
‘1963f68d00000000017c’. The PIN required to access this certificate is ‘12341234’.
If you do not specify the certificate issuer and serial number, the Select Certificate
window appears to enable you to select the PKI certificate that will give the user
access to the Vault.
Note:
If a PIN is required to access the certificate, you must enter the PIN in the command line.

■ Select the PKI certificate to use, then click OK; the user’s credential file will now be
created and saved in the current folder.
The following message appears to confirm that the authentication file has been
created successfully.
Import a Certificate for Authentication

Authentication certificates can be used to authenticate to the Vault if the certificate has
been imported into the Microsoft Windows certificate store.
The certificate store is divided into several locations to limit accessibility (for security
reasons). The most common location for certificates is the “Current User” location. When
importing certificates into Microsoft Windows, this is the default location into which the
certificates are imported. The certificates in the “Current User” location are only
accessible to the user that is currently logged on. One user will not be able to access
certificates in another user’s “Current User” location.
Create the User Credential File for Proxy Authentication

The Proxy user and password can be stored encrypted in a credentials file instead of
being specified in the Vault parameter file.
1. At the command line prompt, run the CreateCredFile.exe utility.
Example:
>createcredfile.exe user.cred Proxy /ProxyUser PUser

/ProxyPassword Pass /ExePath "C:\Program

Files\PrivateArk\Client\PACLI.exe" /IPAddress /OSUsername
my_dom\Paul /DisplayRestrictions
The above example will create a file called ‘user.cred’ and will enable the proxy user
to log onto the Vault with proxy authentication. The credentials file will contain an
encrypted proxy password for the proxy user called PUser.
If you do not specify the name and password of the proxy user, you will be prompted
for them. An example of this appears in the following example:
Example:
Proxy Username [mandatory] ==> PUser
Proxy Password (will be encrypted in credential file) ==>
****
Domain name of ProxyUser [optional] ==> MyCompany.com
The user’s credential file will now be created and saved in the current folder.


The Password Upload utility works with the CyberArk Password Vault to create accounts
from a passwords list and store them in the Vault. This makes the Vault implementation
process quicker and more automatic.
Implement the Password Upload Utility

The Password Upload utility uploads multiple accounts to the Password Vault, making
the Vault implementation process quicker and more automatic. This utility works by
uploading passwords and their properties into the Password Vault from a pre-prepared
file, creating the required environment, when necessary. It is run from a command line
whenever a password upload is required.
This section describes how to implement the Password Upload utility.
Create the Vault Environment Automatically

The Password Upload utility initiates the Vault environment required to store passwords
in the Safe and start working with them. This includes creating new Safes, adding the
CPM user as a Safe owner, and sharing the Safe with the Password Vault Web Access.
Create New Safes
The Password Upload utility uses Template Safes to create Safes automatically
with the properties that are specified in the Template Safes. You can create
different types of Template Safes, depending on your requirements. When the utility
uploads passwords into the Vault, if the specified Safe doesn’t exist, the utility will
create a new Safe based on the Template Safe that is specified in the password file.
If a Template Safe is not specified, a new Safe will be created, based on the default
Template Safe that is specified in the utility configuration file.
To create a new Safe based on a Template Safe, the user running the utility
requires the following authorizations in the Vault:
■ The ‘Add Safes’ user authorization
■ Ownership of the Template Safe with at least one authorization
Add the CPM User as a Safe Owner
The Password Upload utility adds a CPM user automatically to new and existing
Safes to which it uploads passwords, with the following authorizations:
■ View Audit
■ View Safe Members
■ Retrieve accounts
■ List accounts
■ Add accounts
■ Access Safe without Confirmation

270 Password Upload Utility
■ Unlock accounts (dependent on the parameters specified in the configuration

file)
■ Manage Safe (dependent on the parameters specified in the configuration file)
The name of the CPM user is specified in the password file.
To add the CPM user to existing Safes, the user running the utility requires the
above authorizations in the Safe as well as the Manage Safe Members
authorization.
Share the Safe with the Password Vault Web Access
The Password Upload utility automatically shares new and existing Safes to which it
uploads passwords with the Password Vault Web Access gateway account whose
name is specified in the utility configuration file. This enables users to access
passwords through the Password Vault Web Access as soon as they have been
uploaded to the Safe.
To share existing Safes with the gateway account, the user running the utility
requires the Manage Safe authorization in the Safe.
The following diagram shows the procedure to follow to enable the utility to upload
password objects successfully.
In the PVWA
1. Create the Safes where the passwords will be stored. For more
information, refer to Adding and Managing Safes
2. If this Safe will be used as a Template Safe:
■ If this Safe will be used as a Template Safe for all the new Safes that
will be created automatically when the utility uploads the password list,
in the utility configuration file, in the DefaultTemplateSafe parameter,
specify the default template Safe that will be used to create new Safes.

■ If different Template Safes will be used for different password files,

specify the name of the relevant Template Safe in the password file.
Note:
The name of the Template Safe only needs to be specified the first time
the non-existent Safe
For more information about Template Safes, refer to Create New Safes.
Note:
This utility only supports Safe, folder, and file names in English. Make
sure that all Safe and folder names are in English.
3. If you created Safes manually, give the user that will run the utility Safe
ownership of all the Safes specified in the password file, with the following
authorizations:
■ Add accounts
■ Update password values
■ Access Safe without confirmation – In existing Safes that require
confirmation from authorized users before they can be accessed (dual
control)
4. In the ADMINISTRATION, in Platform Management, configure the target
account platform that will determine the type of password that is allowed
and how frequently it must be changed. Each platform has a unique
platform name which will be specified in the password file for each
password object.
For more information about platforms, refer to Adding New Platforms,
page 1.
On the machine where the utility is installed
1. In the utility installation folder, open the Vault parameter file and specify the
parameters of the Vault into which the password objects will be uploaded.
For more information, refer to Vault Parameter File in the Privileged
Account Security Reference Guide.
2. If you want to run the utility automatically, so that you do not have to supply
the user name and password, create a user authentication file for the user
who will run the utility. For more information, refer to Appendix B: Creating
User Credential Files.
3. In the utility installation folder, open the password file and specify the
password objects and their properties to upload to the Vault, then save the
file in Comma Separated Values (CSV) format. For more information,
refer to Create the Password File, page 272.
4. In the utility installation folder, open the configuration file and do the
following:
■ Specify the parameters that will enable the utility to upload the
password file to the Vault.

■ Set the following parameter:
CPMUserAdminRights=yes
For more information, refer to Configure the Password Upload Utility,

page 275.
5. At a command line prompt, run the Password Upload utility.
The following example would run the utility according to a configuration file
called Conf.ini. As no path is specified, the file is stored in the utility
installation folder.
> PasswordUpload Conf.ini
For more information, refer to Run the Password Upload Utility.
Create the Password File

Password parameters that will be uploaded to the Vault are stored in a text file as
Comma Separated Values (CSV). The first line in the file defines the names of the
password properties as specified in the Password Vault. Every other line represents a
single password object and its property values, according to the properties specified in
the first line.
Note:
This utility only supports Safe, folder, and file names in English. Make
sure that the filename is in English and that all Safe, folder, and file
names match the exact case of those in the Vault.
Password properties
The following password properties are required for every password object that will
be uploaded to the Vault:
Password_ The name of the Password object.

name
Safe The name of the Safe where the password object will be stored.
Folder The name of the folder where the password object will be stored.
Password If the password object is new, a password must be specified.

To upload a new password object with a blank password, specify
“NO_VALUE”.
A password property, whose value is not specified in the password values, will not
be specified in the password object when it is uploaded to the Vault.
Save a Password File in Excel
You can create a password file in Excel and save it in CSV format so that it can be

uploaded to the Vault. Each column in the Excel file represents a different password
property.
1. In the utility installation folder, open the sample password file and specify the
values of the passwords that will be uploaded to the Password Vault when the
utility is run.
Note: Do not change the order of the first 6 columns in the password file (Password_
name, TemplateSafe, CPMUser, Safe, Folder, Password).
2. Save the file in CSV format.
Specify Passwords in the Password File

Passwords that will be changed automatically by the CPM require the following
additional password properties.
Platform name The Platform Name parameter of the platform that will be applied to this
password, and is specified in the platform.
UserName The name of the user on the remote machine who this password belongs
to.
Address The address of the Vault where the password will be changed (IP or
DNS).
Other password parameters are optional. For a complete list of password object
properties that are created when the Password Vault is installed, refer to Appendix A:
Account Properties.
Add Password Properties without a Value
Some password properties do not require a value, but can be added to the
password object when it is uploaded to the Vault.
■ In the password property value, specify NO_VALUE; the password property
will be added to the password object, but a value will not be assigned to it.
Delete Password Properties
A password property can be deleted from an existing password object.
■ In the password property value, specify DELETE; when the password object is
uploaded to the Vault, the password property will be deleted from the password
object.
Update Existing Password Objects
Both passwords and properties in existing password objects can be updated
through the password file.
■ In the password file, specify the new value for the password or the password
property to update. Password or property values that will not be changed should
be left empty; when the utility uploads the password and password properties to
the Vault, existing password objects will be updated.
A configuration parameter in the utility configuration file must specify that properties
in existing password objects can be updated. For more information, refer to
Configure the Password Upload Utility, page 275.

Add Comments to the Password File

Lines that are marked as comments will not be uploaded to the Password Vault.
Tip:
To mark a line as a comment, at the beginning of the line, type hash
(#).
Example
The following sample password file displays a header line with two passwords to
upload to the Password Vault.
Password_
ame,TemplateSafe,CPMUser,Safe,Folder,Password,DeviceType,PolicyID,
UserName,Address,CPMDisabled,ResetImmediately
Operating System-UnixSSH-1.1.1.250-Root,ExclusivePasswordsTemplate,
PasswordManager,UnixPasswords,Root,asdf,Operating
System,UnixSSH,Root, 1.1.1.250,,NO_VALUE
Operating System-Windows-1.1.1.227-Administrator,,,WindowsPasswords,
Root\Domains,1234,Operating
System,Windows,Administrator,1.1.1.227,NO_VALUE
Password 1:
The first password object that will be uploaded is for use on an Operating System
device and will be managed by the UnixSSH platform. This password is called
Operating System-UnixSSH-1.1.1.250-Root and will be stored in the
UnixPasswords Safe in the Root folder. If this Safe does not exist, it will be
created according to the ExclusivePasswordsTemplate Safe. The CPM user
called PasswordManager will be added to the Safe with all the authorizations
required to enable him to manage the passwords within. This Safe will be shared
with the gateway account specified in the ‘GWAccounts’ parameter in the
configuration parameter file. The password is asdf. This password is intended for
the Root user on the machine whose host IP is 1.1.1.250. The CPMDisabled
property is not specified and therefore the password will be managed by the CPM.
The ResetImmediately value has not been specified, but the property will be
specified in the password object, and the password will be changed by the CPM
during the next cycle.
Password 2:
The second password object that will be uploaded is for use on an Operating
System device and will be managed by the Windows platform. This password is
called Operating System-Windows-1.1.1.227-Administrator and will be stored
in the WindowsPasswords Safe in the Root\Domains folder. If this Safe does not
exist, it will be created according to the default Template Safe specified in the
‘DefaultTemplateSafe’ parameter in the configuration parameter file. As no CPM
user is specified, the CPM user will not be added as a user to the Safe. The
password is 1234. This password is intended for the Administrator user on the
machine whose host IP is 1.1.1.227. The CPMDisabled property value has not

been specified, but the property will be specified in the password object, and the
password will not be changed by the CPM until this property is removed. The
ResetImmediately property has not been specified and will not be added to the
password object.
Configure the Password Upload Utility

The Password Upload utility is configured through a parameter file that contains
references to parameter files and to specific parameters that determine the utility’s
functionality.
A sample configuration file is included in the package that contains the Password Upload
utility.
For a complete list of the parameters in the Password Upload utility’s configuration file,
refer to the Privileged Account Security Reference Guide.
Update Existing Password Objects
The Password Upload utility can update existing password object properties and
passwords in the Vault according to the properties specified in the CSV file.
In the utility configuration file, specify the following parameter:
UpdateIfExists=Yes
If UpdateIfExists=No, neither passwords nor password properties can be

updated by the utility.
Create Missing Folders in the Vault
If the password object properties in the password file specify a folder in the Vault
that does not exist, the Password Upload utility can create the new folder and
create the password object in that folder.
In the utility configuration file, specify the following parameter:
CreateMissingFolders=Yes
Manage Errors
If an error occurs when the Password Upload utility is uploading a password object
from the password file, the utility can either abort the upload process or skip to the
next password object to upload in the password file. In both cases, an error will be
written to the error log.
■ To abort the upload process if a password object cannot be uploaded, specify
the following parameter:
StopOnError=Yes
■ To continue uploading the next password object in the password file, specify the
following parameter:

StopOnError=No
Example:
Below is a sample configuration file:
#---------------------
# Mandatory parameters
#---------------------
Os=windows
VaultFile=vault.ini
PasswordFile=passwords.csv
DefaultTemplateSafe=”Default Template”
CPMUserAdminRights=yes
AllowFullImpersonationSharing=no
GWAccounts=PVWAGWAccounts
#---------------------
# Optional parameters
#---------------------
SessionId=1
CredFile=user.ini
LogFile=UploadPasswords.log
ErrorLogFile=ErrorLog.log
UpdateIfExists=yes
StopOnError=no
CreateMissingFolders=yes
VerboseMode=yes
DebugMode=no
The above sample parameter file specifies the name of the Vault parameter file,
vault.ini. As a pathname is not specified, the utility will look for it in the same folder
that the utility is running from. The list of password objects to upload are stored in
the passwords.csv file in the same folder as well.
If the Safe specified in the CSV file does not exist, and no specific Template Safe is
defined, the Safe called Default Template will be used as the Template Safe. If the
CPM user is specified in the CSV file, it will be added to the new Safe with the
Manage Safe authorization, which will enable him to manage Safes in Exclusive
Passwords mode. The new Safe will be shared by the PVWAGWAccounts
gateway accounts group and impersonation will be set to Enable access to
impersonated users with additional Server authentication. As a result, users
who log onto the Vault through the Password Vault Web Access will be required to
supply a username and password (Vault, Radius or LDAP authentication).
The utility will allocate Session ID number ‘1’ to this session.
The user.ini credentials file is specified, indicating that the user running the utility
will be able to log onto the Vault automatically, without any human intervention.
All activities will be saved in a log file called UploadPasswords.log, while error
messages will be saved in a file called ErrorLog.log. Neither of these parameters

specifies a pathname, indicating that they will also be saved in the same folder as
the utility.
The utility will replace existing passwords or password object properties with
passwords or password properties specified in the password file that is being
uploaded. If, for any reason, an error occurs and a password object cannot be
uploaded to the Vault, the utility will write an error message in the ErrorLog.log file
and continue uploading the next password object in the password file. If the
password object properties in the password file specifies a folder in the Vault that
does not exist, the utility will create that folder and store the new password object in
it.
The VerboseMode parameter determines that when this utility runs, the user will be
able to see how the upload process develops by viewing constant messages,
confirmations, and errors on the screen.
When this configuration file is used to run the utility, the debug mode will not be
activated.
Run the Password Upload Utility

The Password Upload utility is a command line utility that has the following usage:
PasswordUpload <Configuration Filename>
Configuration The name of the configuration file that contains references to the
Filename password file to upload, and parameters that determine the utility
functionality. This configuration file is described in detail in Configure the
Password Upload Utility.
Before running the utility, make sure that the user who will run it is an owner of existing
and Template Safes that are specified in the password file with the appropriate
authorizations. For more information, refer to .
Run the Password Upload Utility
At the command line prompt, run the PasswordUpload utility.
■ If you do not specify a user credentials file, you will be prompted for the user
name and authentication of the Vault user running the utility.
■ If you specify the user credentials file, you will not be prompted for user
authentication. For more information about creating user credentials files, refer
to Appendix B: Creating User Credential Files.

278 Vault Parameter File
Vault Parameter File

The Vault.ini file contains all the information about the Vault that will be accessed by
CyberArk components. Each component that will access the Vault requires a Vault.ini file
of its own.
During installation, the Vault.ini file is copied to the installation folder.
Notes:
■ The semicolon (;) and hash (#) characters indicate the beginning of a remark. However, if
these characters appear between quotation marks (“”) or after an equals sign (=) they are
considered to represent a parameter.
■ All parameters must be specified without spaces.
Parameters
Vault
Description The name of the Vault.
Acceptable Values String
Default Value None
Address
Description The IP address of the Vault. Currently there is no limit to the number
of IP addresses that you can specify.
Note: Currently multiple Vault IP addresses is supported on the
CPM, PVWA, OPM, and PSM.
Acceptable Values IP address,IP address,IP address,…
Default Value None
Port
Description The Vault IP Port.
Acceptable Values Number
Default Value 1858
Timeout
Description The number of seconds to wait for a Vault to respond to a command

before a timeout message is displayed.
Default Value 30
SwitchVaultAddressTimeOut

Parameters
Description The number of seconds that the Vault component will try to access
additional Vault IP addresses after the initial timeout to the current
Vault, specified in the Timeout parameter, expires.
Note: Currently this is relevant to the CPM, PVWA, OPM, and
PSM.
Acceptable Values Number of seconds
Default Value 3
AuthType
Description The type of authentication to be used to log onto the Vault.
Acceptable Values PA_AUTH (Password), NT_AUTH, PKI_AUTH, LDAP, RADIUS
Default Value PA_AUTH (Password)
NTAuthAgentName
Description The name of the NT Authentication Agent.
Acceptable Values String (1-260 characters)
Default Value None
NTAuthAgentKeyFile
Description The name of the NT Authentication Key File.
Default Value None
VaultDN
Description The Distinguished Name of the Vault (PKI Authentication).
Default Value None
ProxyType
Description The type of proxy through which the Vault is accessed.
Acceptable Values HTTP, HTTPS, SOCKS4, SOCKS5
Default Value None
ProxyAddress
Description The proxy server IP address. This is mandatory when using a proxy
server.
Acceptable Values IP address
Default Value None
ProxyPort

Parameters
Description The Proxy server IP Port.
Default Value 8081
ProxyUser
Description User for Proxy server if NTLM authentication is required.
Acceptable Values User name
Default Value None
ProxyPassword
Description The password for Proxy server if NTLM authentication is required.
Acceptable Values Password
Default Value None
ProxyAuthDomain
Description The domain for the Proxy server if NTLM authentication is required.
Acceptable Values Domain name
Default Value NT_DOMAIN_NAME
BehindFirewall
Description Accessing the Vault via a Firewall.
Acceptable Values Yes/No
Default Value No
UseOnlyHTTP1
Description Use only HTTP 1.0 protocol. Valid either with proxy settings or with
BEHINDFIREWALL.
Default Value No
NumOfRecordsPerSend
Description The number of file records that require an acknowledgement from the
Vault server.
Default Value 15
NumOfRecordsPerChunk
Description The number of file records to transfer together in a single TCP/IP

send/receive operation.

Parameters
Default Value 15
ReconnectPeriod
Description The number of seconds to wait before the sessions with the Vault is
re-established.
Default Value 1
EnhancedSSL
Description Whether or not to use an enhanced SSL based connection (port 443
is required).
Default Value No
PreAuthSecuredSession
Description Whether or not to enable a pre- authentication secured session.
Default Value No
TrustSSC
Description Whether or not to trust self-signed certificates in pre-authentication

secured sessions.
Default Value No
ProxyCredentials
Description This name of a file that contains the proxy credentials. This
parameter can be used to replace the ProxyUser and ProxyPassword
parameters.
Acceptable Values Full pathname
Default Value None
CTLFileName
Description The path to the CTL file for Radius authentication.
Acceptable Values Valid path to base64 CTL file
Default Value None
AllowSSCFor3PartyAuth
Description Whether or not self-signed certificates are allowed for 3rd party
authentication (eg, RADIUS).

Parameters
Default Value No
CIFSGateway
Description The name of the CIFS Gateway.
Default Value None
HTTPGatewayAddress
Description The URL of the HTTP Gateway.
Acceptable Values URL
Default Value URL
DistributedVaults
Description Whether or not CyberArk Clients will work in Distributed Vaults

mode, and will be able to send requests to one of a list of available
Vaults.
When this parameter is set to Yes, the Address parameter must
specify an address that returns a DNS SRV record which indicates
the Vault to which the client will send requests.
When this parameter is set to 'Static' the Address parameter must
specify the IP/DNS address, using the following format: IP
address,IP address,IP address,….
Acceptable Values Yes, No, Static
Default Value No
FailbackInterval
Description The number of seconds between client requests to check the SRV
record.
Acceptable Values Number of seconds
Default Value 1800 (30 minutes)

CyberArk Managed Security Service Provider Solution Implementation Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CyberArk Managed Security Service Provider Solution Implementation Guide

Hochgeladen von

Copyright:

Verfügbare Formate

CyberArk Managed Security

Service Provider Solution

Copyright © 1999-2017 CyberArk Software Ltd. All rights reserved.

PAS Offering for Managed Security Service Provider 5

Managed Security Service Provider

Authenticate to the Privileged Account Security Solution 99

Managed Security Service Provider

Header parameter 227

Managed Security Service Provider

PAS Offering for Managed Security

Managed Security Service Provider

General Create a centralized overview of the security and compliance policy of

Inventory To support your billing processes and streamline maintenance

Managed Security Service Provider

High level architecture

Note:The Service Provider is responsible for ensuring secure access to

Managed Security Service Provider

Security and multi-tenancy

Managed Security Service Provider

Managed Secure Service Provider

Managed Security Service Provider

Recommended Server Specifications

Vault and DR Vault Servers

Managed Security Service Provider

Central PVWA and CPM

Managed Security Service Provider

Install the Multi-Tenant Vault

Harden the CyberArk Vault

Vault Installation Requirements

Managed Security Service Provider

Vault location on hard drives

Preparation for backup

Preparation of CyberArk Vault Keys

Folder Group Permission

PAKeys Administrators Read/Write

Managed Security Service Provider

Server Key storage on a Hardware Security Module (HSM)

Configure the Vault Interface Language for Non-unicode Programs

Preparation of the CyberArk Vault Server

Note:It is essential to install a clean Operating System or image, and

2. Check that the Administrator password is appropriately strong. For example,

Managed Security Service Provider

Note:It is important to verify the network connection before installing the

Note:This is recommended for additional physical security.

9. Secure the Server machine BIOS by setting a password.

Note:For more information about implementing DEP, refer to Microsoft

11. Install a compatible version of Windows, as described in Digital Vault Server.

Note:This step is not relevant for High-Availability.

13. Reboot the Server.

Managed Security Service Provider

Install the CyberArk Vault Server

Install the Vault Remotely in an RDP Session

Managed Security Service Provider

to complete Vault installation by physically accessing the machine where

Make sure that the following message appears:

Configure HSM Key Management

Managed Security Service Provider

Initial Vault Configurations

2. Configure the PKCS#11 provider DLL and specify it in the

3. Save DBParm.ini and close it.

b. On HSM devices that do require the key to be encrypted, from a

Managed Security Service Provider

4. In DBParm.ini, change the value of the ServerKey parameter as follows:

Managed Security Service Provider