Documente Academic
Documente Profesional
Documente Cultură
Version v9.10
Table of Contents
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
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.
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.
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.
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.
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).
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.
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.
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.
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.
8. In the server machine BIOS security, set the Server machine’s boot
sequence to boot from the hard drive first.
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
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.
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
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.
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.
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.
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:
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.
Following Installation
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.
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.
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
Note:
For security reasons, this password must be changed after testing
Considerations
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.
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 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.
6. Read the license agreement, then click Yes to accept its terms and proceed
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.
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
Oracle databases.
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)>"
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
Note:
The credentials file is created dynamically during CPM installation, and is not removed
automatically when the CPM is uninstalled
■ 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:
■ Python C:\Python27
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
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
■ 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
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.
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.
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
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.
5. 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.
6. Read the license agreement, then click Yes to accept its terms and proceed
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 Web application destination window which enables
you to select the folder on your computer where 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
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:
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
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.
■ 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.
If you will use Internet Explorer in Windows 2008 to browse to the PVWA,
change the following setting:
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.
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'.
Note:
To configure the two instances of the PVWA to access the same configuration
files, change the GWUserName parameter and the ApplicationUserName
parameter
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
Implementation Guide.
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.
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
■ 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:
■ Retrieve passwords/files
■ List passwords/files
■ 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
■ Retrieve passwords/files
■ List passwords/files
■ Update password value
This group is also added automatically to the PasswordManager_Info Safe with the
following authorizations:
■ Retrieve passwords/files
■ List passwords/files
■ 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:
■ Retrieve passwords/files
■ List passwords/files
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
Implementation Guide.
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.
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.
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.
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.
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.
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
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
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 Replicate 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 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
3. Click Next to proceed to the next step of the 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.
10. 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 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,
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>]
/?
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.
[/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.
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’.
Note:
When PAReplicate is executed, it automatically carries out a pre-backup procedure,
and there is no need to run PAPreBackup separately
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
[/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.
/MetadataOnly Replicates only the metadata backup files, not the data files.
/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.
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
Implementation Guide.
2. Check the replication log to make sure that the Vault was replicated
successfully:
C:\Program Files\PrivateArk\Replicate\Replicate.log
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.
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.
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
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 Disaster Recovery 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 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.
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.
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.
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:
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
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
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
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.
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.
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
directory, then click Sign in; 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.
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.
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:
/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
Parameter Description
Note:
This parameter is not relevant for Radius
configuration and should not be used to
create the Radius secret file.
Note:
If you don’t specify the secret in the SecureSecretFiles
command, you will be prompted for it.
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.
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.
Note:
You can exit installation at any time by clicking Cancel.
You can return to the previous installation window by
clicking Back, where applicable.
c. Read the license agreement, then click Yes to accept its terms and
proceed to the Ready to Install window.
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.
vii. In the General tab, set the User type to EPVUser; the
following message appears:
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.
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
Account Security Implementation Guide.
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
Auditors Auditors
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,
The following table lists several scenarios and the valid value for each one.
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
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, 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.
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.
https://<FullDomainName>/PasswordVault/api/auth/cyberark/logon
Resource Information
HTTP method POST
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
Resource Information
HTTP method POST
{
"TenantId": "<Customer UniqueID>",
"Address": "<Radius Server IP>",
"Port": 1812,
"Hostname": "",
"Secret": "<Radius Client Shared Secret>"
}
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.
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
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.
Note:
Specify a folder name without spaces.
3. In the PVWA, display Accounts > Files, and search for the CPM-
DeployFiles file.
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.
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
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.
The following sample scenario shows how to calculate the required space in the Vault for
a PSM implementation:
PSM implementation
Consideration Enterprise requirement
requirement
PSM implementation
Consideration Enterprise requirement
requirement
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 .
Note:
For information about Setting up RDS on Windows 2008R2 or Windows 2012R2, refer
to the Microsoft documentation.
PSM License
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.
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.
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.
2. Start the installation procedure:
Double-click Setup.exe or,
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.
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 Customer Information window, which enables you to enter user
information.
6. 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 the PSM server where the PSM will be installed.
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:
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.
Note:
This step is mandatory.
During installation, the following two Windows users are created for the PSM
environment on the PSM machine:
User Description
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.
8. Click Browse; the Browse for a 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.
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.
Note:
The PSMConnect password can be managed by the CPM and is changed
periodically.
Note:
You can configure the maximum PSM session duration in PSM configuration in
the PVWA.
Note:
The PSMAdminConnect password can be managed by the CPM and is changed
periodically.
Note:
You can configure the maximum PSM session duration in PSM configuration in
the PVWA.
Note:
This step is mandatory.
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
FromHour 2
ToHour 5
Parameter Value
VFFromHour 2
VFToHour 5
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
Stage Tasks
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
Stage Tasks
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.
Get-ExecutionPolicy
2. If the command does not return the RemoteSigned status, run the following
command to allow local PowerShell scripts to run
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.
./PSMHardening.ps1
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.
3. From the Available snap-ins area, select Group Policy Object Editor, and
then click Add. The Select Group Policy Object window appears.
4. Click Browse; the Browse for a 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.
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:
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
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
Note:
This step is relevant for PSM servers installed on Windows 2012 R2
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….
6. In the Welcome to the Import Settings Wizard window, click Next. The
Backup GPO window 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.
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.
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.
Note:
This step is relevant for PSM servers installed on Windows 2012 R2
5. Browse to the folder where the INF hardening file is located, for example,
CyberArk PSM Hardening, and open it.
5. Browse to the folder where the Advanced Audit.csv is saved, and open it.
Note:
Customer's discretion is required!
Policy Setting
Services
Vulnerability: Unnecessary services are expose the server to vulnerabilities and
increasing the attack surface
Services
Vulnerability: Unnecessary services expose the server to vulnerabilities
and increase the attack surface
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.
Note:
Customer's discretion is required!
Policy Setting
Services
Policy Setting
Policy Setting
Services
Administrative Templates → Windows components → Remote Desktop Services →
Remote Desktop Session Host → Device and Resource Redirection
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.
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.
C:\Program Files
(x86)\CyberArk\PSM\Components\PSMInitSession.exe
d. Make sure that all the Client devices checkboxes are clear.
c. Click OK.
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.
Note:
You can configure the maximum PSM session duration in PSM
configuration in the PVWANote
C:\Program Files
(x86)\CyberArk\PSM\Components\PSMInitSession.exe
d. Make sure that all the Client devices checkboxes are clear.
3. In the Remote Control tab, do the following:
c. Click OK.
5. In the Account tab options, select the following:
Note:
You can configure the maximum PSM session duration in
PSM configuration in the PVWA
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.
C:\Program Files
(x86)\CyberArk\PSM\Hardening\PSMHardening.ps1
./PSMHardening.ps1.
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.
$PSM_CONNECT = "Domain.com\DomainPSMConnect"
$PSM_ADMIN_CONNECT = "Domain.com\DomainPSMAdmin"
./PSMConfigureAppLocker.ps1
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.
■ 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
Note:
After the Safes have been created, change users' permissions
according to the tasks that they perform.
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.
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.
Note:
For security reasons, it is highly recommended not to use a self-signed
certificate for LDAPS connections.
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.
General details
Details Description
Services
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.
Note:
Specify these detailsexactlyas they appear in the organizational Active
Directory.
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.
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
Note:
Make sure that the secure connection certificate is
installed before adding the customer.
AD groups mapping
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
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.
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
Account Security Implementation Guide.
6. If Provision LDAP users automatically is not selected, in the PrivateArk
Client, create the customer admin user with following settings:
Setting Value
Authentication Password
method Select User Must Change Password at Next Logon
Setting Value
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
Privileged Account Security Implementation Guide.
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
■ 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.
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.
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.
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.
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
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
Privileged Account Security Implementation Guide.
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.
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.
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
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
Implementation Guide.
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
Resource Information
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>",
"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>"
}
}
Type String
Valid values -
Type String
Parameter ContactName
Type String
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
Valid values -
Parameter SupportedServices
Type StringArray
Description The services supported by the MSSP for this customer (EPV, PSM, EPM).
Default EPV
Type String
Description The authentication that will be used by the customer to authenticate to the
PVWA.
LdapDetails
Type String
Valid values -
Type String
Valid values -
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.
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
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.
Type String
Description The customer's admin users group in the Active Directory. Use the
Distinguished Name format.
Valid values Specify these details exactly as they appear in the organizational Active
Directory.
Type String
Description The customer's auditor group in the Active Directory. Use the
Distinguished Name format.
Valid values Specify these details exactly as they appear in the organizational Active
Directory.
Parameter useSecureConnection
Type boolean
Valid values true/false
Default true
radiusDetails
Type String
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.
Type Integer
Type String
Valid values RADIUS secret
Disable Customer
This method disables a specific customer in 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.
The following characters are not supported in URL values: + & %
https://<IIS_Server_Ip>/PasswordVault/msp/api/customers/
{CustomerUniqueID}/disable
Type String
Resource Information
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
{
}
Result
{
}
List Customers
This method returns a list of the customers in the MSSP environment.
The user who runs this web service requires the following permission in the Vault:
■ Audit users
URL
Note:
Make sure there are no spaces in the URL.
The following characters are not supported in URL values: + & %
https://<IIS_Server_Ip>/PasswordVault/msp/api/Customers?offset=
{number of results to skip}&limit={number of results to take}
Type String
Parameter limit
Type String
Resource Information
HTTP method GET
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.
Result
{
[
{
"Name":"<customer>",
"UniqueID":"<ID>",
"Logo":"[image-encoded-as-base64]",
"SupportedServices":["<service>","<service>"],
"Status":"<status>"
},
{
"Name":"<customer>,
"UniqueID":"<ID>",
"Logo":"[image-encoded-as-base64]",
"SupportedServices":["<service>","<service>"],
"Status":"<status>"
},
...
]
}
Parameter Name
Type String
Parameter UniqueID
Type String
Parameter Logo
Type String
Parameter SupportedServices
Type StringArray
Parameter Status
Type StringArray
URL
Note:
Make sure there are no spaces in the URL.
The following characters are not supported in URL values: + & %
https://<IIS_Server_Ip>/PasswordVault/msp/api/customers/{CustomerUniqueID}
Type String
Resource Information
HTTP method GET
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.
Result
{
"Name":"<customer>",
"UniqueID":"<ID>",
"ContactName":"<name>",
"ContactEmail":"<email>",
"Logo":"[image-encoded-as-base64]",
"SupportedServices":["<service>","<service>"],
"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
Parameter UniqueID
Type String
Parameter ContactName
Type String
Parameter ContactEmail
Type String
Description The email of the customer's contact person for MSSP (customer admin).
Parameter Logo
Type String
Parameter SupportedServices
Type StringArray
LdapDetails
Parameter Address
Type String
Parameter DomainName
Type String
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
URL
Note:
Make sure there are no spaces in the URL.
https://<IIS_Server_Ip>/PasswordVault/api/RadiusDetails
Resource Information
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
{
"TenantId": "<tenant>",
"Address":"<x.x.x.x>",
"Port":"<port>",
"Hostname":"<hostname>",
"Secret":"<secret>"
}
Type String
Type String
Valid values IPv4 or IPv6 (IPv6 should be supported only when Vault will support IPv6)
Type Integer
Parameter Hostname
Type String
Type String
Return Codes
Status code 400
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
Account Security Implementation Guide.
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 …
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.
List accounts View Account lists. Users who have this authorization can do
the following:
■ View the Accounts or Files list.
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.
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
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:
Move accounts/ Move accounts and folders in the Safe to different folders and
folders subfolders.
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.
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.
Troubleshooting
Appendices
Daily Activities
The following table lists the responsibilities of the MSSP administrator and Customer
administrator.
MSSP Customer
Category Activity
admin admin
Recordings No Yes
Administration Yes No
MSSP Customer
Category Activity
admin admin
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:
Specify Applications
The following CyberArk applications can be specified in a user credentials file:
Application ID
Unix
Parameter Specifies
Command
Unix
Parameter Specifies
Command
/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.
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”.
Unix
Parameter Specifies
Command
Unix
Parameter Specifies
Command
Unix
Parameter Specifies
Command
Unix
Parameter Specifies
Command
Note:
The text typed by the user appears in bold.
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.
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
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.
Note:
A PIN to access a PKI certificate can only be used in a Windows 2000 environment or
higher.
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.
Example:
>createcredfile.exe user.cred Proxy /ProxyUser PUser
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.
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.
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 properties
■ 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.
CPMUserAdminRights=yes
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:
Parameter Description
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.
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.
Parameter Description
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.
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.
UpdateIfExists=Yes
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.
Parameter Description
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.
Parameters
Vault
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.
Port
Timeout
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.
Default Value 3
AuthType
NTAuthAgentName
NTAuthAgentKeyFile
VaultDN
ProxyType
ProxyAddress
Description The proxy server IP address. This is mandatory when using a proxy
server.
ProxyPort
Parameters
ProxyUser
ProxyPassword
ProxyAuthDomain
Description The domain for the Proxy server if NTLM authentication is required.
BehindFirewall
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
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
Default Value No
TrustSSC
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.
CTLFileName
AllowSSCFor3PartyAuth
Description Whether or not self-signed certificates are allowed for 3rd party
authentication (eg, RADIUS).
Parameters
Default Value No
CIFSGateway
HTTPGatewayAddress
DistributedVaults
Default Value No
FailbackInterval
Description The number of seconds between client requests to check the SRV
record.