Pam Admin Exercise Guide Ilt

CyberArk University
Privileged Access Management Administration
Exercise Guide
CyberArk University Exercise Guide page 1
3/15/2022
© Cyber-Ark® Software Ltd - No part of this material may be disclosed to any person or firm or reproduced by any means, electronic
and mechanical, without the express prior written permission of Cyber-Ark® Software Ltd.
Contents
CONTENTS ............................................................................................................................................................. 2
INTRODUCTION ..................................................................................................................................................... 8
USING SKYTAP...............................................................................................................................................................8
INTERNATIONAL USERS .................................................................................................................................................10
INTRODUCTION TO CYBERARK PRIVILEGED ACCESS MANAGEMENT .................................................................... 13
GETTING TO KNOW THE ACME.CORP ENVIRONMENT...........................................................................................................13

Acme Servers ......................................................................................................................................................14
GETTING TO KNOW CYBERARK PAM ...............................................................................................................................15
LOG INTO THE COMPONENTS SERVER ...............................................................................................................................16
PVWA ......................................................................................................................................................................18
Log in as Mike ....................................................................................................................................................18
Activate the PSM ................................................................................................................................................20
Deactivate “Reason for Access” .........................................................................................................................21
Connect to an Account in the New UI .................................................................................................................22
Retrieve a Password in the Classic UI .................................................................................................................24
PRIVATEARK CLIENT .....................................................................................................................................................27
Connecting .........................................................................................................................................................27
Accessing a File in a Safe ....................................................................................................................................29
Modifying the View ............................................................................................................................................31
REMOTE CONTROL CLIENT .............................................................................................................................................31
THE VAULT SERVER ......................................................................................................................................................33
USER MANAGEMENT ........................................................................................................................................... 38
KNOW THE PLAYERS .....................................................................................................................................................38

LDAP INTEGRATION AND DIRECTORY MAPPING ................................................................................................................38
Review LDAP Integration and pre-defined Directory Mappings .........................................................................39
Test the LDAP Integration and Pre-defined Mappings .......................................................................................45
Configure Custom Directory Mapping ................................................................................................................45
Test Custom Directory Mapping .........................................................................................................................48
UNSUSPEND A SUSPENDED USER .....................................................................................................................................53
LOG IN WITH MASTER ...................................................................................................................................................56
SECURING WINDOWS DOMAIN ACCOUNTS ......................................................................................................... 57
PLATFORM MANAGEMENT ............................................................................................................................................57

Duplicating a Platform .......................................................................................................................................57
Configure Password Management .....................................................................................................................59
Editing the Master Policy ...................................................................................................................................62
SAFE MANAGEMENT ....................................................................................................................................................65
3/15/2022
Creating a Safe ...................................................................................................................................................65
Add Safe Members .............................................................................................................................................67
ACCOUNT MANAGEMENT..............................................................................................................................................70
Add the reconcile account ..................................................................................................................................70
Add the accounts discovery account ..................................................................................................................74
SECURING UNIX SSH ACCOUNTS .......................................................................................................................... 75
VAULT ADMINISTRATOR TASKS – MIKE ............................................................................................................................75

Duplicating a Unix Platform ...............................................................................................................................75
Configuring the Master Policy ............................................................................................................................78
SAFE MANAGER TASKS – PAUL.......................................................................................................................................79
Creating a Safe ...................................................................................................................................................79
Add Safe Members .............................................................................................................................................80
ADDING A LINUX ACCOUNT ............................................................................................................................................82
Test the New Account as Safe Manager ............................................................................................................86
Test the New Account as a Normal End User .....................................................................................................89
AUDITOR TASKS...........................................................................................................................................................90
SECURING ORACLE DATABASE ACCOUNTS ........................................................................................................... 93
VAULT ADMINISTRATOR TASKS .......................................................................................................................................93

Duplicating a Platform .......................................................................................................................................93
SAFE MANAGER TASKS .................................................................................................................................................94
Creating a Safe ...................................................................................................................................................95
Adding an Account .............................................................................................................................................95
LINKED ACCOUNTS .............................................................................................................................................. 98
SECURING SSH ACCOUNTS USING A LOGON ACCOUNT........................................................................................................98

SECURING WINDOWS SERVER LOCAL ACCOUNTS VIA A RECONCILE ACCOUNT ........................................................................101
Vault Administrator Tasks ................................................................................................................................101
Safe Manager Tasks .........................................................................................................................................104
SECURING UNIX ACCOUNTS WITH SSH KEYS ...................................................................................................... 108
GENERATING A KEY-PAIR.............................................................................................................................................108
VERIFY YOU CAN LOGIN WITH THE PRIVATE KEY................................................................................................................113
DUPLICATING A PLATFORM – VAULT ADMINISTRATOR TASK ...............................................................................................115
ADD AN ACCOUNT WITH AN SSH KEY – SAFE MANAGER TASK............................................................................................116
DEPENDENTS – SECURING SERVICE ACCOUNTS / USAGES ................................................................................. 119
MANAGING A SCHEDULED TASK USAGE .........................................................................................................................119

MANAGING A CONFIGURATION FILE USAGE ....................................................................................................................124
Create a Logon account ...................................................................................................................................125
Configure Usages on the Oracle platform ........................................................................................................126
Add the Usage to the target account ...............................................................................................................127
3/15/2022
PRIVILEGED ACCESS WORKFLOWS ..................................................................................................................... 133
REQUIRE USERS TO SPECIFY REASON FOR ACCESS ..............................................................................................................133

Activating the Policy .........................................................................................................................................133
Add Predefined Reasons for Access ..................................................................................................................134
Testing Predefined Reasons for Access ............................................................................................................136
REQUIRE DUAL CONTROL ACCESS APPROVAL ....................................................................................................................137
Activating the Policy .........................................................................................................................................137
Adding an approver to a Safe ...........................................................................................................................139
Testing Dual Control .........................................................................................................................................141
EXCLUSIVE PASSWORDS WITH AUTOMATED RELEASE AND ONE-TIME USE ............................................................................145
Adding a Master Policy exception for Exclusive Passwords .............................................................................145
Adding a Master Policy exception for One-Time Passwords ............................................................................147
Reducing the Minimum Validity Period ............................................................................................................147
Testing Exclusive Passwords.............................................................................................................................148
Testing Automatic release by PSM ...................................................................................................................150
DISCOVERY AND ONBOARDING ......................................................................................................................... 153
ACCOUNTS FEED ........................................................................................................................................................153

Configure Automatic Onboarding Rules ...........................................................................................................153
Configure and Run Windows Accounts Discovery ............................................................................................157
Manually onboard discovered accounts...........................................................................................................163
ADD MULTIPLE ACCOUNTS FROM FILE ...........................................................................................................................166
PRIVILEGED SESSION MANAGEMENT – PART 1 .................................................................................................. 170
Remove Privileged Access Workflows Exceptions ............................................................................................170

Disabling the PSM Globally ..............................................................................................................................172
PRIVILEGED SESSION MANAGER....................................................................................................................................172
Adding Exceptions ............................................................................................................................................172
Connect with a Linux Account ..........................................................................................................................174
Connect with an Oracle Account ......................................................................................................................175
Connect via HTML5 Gateway ...........................................................................................................................175
Connect using PSM Ad-Hoc Connection ...........................................................................................................180
PRIVILEGED SESSION MANAGER FOR WINDOWS ..............................................................................................................183
Connect using RDP file without providing the target system details: ..............................................................183
Connect using RDP file with the target system details .....................................................................................186
PRIVILEGED SESSION MANAGER FOR SSH .......................................................................................................................187
PRIVILEGED SESSION MANAGEMENT – PART 2 .................................................................................................. 190
PSM SESSION TERMINATORS .......................................................................................................................................190

MONITOR, SUSPEND, AND TERMINATE ACTIVE SESSIONS ..................................................................................................190
MONITOR RECORDINGS ..............................................................................................................................................192
PRIVILEGED THREAT ANALYTICS ........................................................................................................................ 194
3/15/2022
DETECTIONS AND AUTOMATIC REMEDIATION FOR UNIX/LINUX..........................................................................................195
Unmanaged Privileged Access .........................................................................................................................195
Suspected Credential Theft and Automatic Password Rotation .......................................................................198
Suspicious Password Change and Automatic Reconciliation ...........................................................................201
Suspicious Activities in a Session and Automatic Suspension...........................................................................203
Security Rules Exceptions .................................................................................................................................206
DETECTIONS AND AUTOMATIC REMEDIATION FOR WINDOWS ............................................................................................207
Unmanaged Privileged Access .........................................................................................................................207
Suspicious Activities in a Windows Session and Automatic Suspension ...........................................................212
CONNECT TO THE PTA ADMINISTRATION INTERFACE ........................................................................................................215
REPORTS ............................................................................................................................................................ 217
GENERATE “PRIVILEGED ACCOUNTS INVENTORY” REPORT..................................................................................................217

GENERATE “SAFES LIST” REPORT AND “USERS LIST” REPORT..............................................................................................219
GENERATE REPORTS USING EVD ...................................................................................................................................222
Enable the Auditor user ....................................................................................................................................222
Create the Cred file ...........................................................................................................................................224
Export Vault Data .............................................................................................................................................225
BACKUP AND RESTORE ...................................................................................................................................... 227
CONFIGURE THE CYBERARK REPLICATOR UTILITY..............................................................................................................227

Configure the Vault.ini file ...............................................................................................................................227
Locate the output directory – tsparm.ini..........................................................................................................228
Create the credential file – backup.cred...........................................................................................................228
RUN A BACKUP ..........................................................................................................................................................229
DELETE THE TEST SAFE ...............................................................................................................................................230
RUN A RESTORE.........................................................................................................................................................231
DISASTER RECOVERY.......................................................................................................................................... 233
STEP 1: ENABLE AUTOMATIC FAILOVER ON THE DR VAULT ................................................................................................233

STEP 2: EXECUTE A FULL REPLICATION TO THE DR VAULT ...................................................................................................235
STEP 3: EXECUTE AUTOMATIC FAILOVER TEST .................................................................................................................237
Confirm Automatic Failover on the DR Vault ...................................................................................................238
Confirm Automatic Failover of PVWA and PSM ...............................................................................................239
STEP 4: EXECUTE A FULL REPLICATION BACK TO THE PRIMARY VAULT ...................................................................................240
STEP 5: EXECUTE FAILBACK PROCEDURE BY USING MANUAL FAILOVER .................................................................................243
Confirm Manual Failover on the Primary Vault ...............................................................................................244
STEP 6: SET THE DR SERVER BACK TO DR MODE ..............................................................................................................245
Confirm Automatic Failover for PVWA and PSM ..............................................................................................247
COMMON ADMINISTRATIVE TASKS ................................................................................................................... 249
ROTATING CPM LOGS ................................................................................................................................................249
3/15/2022
OPTIONAL EXERCISES ......................................................................................................................................... 252
JUST-IN-TIME (JIT) ACCESS .........................................................................................................................................252

Set up the JIT Access Platform ..........................................................................................................................253
Add the Local Administrator Account ..............................................................................................................255
Test Just-in-Time Access ...................................................................................................................................256
CUSTOM FILE CATEGORIES...........................................................................................................................................259
Creating the Custom File Category ...................................................................................................................259
Adding the Custom File Category to the Platform ............................................................................................261
Making the File Category Searchable...............................................................................................................261
Testing the New File Category .........................................................................................................................262
3/15/2022
3/15/2022
CyberArk Privileged Access Management 12.2 – Administration
Introduction
Using Skytap
Before beginning the exercises, here are a few tips to help you navigate the labs more
effectively. You can refer to the section for International Users for instructions on
changing the keyboard.
The virtual machines need to be running for you to be able to do the exercises. You can
start all the virtual machines with one click by pressing the start button (there are two).
The buttons are highlighted in red in the image below.
Note: The number and names of virtual machines vary by course. The image above is
given as an example and might not match exactly what you see.
The environments have been set up to start up gradually: first the domain controller, then
the Vault, and so on. It will take a few minutes for them to get up and running. Also note,
that some machines are designed not to start automatically. This is the case of the
PTAServer and DR in the image above. These servers are not needed until later in the
course, so you can start them when instructed in the manual or by the CyberArk trainer.
Occasionally, for reasons outside our control, one or more machines may fail to start up
when requested. If you notice that a particular machine is not responding to a ping or if
you cannot log in using Active Directory, you should check your virtual machines to make
sure they are all running properly.
3/15/2022
Click on the large monitor icon to connect to a virtual machine with the HTML 5 client.
Use the Ctrl-Alt-Del button on the tool bar to send a Ctrl-Alt-Del to the machine.
The clipboard icon will allow you to copy and paste text between your computer and
your lab machine. Do NOT copy and paste from this PDF into the CyberArk PAM
tool. It will not work.
The full screen icon will resize your virtual screen to adapt to your computer’s screen
settings to avoid scrolling.
3/15/2022
You may need to adjust your bandwidth setting on slower connections.
International Users
By default, the lab machines are configured to use a US English keyboard layout. If you
use a machine from a country other than the US, you may experience odd behavior from
your lab machines. The solution is to install the keyboard layout for your keyboard on our
lab machines. Follow the process below to find and configure the correct keyboard layout
for your keyboard.
From the Start Menu, go to Settings -> Time & Language -> Language -> Add a
language.
3/15/2022
Select your language. Click Next. You can uncheck the options for voice and
handwriting and then click Install.
3/15/2022
Note: If you use an alternate keyboard layout (e.g., AZERTY, Dvorak), you can click
options next to your language to install that. Otherwise, close the Language
window.
In the system tray, click ENG, then choose your keyboard layout. You may switch
back and forth between keyboard layouts. Your instructor may need to switch back
to ENG to help you with exercises, so do not uninstall any language options.
3/15/2022
Introduction to CyberArk Privileged Access Management

Welcome to CyberArk Privileged Access Manager (PAM) Administration training. The
purpose of this training is to introduce CyberArk’s Privileged Access Management (PAM)
solution. Specifically, this training focuses on the Privilege On-premises solution. As the
focus of this training is on the administration of the solution, everything has already been
installed. The scenario is that the implementation team has done its job and it is now up to
the system administrators (that is, us) to take ownership of CyberArk PAM and configure
it according to the organization’s requirements.
Getting to Know the acme.corp Environment
For the purposes of the training, we have created an IT environment for the fictitious
company Acme Corporation. The domain name is acme.corp.
Our environment consists of a total of 8 virtual servers. Some host CyberArk

components, such as the Vault; some are IT infrastructure, such as the Acme domain
controller; and finally, others have nothing to do with either CyberArk or the IT
environment and are what we call the target servers, such as servers hosting Acme
human resources applications or financial information.
3/15/2022
The goal is to provide trainees with an environment that resembles as closely as possible
an actual production environment. As such, there is a domain with Active Directory, an
email server, a certification authority for PKI authentication, and so on. Our goal is to
integrate CyberArk PAM in this corporate environment and to bring the principal privileged
accounts under CyberArk control.
Acme Servers
The table below lists the various servers, their roles, and configuration. The lines shaded
blue represent servers hosting CyberArk services.
Host name IP Address Operating system Role
dc01 10.0.0.1 Windows 2019 Domain controller

Server Active Directory
Email server
components 10.0.20.1 Windows 2019 CyberArk component server

Server hosting:
• PVWA
• CPM
• PSM
• Admin workstation
psm-ssh-gw 10.0.30.1 CentOS Linux 7 CyberArk server hosting:

• PSM for SSH
• PSM HTML5 Gateway
ptaserver 10.0.30.2 CentOS Linux 7 CyberArk Privileged Threat

Analytics
vault01a 10.0.10.1 Windows 2016 CyberArk Vault and the

Server Disaster Recovery Module
DR 10.0.14.1 Windows 2016 CyberArk Vault and the

Server Disaster Recovery Module
target-win 10.0.21.1 Windows 2019 Target Windows server

Server
target-lin 10.0.0.20 CentOS Linux 6.5 Target Linux server
3/15/2022
We will do most of our work on the server Components, also known as the Component
server. As indicated above, the Component server runs most of the CyberArk component
services. For convenience, it also serves as the workstation for the Vault administrator.
All the servers (except for the ptaserver and DR) are configured to start automatically
when the general power-on button is clicked in Skytap. Obviously, for CyberArk PAM to
work properly, the servers need to be running. So, if you run into problems connecting to
the PVWA or opening a PSM session to a Linux machine, the first thing to do is to check
that all the machines and the corresponding services are running.
Reminder: Make sure that you start the virtual machines using one of the global start buttons,
as shown in the image below.
Because we won’t need them immediately, we will start up the ptaserver and DR
manually later in the course.
Getting to know CyberArk PAM
In this first exercise, we will perform a few basic tasks to start to familiarize ourselves with
the various CyberArk PAM tools and interfaces. We will:
• Log into the Components server, which will also serve as our workstation.
• Log into Password Vault Web Access (PVWA)
• Connect via PrivateArk Client
• Connect via Remote Control Client
3/15/2022
• Vault Server Central Administration
All actions should be performed on the Components server unless otherwise indicated.
Note: For the sake of convenience, we use the Components server in this training as our
workstation. It is important to note, however, that this is something you would never
do in the real world. As the host of sensitive CyberArk services, your component
servers must be placed under CyberArk control, with their passwords stored
securely in the Vault and accessed only through the Privileged Session Manager.
Log into the Components server
First, we need to log into Windows. As already mentioned, we are going to use the
Components server as our workstation. The account we will use is Mike, an Active
Directory user who has been given the responsibility for configuring and maintaining the
CyberArk PAM solution in Acme.
Make sure that you have started the virtual machines using one of the global start
buttons, as shown in the image below.
Note: Make sure all the VMs (except for PTA and DR) are running before proceeding to
the next step.
In Skytap, click on the screen for the 02 – components virtual machine. This will
open a browser window with the machine’s login screen.
3/15/2022
Click the Ctrl-Alt-Del button in the Skytap toolbar at the top of the window to bring up
the login dialog. You can also use the keyboard combination Ctrl+Alt-End to send
Ctrl+Alt+Delete.
Enter mike as the username and Cyberark1 as the password. Remember, the
machines use the US English keyboard as the default, so you may have to adjust the
keys you use. When you are finished, hit Enter to log in.
3/15/2022
And you should find yourself logged into the Components server with the Active
Directory credentials of Mike, the CyberArk Vault Administrator.
PVWA
In this section, we will perform some basic operations using the Password Vault Web
Access, or PVWA. We will:
• Log in as Mike, our CyberArk Vault Administrator

• Activate the PSM
• Deactivate “Reason for Access”
• Launch a PSM connection in the New UI
• Retrieve a password in the Classic UI
Log in as Mike
On the Components server, launch a browser using one of the shortcuts in the
taskbar at the bottom of the screen. You should arrive directly on the login screen for
the PVWA.
3/15/2022
Note: The screenshots in this guide have been made using the Chrome browser, which
works very well and is probably the fastest.
There are currently two authentication methods available to us: CyberArk and
LDAP. LDAP integration has already been performed by the installation team, so we
can connect with the Active Directory credentials of our CyberArk Vault Administrator
Mike. Click on the LDAP icon.
Enter the username Mike and password Cyberark1 and then hit Enter or click Sign
In.
3/15/2022
By default, you will be in the Accounts View, which provides access to all the
privileged accounts in the Safes of which you are a member. There are not many
accounts at the moment. It will be our job to add them.
Activate the PSM
As you can see in the image above, the Connect buttons are greyed out. The reason for
this is that the PSM has not yet been activated (this is the default value), we will activate it
now.
To activate the PSM, we will need to modify the Master Policy. Click on the
Policies tab.
3/15/2022
In the Master Policy, open the Session Management section, select Require
privileged session monitoring and isolation, and then click the pencil icon in the upper
right-hand corner.
Toggle the value from Inactive to Active and then click the diskette icon to save the
change.
Deactivate “Reason for Access”
While we are here, we can make our lives easier by deactivating the option Require users
to specify a reason for access, which can be found in the Privileged Access
Workflows section at the top. That way we will not be required to enter in a reason every
time we want to test a newly created account.
3/15/2022
Select the policy, click the pencil icon, toggle the value from Active to Inactive, and then
click the diskette icon to save your changes.
Connect to an Account in the New UI
Now we will test using a password from the Vault to connect to a target device using a test
account.
Go back to Accounts View by clicking on the tab along the left-hand side of the
screen (second from the top) and then click again on the root10 account. You should
now see that the Connect button is enabled.
Click on Connect.
Depending on the browser you are using, the PSM server will send an RDP file. In
Chrome, it is downloaded to the local machine and appears in the lower left-hand
corner of the screen.
Click on the RDP file to launch the connection. You may be prompted to allow the
RemoteApp program to run. If you are, you can check the box “Don’t ask me
again…” and click Connect.
3/15/2022
Note: If it is the first time the currently logged in user (in this case Mike) connects to the
target server, you will be prompted to accept the server’s key. You must accept the
key.
You will see a banner telling you that your session is being recorded by the
Privileged Session Manager (this will eventually disappear) and then see a PuTTY
window with the SSH connection to the machine target-lin with the username root10.
3/15/2022
Note: The password for this user was retrieved by the PSM from the Vault and inserted
into the PuTTY session at the time of connection. At no time did the password
appear on the user machine.
Enter “exit” (without the quotes) into the SSH session and hit Enter to close the
session. This closes the SSH session and the RDP connection.
Retrieve a Password in the Classic UI
CyberArk introduced a new user interface beginning with version 10. There is, however,
still some functionality that can only be accessed through the old interface, or Classic UI,
so we will now look at how to access this user interface.
In this section, we will use another method to retrieve the password for root10 by using the
Show button in the classic interface.
Back in the PVWA, you should still see the details for the account root10. In the
upper right-hand corner of the Accounts View you will see a link to the Classic
interface. Click the link.
3/15/2022
Here, you are looking at the Account Details for root10 in the Classic interface.
Notice that we are still in the new interface: You still have access to the tabs along
the left-hand side. Now click the Show button.
We can now see the password that is currently stored in the Vault for the account
root10.
3/15/2022
As a last step, click the Change button at the top of the Account Details view. You
are presented with three options. The first option – Change the password
immediately (by the CPM) – is available in both the Classic and the new interface.
The third option – Change the password only in the Vault – is also available in the
new UI. The second option is for the moment only available in the Classic interface.
Click OK to change the password immediately.
Now hover the mouse over the Accounts tab on the left-hand side and select
Accounts View. This will bring us back to the new interface. Click on the root10
account again and after a few minutes, you should see that the password has been
changed by the user PasswordManager (in other words, the CPM). Press refresh
until you see the password has been changed.
3/15/2022
Close the PVWA.
PrivateArk Client
In this section, we will see how to perform a basic file retrieval using the PrivateArk
Client. The file we are going to retrieve is italog.log, the Vault’s main log file.
Connecting
In the Windows taskbar, click on the shortcut to launch the PrivateArk Client.
Now double-click on the link named Primary Vault. You can configure multiple Vault
connections here: Primary, Disaster Recovery, etc.
Note: You will notice you have two servers configured: Primary Vault and DR Vault.
When you are requested in this guide to connect using the PrivateArk Client,
always use the Primary Vault, unless stated otherwise.
3/15/2022
Enter the username and password for the internal CyberArk Administrator user
(password is Cyberark1).
Note: It is not possible to be connected to the CyberArk solution via both interfaces at the
same time, using the same user. If you have not logged out of your session on the
PVWA, logging into the PrivateArk Client with the same user will terminate your
session. The reverse, however, is not true: if you leave your PrivateArk Client
session open and try to log into the PVWA with the same user, you will not be able
to.
3/15/2022
Accessing a File in a Safe
Now we are in the main window looking at the Safes to which the current user has
access. The Safe we are interested in is the System Safe. Double-click in it to open
it and “step into” the Safe.
You may receive a message asking if you want to clear expired Safe history. Click
Yes.
The file we want to view is italog.log. We are not going to modify the file, so right-
click on it and select Retrieve for Read-Only.
3/15/2022
The file is extracted from the Safe and displayed. Take a moment to view some of
the log messages and then close the file.
To indicate to the Vault that we are finished with the file, right-click on it again and
select Return to Safe.
3/15/2022
Modifying the View
You can change how you view the Safes by going to the View menu.
Click the Up button to navigate back to the top of the Safes and click View and then
Large Icons.
Notice that the System Safe is still open. You can either use the Logoff button or
simply close the PrivateArk Client. Both will close the Safe and terminate your
session.
Remote Control Client
We are now going to execute a few simple commands using the Remote Control Client,
a command-line tool for performing remote administration on the Vault.
3/15/2022
On the Components server, open a command-line window (either the classic

Windows command line or PowerShell – there are short-cuts in the Task bar) and
change directory to:
C:\Remote Control Client
To start the Remote Control Client, run the following command (highlighted in
yellow below):
C:\Remote Control Client\PARClient.exe 10.0.10.1/Cyberark1
Cyber-Ark Remote Administration Client (12.2.70.0)
Working with agent on: 10.0.10.1
Loaded component from [C:\Remote Control Client\PARClusterVaultClient.dll]

Loaded component from [C:\Remoteexit Control Client\PARDRClient.dll]
Loaded component from [C:\Remote Control Client\PARENEClient.dll]
Loaded component from [C:\ Remote Control Client\PARVaultClient.dll]
PARCLIENT>
Note: The connection string is made up of the executable, the Vault address (here its IP
address), and the password for the Remote Control Client that was set during
installation. This password cannot be managed by the Vault and so must be
managed manually.
Once you have the PARCLIENT prompt, get the current Vault status by running:
PARCLIENT> status vault

Vault is running.
Note: Depending on how long after logging in you wait to run the command, you may be
prompted to re-enter the password.
To stop the Vault, run the following:
PARCLIENT> stop vault

Are you sure you want to stop the remote Vault (Y/N)? y
Password:*********
Vault was stopped successfully
To restart the Vault, run the following:
PARCLIENT> start vault
3/15/2022
Password:*********
Vault was started, pending service running. use status command for further
details.
When you stop the Vault, the Event Notification Engine, or ENE, is also stopped
because it is dependent on the Vault service. However, when you start the Vault,
the ENE is not automatically restarted. You must restart it manually by running:
PARCLIENT> start ene

Password:*********
ENE was started, pending service running. use status command for further details
As a final step, check the status on these two Vault services by running:
PARCLIENT> status ene

ENE is running.
PARCLIENT> status vault
Vault is running.
Type exit and hit enter to exit the PrivateArk Remote Control Client.
The Vault Server
In the last section for this first chapter, we will see how to stop and restart the Vault
service directly on the Vault.
To do this, we will need to switch in Skytap from the Component server to the Vault
server.
1. Log in with the local administrator account: Username administrator, password

Cyberark1. You will receive an authorization warning message.
3/15/2022
On the desktop of the Vault server, you will find two CyberArk icons:
• PrivateArk Server
• PrivateArk Client
Double-click on the PrivateArk Server shortcut.
You will receive a User Account Control alert. Click Yes to allow the action.
3/15/2022
The main function of the Server Central Administration tool is to view the italog.log
file and to stop and restart the Vault. Click on the red traffic light icon to stop the
Vault service.
You will be prompted for the type of shutdown. Choose Normal shutdown and click
OK.
3/15/2022
You will be asked to confirm Vault shutdown. Click Yes to shut down the Vault.
You will see the messages indicating the shutdown procedure ending with the
message: ITAFW002I Firewall is closed to client communication.
To restart the Vault service, click on the green traffic light icon.
You will see several messages indicating that the Vault is starting up.
3/15/2022
As was the case with the Remote Control Client, starting the Vault in the Server
Central Administration tool does not restart the Cyber-Ark Event Notification
Engine (as it is listed in the local services). The ENE is essential for the Vault to
send emails and alerts, so you will have to start it by going into the Services tool on
the Vault server and starting the service there. You will find a shortcut in the taskbar
on the Vault desktop.
3/15/2022
User Management
Know the Players
Before we begin, let's first get to know the different users we will be using throughout this
lab and their roles. The password for all these users is Cyberark1.
Username Auth Method CyberArk Role LDAP Group
Administrator CYBERARK Vault Admin -
Master CYBERARK Master User -
CyberArk Team (AD)
Mike LDAP Vault Admin CyberArk Vault Admins
Cindy LDAP Auditor CyberArk Auditors
Dexter LDAP User Manager (custom) CyberArk Help Desk
Linux Team
Paul LDAP Safe Manager CyberArk Safe Managers
Carlos LDAP User LinuxAdmins
Windows Team
Tom LDAP Safe Manager CyberArk Safe Managers
John LDAP User WindowsAdmins
Oracle Team
Robert LDAP Safe Manager CyberArk Safe Managers
LDAP Integration and Directory Mapping
In this first section we will review the LDAP integration with CyberArk PAM and the
predefined directory mapping to four common CyberArk roles.
LDAP integration is a two-step process:
3/15/2022
1. Create the connection to the LDAP server, which in our case is Active Directory.
2. Create the directory mappings between the AD groups and the built-in CyberArk
roles.
The above steps have already been completed by the implementation team. We will now
review the predefined directory mappings and examine the authorizations assigned to four
common CyberArk roles. Because this defines how CyberArk interacts with LDAP, an
LDAP user cannot perform this task, so we will be using the built-in CyberArk administrator
account.
Review LDAP Integration and pre-defined Directory Mappings
Launch a browser to open the PVWA page and click on CYBERARK.
3/15/2022
Enter the credentials: Username: administrator, password: Cyberark1.
Along the left side of the window, you will find the navigation tabs. The User
Provisioning tab is the next to last one. Click the down arrow and select LDAP
Integration.
Click on acme.corp and note that CyberArk PAM has been integrated with the
domain and that four directory mappings have been defined.
3/15/2022
As you can see, there are four AD groups and each group is mapped to a CyberArk
role as shown in the table below.
CyberArk Role LDAP Group
Vault Admins CyberArk Vault Admins
Safe Managers CyberArk Safe Managers
Auditors CyberArk Auditors
Users CyberArk Users
Click on the Vault admins mapping to expand it.
In the Details tab you can see the mapping criteria, the mapping destination in the
Vault, the authentication method the mapped users will use to authenticate to
CyberArk, and how many days user activity logs are kept.
3/15/2022
Note: In the above example we can see that users who belong to the AD group CyberArk
Vault Admins are mapped to this role, and that the authentication method they will
use is LDAP.
To know what Vault authorizations are assigned to the mapped users, click on the
Vault authorizations tab.
3/15/2022
Here we can see that users who are mapped to the role of Vault admins will be
assigned with all Vault authorizations, except for Backup all safes and Restore all
safes. In other words, members of the AD group CyberArk Vault Admins will be
assigned these Vault authorizations when they authenticate to CyberArk for the first
time. When you are ready, click on the Edit button.
Note you can now edit all the settings we reviewed in the Details page as well as edit
the Vault authorizations that are assigned to users who meet the search criteria.
3/15/2022
Scroll down to Mapping Criteria and click on View users.
Here we can review which LDAP users currently meet the mapping criteria and will
be assigned the Vault admin role when they are first created in CyberArk.
Note: In the above example we can see that Mike is the only user who meets the Mapping
Criteria. This means that when Mike authenticates to CyberArk for the first time,
his user will be created and assigned the Vault authorizations of a Vault admin
(which includes all Vault authorizations except for Backup all safes and Restore all
safes).
Repeat the above steps to review the details of the other three pre-defined
mappings: Safe Managers, Auditors and Users. Note the following for each mapping:
• What are the mapping criteria for this mapping?
• Which users currently meet the mapping criteria?
3/15/2022
• What Vault authorizations are assigned to users who meet the criteria?
Test the LDAP Integration and Pre-defined Mappings
Now that we can log into CyberArk PAM using Active Directory users, test the integration
by logging in with the following users (all have the password Cyberark1).
• Mike
• Cindy
• Paul
• Carlos
Take note of the differences in access to different PVWA panes and buttons.
Configure Custom Directory Mapping
In this section we will create a custom directory mapping for CyberArk Help Desk – a
group with the necessary Vault authorizations to manage users in CyberArk.
Login to the PVWA as administrator using CYBERARK authentication with the

password Cyberark1.
Navigate to User Provisioning -> LDAP Integration. This time select Add
Mapping.
In Map name enter Help Desk.
Click in the Map order section to update the display and move Help Desk to the
second position using the up and down arrows. Then click on Next.
3/15/2022
Note: The mapping order is important for users who belong to multiple
groups/mappings. For example, if a user belongs to both Help Desk and Vault
Admins mappings, the user will receive the privileges for the first mapping listed. If
Help Desk was listed first, a user who is also a help desk user would only receive
the help desk subset of Vault authorizations, instead of the full set provided by the
Vault Admins mapping.
Type ‘cyber’ and then select the Active Directory group CyberArk Help Desk under
LDAP group (once you begin typing the name should autocomplete itself). You may
click on View users to view the users the directory mapping will be applied to. Then
click on Next.
3/15/2022
Select the following Vault Authorizations: Activate Users, Audit Users, and Reset
Users’ Passwords then click on Next.
Verify your settings in the Summary page. If all is ok, click on Save.
Logoff the PVWA.
3/15/2022
Test Custom Directory Mapping
To test this custom mapping, we will log in to the PrivateArk Client as Dexter, who works
in the CyberArk Help Desk. The reason for using the PrivateArk Client is that user
management is still mostly handled in this interface. In this exercise we will also see how
to change the authentication method used in the PrivateArk Client.
Open the PrivateArk Client using the shortcut in the Windows task bar.
Right-click on the Primary Vault and select Properties.
Click on Advanced.
3/15/2022
Select LDAP authentication and then click on OK.
Click on OK again (no need to change the default username).
Double-click on the Primary Vault icon login. Enter Dexter as the username and
Cyberark1 as the password.
3/15/2022
Note: You should not see any Safes when logged in to the PrivateArk Client as Dexter.
Navigate to Tools -> Administrative Tools -> Users and groups.
You should be able to see all the users provisioned in the Vault, both internal users
and transparent users. You should also be able to see the newly added Dexter
transparent user.
Select Dexter to see the Vault authorizations granted to the user.
3/15/2022
Select another user, for example, Mike, and review the user’s Vault authorizations.
Then click on Trusted Net Areas…
3/15/2022
As you can see, the user is now active (there is no need to deactivate it). In the
event that Mike or any other user gets suspended, Dexter (or any other user of the
CyberArk Help Desk group) will now be able to re-activate the user using, by clicking
on Activate.
Click on Close and then log-off the PrivateArk Client.
When finished, change the default authentication method for the Primary server
back to PrivateArk authentication.
3/15/2022
Unsuspend a suspended user
In this exercise, you will provoke a user suspension by entering the incorrect password for
a user and then see how an administrator or a help desk user can unsuspend the user.
From the Components server, try to login via the PVWA as Carlos using a wrong
password. After 5 unsuccessful attempts the user should be suspended. You should
receive the below message on the 6th attempt.
3/15/2022
On the Components server, open the PrivateArk Client using the shortcut in the
Windows task bar.
Login either as Mike or Dexter (using LDAP authentication).
Locate the Carlos user. Click on Trusted Net Areas. Then click on Activate to
unsuspend Carlos.
The user should now appear as Active.
3/15/2022
Click on Close and then log off the PrivateArk Client.
Open the PVWA and try to login as Carlos, this time using the correct password
(Cyberark1). Verify you can now login as Carlos.
3/15/2022
Log in with Master
There are some cases where you will need to log in to the Vault with the Master user. This
can be in the event of an emergency or to give permissions to a user for a Safe when
there are no active users with the necessary permissions.
To use the Master user, the dbparm.ini file must point to the location of the Recovery
Private Key. By default, this is the CD-ROM drive of the server.
On the Vault server, open C:\Program Files (x86)\PrivateArk\Server\Conf\dbparm.ini.
Because we do not have a CD-ROM drive (we are using VMs for our lab exercises),
The RecoveryPrvKey parameter has been changed in the training environment to
point to the location of the file called recprv.key in the Master CD folder:
RecoveryPrvKey=”C:\CYBR_Files\Keys\Master CD\recprv.key”
Important: You don’t need to do anything here, but in a real environment, you would have to
retrieve the Master CD from a physical safe, load it into the Vault server, and only
then be able to connect to the Vault as Master.
Open the PrivateArk Client from the Vault server machine.
Delete the username Administrator and enter: Master. The password is Cyberark1.
These values were set during installation.
Question: How many safes are listed?
Log off the PrivateArk Client session and log in as Administrator
Question: How many safes are listed?
You should notice that there are more safes displayed when you are logged in as the
Master user.
3/15/2022
Securing Windows Domain Accounts

In this section, we will look at how to secure Windows domain accounts. We will begin
with accounts that are owned by the CyberArk Vault Administrators and that are used by
CyberArk PAM to perform CPM operations:
• A reconciliation account – cybrreconcile

• A discovery account – cybrscan
We will duplicate a Platform for these accounts, create relevant exceptions to the Master
Policy, create a Safe, add an Active Directory group as members of the Safe, and then
add the accounts to the Safe.
Platform Management
Duplicating a Platform
If you are not still logged in, connect to the PVWA using LDAP authentication with the
Vault Administrator account mike with the password Cyberark1.
Note: As earlier when you logged in as Administrator, you will arrive by default in the
Accounts View. Notice, however, that you do not see the same accounts. Each
user will only see the accounts that are in Safes to which he or she has been
granted access.
As shown in the image below, in the Toolbar along the left side of the page, click on
the down icon of the Administration menu to expand, then click on Platform
Management.
3/15/2022
Expand the Windows section to view the platforms there.
Select the Windows Domain Accounts platform and press the Duplicate button.
3/15/2022
Enter as the name WIN DOM ADM 15 (you can also give it a meaningful description)
and then press Create.
Configure Password Management
Select the WIN DOM ADM 15 platform and press the Edit button.
3/15/2022
Click on UI & Workflows and change AutoVerifyOnAdd from No to Yes.
Note: While not required, it is always a good idea to press the Apply button to make sure
your changes are saved (bottom right of the screen).
Note: This setting will prompt the CPM to automatically verify the password whenever a
new account assigned to this platform is added.
Go to Automatic Password Management -> General and change the value of

ImmediateInterval to 1.
Note: Changing the ImmediateInterval to 1 is only suitable for testing and should be left to
its default value.
3/15/2022
Still in Automatic Password Management -> General, enter the following into the
AllowedSafes parameter.
CyberArk-Service-Accounts|Win-Dom-
Warning! Do NOT copy and paste from the PDF file. It will probably not work. Make sure there
is no space in front of or behind the | symbol.
Note: This regular expression restricts the Safes to which this Platform can be applied to
only those Safes that start with the string “Win-Dom-” or the safe named “CyberArk-
Service-Accounts”. This field is case sensitive.
Press Apply.
Go to Password Change and set PerformPeriodicChange to Yes.
Go to Password Verification and set VFPerformPeriodicVerification to Yes.
Finally, go to Generate Password. Here, we are going to modify the password

length and complexity to give us more secure passwords for our domain admin
accounts. Set the values as follows:
PasswordLength 17
MinUpperCase 2
MinLowerCase 2
MinDigit 1
MinSpecial 1
3/15/2022
Note: The sum of the various complexity parameters must be less than or equal to
PasswordLength for password change to function. However, the system does not
check the values for you.
Press Apply and OK to save all your changes and close the Platform.
Note: Notice that some of the Platforms are Active while others are Inactive. It is best
practice in CyberArk PAM to deactivate all Platforms that are not being actively
used. Now that we have created our own Platform for Windows domain accounts,
we can deactivate the platform Windows Domain Account.
To deactivate a platform, select the platform, click on the ellipsis, and select
Deactivate.
Editing the Master Policy
In this section, you will modify the Master Policy to:
• Change passwords for all accounts every 60 days

• Create an exception for the Platform WIN DOM ADM 15 to rotate passwords every
15 days
Password Change Policy
To edit the Master Policy, click on Policies in the left-hand toolbar. By default, you
will land in the Master Policy. In the Password Management section, select
Require password change every X days and then in the Rule Preview area on the
right, click on the pencil icon to edit the default value of 90 days.
3/15/2022
Change the value to 60 and then click the diskette icon to save your change.
Add Exceptions
Let’s also add an exception for the Platform we created earlier – WIN DOM ADM 15 – so
that its passwords are changed every 15 days, rather than every 60 days.
Again, select the option Require password change every X days and click Add
Exception.
3/15/2022
Select the Platform WIN DOM ADM 15 and click Next.
Change the value from 60 to 15 and click Finish.
3/15/2022
You should now see an exception to the Master Policy.
Safe Management
In this section, we will create a Safe to store several accounts that are used by the Vault
Administrators to manage other privileged accounts in CyberArk PAM. Specifically, we
will store our reconcile account and our accounts discovery scan account.
Creating a Safe
In the left-hand toolbar, click on POLICIES -> Safes.
3/15/2022
Now click Create Safe.
Enter CyberArk-Service-Accounts as the Safe name. You can provide a

meaningful description. Leave the other values at their defaults and press Save.
Note: This Safe name must match exactly the name we put into the AllowedSafes
parameter for the platform we created a moment ago, which is case sensitive.
3/15/2022
Add Safe Members
On the Safe Details page, click the Add Member button to grant other users access
to this safe.
Enter “cyberark v” (without the quotes) in the Search field, leave Vault as the value in
the Search In field, and click Search.
3/15/2022
Select the group CyberArk Vault Admins, check all the boxes to give Vault
Administrators full rights on these CyberArk service accounts, and click the Add
button. Click Close when you are done.
3/15/2022
You will now see the group CyberArk Vault Admins listed in the Members.
Now add another CyberArk group to the Safe: CyberArk Safe Managers. In the
Access section, remove the permissions for Use accounts and Retrieve accounts,
leaving them only the List Accounts permission, as shown in the image below. We
will need this for a later exercise.
3/15/2022
Account Management
In this section, we are going to add two accounts from Active Directory to CyberArk PAS
beginning with our reconcile account.
Add the reconcile account
Please note that the account is named cybrreconcile (that is cybr, without the “e”).
Go to the ACCOUNTS tab and press the Add Account button.
3/15/2022
First select the System Type. Click on Windows
Next, select the Platform we created for domain accounts: WIN DOM ADM 15.
3/15/2022
Select the Safe we created: CyberArk-Service-Accounts.
Enter the following and then press Add:
Address: acme.corp
Username: cybrreconcile
Password (optional) Cyberark1
Confirm Password Cyberark1
Log On To <click on Resolve>
3/15/2022
Note: Because AutoVerifyOnAdd was set to Yes, the account will be scheduled for
immediate verification. In a minute or two, you should see that the account was
verified by PasswordManager.
3/15/2022
Select the newly created account from the list and then click on the link Additional
details & actions in classic interface to open the account in the classic interface.
Copy the Safe name and the Name values to Notepad (we’ll be using these values in
a later exercise). They should look something like this:
Add the accounts discovery account
We will need another Windows account for a later exercise – cybrscan. Add a second
Windows domain account using the information below.
Again, please note that it is CYBR (without the E).
Store in Safe: CyberArk-Service-Accounts

System Type: Windows
Platform Name: WIN DOM ADM 15
Address: acme.corp
User Name: cybrscan
Password: Cyberark1
Confirm Password: Cyberark1
Best Practice: After adding a new account, you should rotate the password so that only
CyberArk PAM knows the password. Go ahead and change the passwords for
both cybrreconcile and cybrscan.
3/15/2022
Securing Unix SSH Accounts

In this section, we will be managing a “Unix SSH” account or, to be more precise, a Linux
via SSH account.
In the previous section, we were managing what we could call “meta-accounts”: accounts
that are owned by the Vault Administrators and that are used by CyberArk PAM to
manage other accounts (which we will see later).
Here, we are dealing with a typical account. It is an account that is owned by an IT team
(in this case the Active Directory group LinuxAdmins) and as such our Vault Administrators
do not need to know the password or have access to it.
To achieve this, we are going to divide the tasks of configuring CyberArk PAM to manage
these accounts into separate phases and perform the actions by “changing hats”; that is,
logging into CyberArk PAM with different user accounts according to the table below:
Role Action User
Vault Administrator Configuring Platforms and setting Policies. Mike
Safe Manager Creating Safes, adding members, adding accounts. Paul
Auditor Verifying that accounts are being used according to Cindy

corporate policy.
Vault Administrator Tasks – Mike
Vault administrator tasks are handled by Mike, so use this account to login to the PVWA.
Duplicating a Unix Platform
Here you will create a Platform to manage Linux accounts that connect to their targets
with SSH.
Navigate to ADMINISTRATION -> Platform Management, expand the section *NIX

then UNIX via SSH, click on the three points at the end of the line and select
Duplicate.
3/15/2022
Enter LIN SSH 30 in the Name field and optionally something like Linux servers via
SSH, rotate passwords every 30 days for a description and then press Create.
Important! Although you are free (and encouraged) to apply your own naming conventions for
Platforms and Safes in your own environments, please note that we will be referring
to the names provided here in later exercises. If you choose to give your Platforms
and Safes with different names, it may prevent you from completing later exercises
successfully. We therefore recommend you use the names suggested in the guide.
Highlight the newly created platform and press Edit.
3/15/2022
Go Automatic Password Management -> General.
Change ImmediateInterval to 1
Note: Changing the ImmediateInterval field to 1 is only suitable for testing and should set
to 5 or higher in a real environment.
Change AllowedSafes to Lin- (case sensitive). This determines which safes can use
this platform.
Click Apply to save your changes, but do not exit the platform just yet.
3/15/2022
Now go to Password Change and change the value of the parameter

PerformPeriodicChange from No to Yes. This will enable the application of the
Master Policy rule Require password change every X days to accounts managed by
this platform.
Within the same window, go to Password Verification and change

VFPerformPeriodicVerification from No to Yes. This will allow the password to be
verified by the CPM automatically and without user intervention.
Finally, in Generate Password, note that the default password length for Unix
machines is 12 characters. This value can be changed to reflect your organization’s
requirements.
Note: Until recently, the default password length for *nix accounts in CyberArk PAM was
8. It has been increased to 12.
Click Apply and OK.
Note: As we have duplicated the Unix via SSH platform to a new platform, you can now
deactivate the Unix via SSH platform.
Configuring the Master Policy
Add an Exception for the New Platform
3/15/2022
We have already seen how to create a Master Policy exception. Create a new one for our
new Platform that rotates the passwords every 30 days.
Safe Manager Tasks – Paul
For this section, we will need to “change hats”; that is, we need to imagine that we are a
different user. We are no longer a Vault Administrator, but a Linux system administrator
named Paul. We have been instructed to place all our privileged accounts into CyberArk
PAM so that their passwords (and SSH keys) will be stored in the Vault.
Paul is a member of the Active Directory groups CyberArk Safe Managers. This means
that when he logs in to CyberArk PAM, he will have the right to create Safes, add users to
the Safes he creates, and to add new accounts to those Safes, which is what we shall do.
Note: Some features may require the use of the UI´s classic interface (pre-version 10). To
access this, you may need to select Additional details & actions in classic
interface, as shown below.
We will perform the basic tasks required to manage a privileged account on a Linux server
to which we connect using SSH. We will create a Safe to securely store the account and
add an AD group of users who are authorized to use the account. We will then add the
new account, verify that we can connect with it, and see how an auditor can monitor the
account activity.
Creating a Safe
Log in to the PVWA as Paul with the password Cyberark1 using LDAP
authentication. Notice that Paul can see the CyberArk service accounts, but he is
unable to view the passwords or use the accounts due to his permissions.
3/15/2022
Go to POLICIES -> Safes and click Create Safe.
Enter Lin-Fin-US as the Safe Name. This is the Safe where the ACME Corporation
will store the privileged accounts for its Linux servers that hold financial data for its
US division. You can also provide a meaningful description. We won’t worry about
the other parameters for now, so press Save when you are done.
Add Safe Members
Press Add Member to grant other users access to the new Safe.
3/15/2022
Enter linuxad in the Search field, select acme.corp in the Search In field and press
Search. Select LinuxAdmins, uncheck the option Retrieve accounts, and press Add.
Now add another group. This time add the LDAP group CyberArk Vault Admins with
the permissions only List under Access and all permissions under Account
Management.
3/15/2022
Click Add and then close the Add Safe Member window.
Note: You should now see that the LinuxAdmins group has been added to the newly
created Lin-Fin-US safe. We removed the ‘Retrieve’ option so that users will never
have access to the password. They can use it to connect, but never actually see it.
Also note that the user logged in is the creator of the Safe and is granted full
permissions by default.
We also added the CyberArk Vault Admins group so that they will be able to perform
account onboarding, which we will see later, but they will not be able to view the
passwords or even use the accounts to connect.
Adding a Linux account
We have created a Platform and a Safe. Now we will add our first Linux account and store
it in the Lin-Fin-US safe and manage it with the LIN SSH 30 platform.
Go to ACCOUNTS and click Add Account.
3/15/2022
On the Add Account page, first select the system type *NIX and click Next:
Select the LIN SSH 30 platform and click Next:
3/15/2022
Select the Safe we created earlier: Lin-Fin-US and click Next.
Note: In the image above, only one safe appears. Why is that?
Enter the account details as shown below and click on Add:
Address: 10.0.0.20
3/15/2022
Username: logon01
Password: Cyberark1
On the Accounts page, select the newly created account. In Account Details,
press the Change button to confirm that you have created the account correctly and
to change the password to a value known only to CyberArk PAM.
You will be asked to confirm the password change. Click Change.
3/15/2022
You will see a brief message at the top of the screen:
After a minute or two, you will see that the value for Compliance Status is updated
to Changed by PasswordManager.
Test the New Account as Safe Manager
Paul wants to make sure that his new account is working correctly, so we are going to
connect to the target system using the account through the PSM.
Click on the account logon01 and click the Connect button.
3/15/2022
Note: The behavior of RDP files will depend on the browser you use. The example shown
here is from Google Chrome.
Click on the RDP file to open it. You may receive a pop-up warning about the
publisher of the RemoteApp program. Click Connect to continue.
The first time you connect to a particular machine, you will receive an alert about the
server’s host key. Click Yes to accept the server’s key.
In the lower right-hand corner of the screen, you will see a pop-up informing you that
the session is being recorded. It will disappear automatically.
3/15/2022
And then a PuTTY window will appear in your taskbar with your SSH connection to
the machine target-lin as logon01, click on it to display.
Close the RemoteApp window by typing “exit” (without the quotes) and hitting Enter.
In the PVWA, you can view some of the messages your actions generated in the
Activities list.
Log out of the PVWA.
3/15/2022
Test the New Account as a Normal End User
Our first test verified that we can establish a connection to the target system using the
PSM. Now we want to just make sure that a normal user – i.e., a user who must use
CyberArk PAM to get his or her job done – can use the account to connect to the target.
There is an AD user named Carlos who is a member of the AD group LinuxAdmins, which
you will remember is the group Paul added as a member of the Safe Lin-Fin-US.
Log in to the PVWA as Carlos with the password Cyberark1.
Click on the logon01 account and then click the Connect button.
3/15/2022
Note: Notice that the Show and Copy buttons are greyed out. This is because Paul
removed the Retrieve option for these users. They can connect to the target
system, but they will never know what the password is, making it less likely that the
password can be compromised.
As you did in the previous test, open the RDP file, accept the publisher and the
server key. Execute a few simple, non-destructive commands (remember, you are a
privileged user) such as pwd and ls -al to generate some session activity.
When you are done, enter exit and hit Enter to close the session.
Auditor Tasks
In this step you will review the activity related to the logon01 account by putting on our
auditor’s hat.
Sign out of the PVWA and log in using LDAP Authentication as cindy.
In the left-hand toolbar, click on the Monitoring tab.
3/15/2022
Click on Carlos in the list of Recordings.
Notice that you have the details of what happened during the session under
Activities, including the commands you executed. Click on the Play button to view
the recording.
3/15/2022
The recording plays automatically. You can pause, rewind, fast-forward, or jump to a
specific place in the recording by clicking on a command.
You can close the recording window by clicking on the X in the upper right-hand
corner.
Sign out of the PVWA.
3/15/2022
Securing Oracle Database Accounts

In this section, we will configure CyberArk to manage an Oracle DBA account. As in
previous exercises, we will duplicate a Platform, create a Safe, and then add the account.
Vault Administrator Tasks
In this section, we are going to create a Platform dedicated to managing accounts used to
access Oracle databases, such as a DBA account.
Log in to the PVWA as mike and go to ADMINISTRATION -> Platform

Management.
Choose Database -> Oracle Database and select Duplicate.
Enter ORA DBA 30 and press Create.
Select ORA DBA 30 and select Edit.
Go to UI & Workflows and set AutoChangeOnAdd to Yes.
Go to Automatic Password Management -> General.
• Set ImmediateInterval to 1.
• Set AllowedSafes to Ora-.
3/15/2022
Now go to Automatic Password Management -> Password Change and change

the value of the parameter PerformPeriodicChange from No to Yes. This will enable
the application of the Master Policy rule Require password change every X days to
accounts managed by this platform.

verified by the CPM automatically and without user intervention
Press Apply.
In the Generate Password section, add the equal sign character (‘=’ without the
quotes) to the PasswordForbiddenChars field. Make sure you add the new character
without deleting any of the existing characters.
Click OK to save the changes and close the Platform.
Note: Now that we have duplicated the Oracle Database platform, you can deactivate the
base Oracle Database platform.
Note: Don’t forget to add an exception to the Master Policy to rotate the oracle DBA
passwords every 30 days.
Safe Manager Tasks
Because we are dealing with a different technology – Oracle in this case – the person
responsible for managing Oracle Safes is different. Our Safe Manager for this exercise is
named Robert.
3/15/2022
Creating a Safe
Log in to the PVWA as LDAP user Robert and go to POLICIES -> Safes.
Press the Create Safe button.
Enter Ora-Fin-US as the Safe name and press Save.
Add the Active Directory group OracleAdmins to the Safe, removing the Retrieve
permission (make sure to search for the group in acme.corp).
Now add the LDAP group CyberArk Vault Admins. Remove the permissions: Use
accounts and Retrieve accounts. Add Account Management (which will add all the
permissions under it). We will need this for a later exercise.
Adding an Account
Go the ACCOUNTS tab, click Add Account and enter the following:
System type Database

Platform ORA DBA 30
3/15/2022
Safe Ora-Fin-US
User Name dba01
Address 10.0.0.20
Password Cyberark1
Confirm Password Cyberark1
Port 1521
Database xe
Press Add.
Note: Because the policy was set to AutoChangeOnAdd=Yes, the account will be set for
immediate change.
Press refresh and you will see the message: ‘The password for this account has
been manually scheduled for change’.
3/15/2022
Once the password has been changed by the CPM, press the Show button to display
the new password.
3/15/2022
Linked Accounts
Securing SSH Accounts Using a Logon account
In this exercise you will add to your CyberArk PAM implementation a Linux privileged
account that is prevented by the target machine’s security policy from accessing the server
via SSH, which is a very common restriction for root accounts. You will then associate a
logon account with this new account, allowing you to use and manage the password
despite the SSH restriction. The logon account establishes the connection to the target
machine and executes a switch-user operation to the privileged account.
Note: In the Unix/Linux world, the account that is typically prevented from
connecting to a server remotely is the root account. Here in CyberArk
training, we are going to use an account named user01 and we will use the
account we created earlier, logon01, as the logon account.
Log into the PVWA as Paul (this is a Safe Manager task).
Go to the Accounts page and press the Add Account button.
On the Add Account screen, enter the following:
System Type: *NIX

Platform Name: LIN SSH 30
Store in Safe: Lin-Fin-US
Address: 10.0.0.20
Username: user01
Password: Cyberark1
Press Add.
3/15/2022
On the Account Details page, press the Verify button. The status will appear as
‘This account is scheduled for immediate verification’.
Eventually this will fail because the CPM received an ‘Access Denied’ message due to the
restriction on user01 (in the log file you should see an error message – “Permission
Denied”)
Click on the account User01, then Details, and click on […] in Logon Account in the
Linked Accounts section.
3/15/2022
Search for the account logon01 and click OK
Go back to Overview, press the Verify button and click OK to confirm. If you receive
the following message, press OK.
3/15/2022
Note: After a few minutes, the account should be verified. In the background the CPM
connected to the server as logon01 and switched to the user01 account to verify the
password.
Securing Windows Server Local Accounts via a Reconcile Account
In this exercise you will add a Windows local server account for which the correct
password is unknown. To bring this account under management, you will associate it with
a domain administrator account (cybrreconcile) that can perform a password reset.
Vault Administrator Tasks
Log in to the PVWA as mike.
Go to ADMINISTRATION -> Platform Management.
Select the Windows Server Local Accounts and click Duplicate.
Enter WIN SRV LCL ADM 45 as the platform name, you may optionally add a
description like “Rotate password every 45 days”, and press Create.
Highlight the newly created platform and select Edit.
3/15/2022
Go to UI & Workflows.
Change AutoChangeOnAdd from No to Yes. This causes the CPM to initiate a

password change whenever a new account that uses this policy is created. Select
Apply to save your change.
Go to Automatic Password Management -> General and set the ImmediateInterval

to 1.
Note: Once again, we are modifying this value for training purposes only, enabling us to
move a little faster. A one-minute immediate interval is suitable for testing but
should be set to five in a production environment.
Enter Win-Srv- in the AllowedSafes field to limit the accounts with which this platform
can be used. Click Apply to save your change.


3/15/2022
Go to Password Reconcilation and enter following:
RCAutomaticReconcileWhenUnsynced: Yes
ReconcileAccountSafe: CyberArk-Service-Accounts
ReconcileAccountName: (you can copy this from the notepad file
that you created earlier, do NOT copy
from this PDF)
Note: The values for the parameters as they appear above assume that you have followed
all previous instructions to the letter. If you haven’t, then these values will not work.
Also, copying and pasting from the PDF into the virtual machine causes problems,
so the safest approach is to do as instructed earlier and copy the values from the
PVWA, paste them into Notepad, and then copy them into the appropriate fields in
the Platform.
3/15/2022
Note: Think about what appropriate values for password length and complexity would be.
Don’t forget to add the relevant exception to the Master Policy to enable automatic
password rotation every 45 days.
As we have now duplicated the Windows Server Local Accounts, you can deactivate
the platform.
Press Apply and OK to close the platform.
Log out of the PVWA session.
Safe Manager Tasks
Once again, we are changing hats and are going to log in as a Safe Manager named Tom,
who is responsible for the Windows servers team. In this part of the exercise, we will:
• Create a Safe
• Add Members to the Safe
• Add an Account
Creating a Safe
Now we are going to create a Safe for our Windows server local administrator accounts.
To comply with data protection regulation, we are going to organize our Safes so that only
US admins can access the passwords for US safes.
Log in to the PVWA as the AD user Tom with the password Cyberark1.
Go to POLICIES -> Safes and click Create Safe.
Name the Safe Win-Srv-Fin-US. Leave the default values for the rest.
Add the AD group WindowsAdmins to the Safe, but remove the check for Retrieve
Accounts – we don’t want our local administrators to view passwords. As this is the
first time, we are assigning permissions to this group, make sure to search for the
group in acme.corp.
3/15/2022
Now add the LDAP group CyberArk Vault Admins. Remove the permissions: Use
accounts and Retrieve accounts. Add Account Management (which will add all the
permissions under it). We will need this for a later exercise.
3/15/2022
Adding an Account
Here we will add a local administrator account for your target Windows server: target-
win.acme.corp. Remember, we don’t know what the password is, so you could put
anything in the password fields (although they must match). We are still using the Tom
account.
Go to the ACCOUNTS page, and press Add Account. Enter the following and press
the Add button:
System type Windows

Platform WIN SRV LCL ADM 45
Safe Win-Srv-Fin-US
Address target-win.acme.corp
User Name localadmin01
Password <leave blank>
Confirm Password <leave blank>
Logon To (optional) <click to resolve>
3/15/2022
Note: After adding the account, you should see a message stating ‘The password for this
account has been manually scheduled for change. This is because you set
AutoChangeOnAdd to Yes in the policy. Also note that there is a reconcile account
already associated with this new account.
Press Refresh. Because the password for this account is incorrect, the password
change will fail.
Press Refresh again and after a short time and you should receive a message
saying that the account was successfully reconciled. The first time an account is
reconciled it can take a little while, so be patient.
3/15/2022
Securing UNIX Accounts with SSH Keys

In this section, we will perform the tasks required to manage a Linux account that connects
to its target server with a public-private key-pair.
Generating a Key-Pair
On the Components server launch PuTTY Key Generator from the Taskbar
Click Generate in the PuttyGen window:
As instructed, you need to make mouse movements in the blank area to generate
random data for the key.
3/15/2022
When the key is generated, click Save Private Key.
Click Yes to store they key without a passphrase. The CPM does not support private
keys with passphrases.
3/15/2022
Name the key root01.ppk and save it to your Documents directory.
Select all the text in the ‘Public key for pasting into Open SSH authorized keys file’
box and copy it to your clipboard.
3/15/2022
Note: You might want to paste the public key into a text file for safe keeping, because if
you close Putty, you will lose it and need to regenerate a new key-pair.
Use PuTTY to connect to Target Linux.
Select Target Linux, click the Load button, then click Open to launch the pre-
configured connection.
3/15/2022
When prompted, log in as root01 with the password Cyberark1.
Edit your authorized key file with vi.
vi ~/.ssh/authorized_keys
Press i (or the Insert button on your keyboard) to enter insert mode.
Right-click inside the editor to paste the key. Verify that the key pasted correctly.
3/15/2022
Warning! It can be a bit tricky to copy and paste into a terminal window. Make sure that your
key text begins with the string “ssh-rsa” and that it ends with “rsa-key-date” where
date is today’s date.
Press ESC and then enter:
:wq
That is : (colon) (w) (q) and then press ENTER to save and exit.
Make sure the key appears in the authorized_keys file (and that all characters were
pasted properly) by using the cat command:
cat ~/.ssh/authorized_keys
Exit your PuTTY session.
Note: If you need help with the vi editor, you can read the tutorial at:
http://www.tutorialspoint.com/unix/unix-vi-editor.htm
Verify you can login with the Private Key
Now we will test that we are able to authenticate with the private key.
Open PuTTY again. Select the Target Linux connection and add a new name, such
as Target Linux Key root01 and click Save. This will save the new configuration in
case you need to come back again.
3/15/2022
Navigate to Connection -> Data and enter root01 in the Auto-login username field.
Navigate to Connection -> SSH -> Auth, click Browse, and select the ppk file you
created earlier.
3/15/2022
Go back to the main window and save your configuration again with the new values.
Now click Open and verify that you can log on without supplying a username and
password.
Type exit and then hit Enter to close the session.
Note: It should be noted that adding an SSH key does not automatically disable password
authentication for this account on the target. You will still be able to log in with the
password for root01.
Duplicating a Platform – Vault Administrator Task
Login to PVWA as mike and go to ADMINISTRATION -> Platform Management.
Highlight *NIX -> Unix via SSH Keys (make sure that you choose the Unix via SSH
Keys platform, not the “Unix via SSH” platform).
3/15/2022
Select Duplicate.
Name your platform LIN KEYS 90 and click Create.
Select LIN KEYS 90 and select Edit.
Go to Automatic Password Management -> General.
• Set ImmediateInterval to 1.
• Set AllowedSafes to Lin-.
Press Apply.


Note: Now that we have duplicated the Unix via SSH Keys platform, you can deactivate
the base Unix via SSH Keys platform.
Note: Don’t forget to add an exception to the Master Policy to rotate SSH Keys every 90
days.
Add an Account with an SSH key – Safe Manager Task
Log in to the PVWA as Paul.
Go to the ACCOUNTS VIEW page and click the Add Account button.
Add an account with the following properties. If you do not see the SSH Key
configuration area, you may have duplicated the wrong platform.
System Type: *NIX

Platform Name: LIN KEYS 90
Safe Name: Lin-Fin-US
Address: 10.0.0.20
Username root01
3/15/2022
Private Key: Browse to find the root01.ppk file you

created earlier.
You may also paste the content of the
private key.
Click Add. You will receive a notification that the account has been added:
Click Change to rotate the key pair.
Click OK. This process can take a few minutes.
Once the change completes, verify that you are NOT able to connect with PuTTY
using the private SSH key stored locally on the Components server.
3/15/2022
As a final step, you can test connecting to the target system using the newly created
account in the PVWA.
3/15/2022
Dependents – Securing Service Accounts / Usages

In this section, we will look at service account usages. Specifically, we will look at:
• Managing a Scheduled Task Usage

• Managing a Configuration File Usage
Managing a Scheduled Task Usage
The virtual machine “Target Windows” (target-win - 10.0.21.1) contains two scheduled
tasks: schedtask01 and schedtask02. Both tasks are configured to send emails to Mike
and John every time they are run, and they can be executed manually from a remote
machine by members of the LDAP groups WindowsAdmins and CyberArk Vault Admins.
The schedtask01 is configured to run with the local account localadmin01, while
schedtask02 is configured to run with local account localadmin02.
To test the scheduled task, launch a command prompt. You have a shortcut to
launch a command prompt.
3/15/2022
Now run the following command:
schtasks /run /s target-win /tn SchedTask01
Because the localadmin01 account password was changed in an earlier exercise

without accounting for the associated scheduled task, the scheduled task will not
run properly (even though the return message says “SUCCESS”). You can confirm
that the scheduled task did not complete properly by checking your email account
mike@acme.corp and seeing that you do not have any messages referring to
“scheduled task”.
To open the email, launch a new browser tab, click on the short-cut Acme Webmail in
the toolbar. Log in as mike with the password Cyberark1.
3/15/2022
Now, log in to the PVWA as Tom and go to the localadmin01 Account Details. Open
the classic interface.
Locate the Scheduled Task tab.
3/15/2022
Press Add.
Enter SchedTask01 in the Task Name field and enter target-win.acme.corp in the
Address field. Press Save.
After pressing Save, you’ll be able to see the new scheduled task that is associated
with the localadmin01 account.
3/15/2022
Note: In many cases, the service account would be blocked from modifying its own
password. If that were the case, you would need to associate a reconcile account
with the Platform and set the parameter ChangePasswordInResetMode to Yes.
This procedure is covered in the CyberArk PAM Install & Configure training. You
would also need to associate a logon account with the scheduled task, which would
be used to perform the password change for the dependency.
Next, go back to the localadmin01 Account Details window and run a password
change. Select Change the password immediately (by the CPM).
You will need to wait for both the localadmin01 and the usage password to change
and then re-run the scheduled task from the command prompt. This will take a few
minutes.
Note: The scheduled task is associated with a different platform than the localadmin01
account. After the localadmin01 account has been changed, the flag will be set for
the scheduled task to be changed. The entire process could take around 10
minutes to complete.
3/15/2022
Now check your email. This time you should receive a message stating that “The
scheduled task is working”.
Note: It is highly recommended to use the accounts discovery feature to detect, provision,
and manage all service accounts automatically. We will use the Accounts Discovery
capability later to discover and onboard schedtask02 which is associated with
localadmin02.
Managing a Configuration File Usage
In this exercise you will be configuring a usage to update a password in a configuration file
whenever the specified account’s password is changed. In this example, the credentials
for dba01, an Oracle database privileged account, are also used by an application, which
retrieves the credentials from a configuration file – app01.ini. The file app01.ini is located
on the Linux server IP address 10.0.0.20 in the /var/opt/app directory.
[Startup]
Product=App Server
3/15/2022
ProductGUID=bf1f0850-d1c7-11d3-8e83-0000e8efafe3
CompanyName=Acme
CompanyURL=www.acmeiincv.com
MediaFormat=1
LogMode=1
SmallProgress=N
SplashTime=
CheckMD5=Y
CmdLine=
ShowPasswordDialog=N
ScriptDriven=4
[Languages]
Default=0x0409
Supported=0x0409
RequireExactLangMatch=0x0404,0x0804
RTLLangs=0x0401,0x040d
[Server]
Hostname=target-linux.acme.corp
Username=dba01
Password=Cyberark1
[Database]
Db=xe
Port=1521
Create a Logon account
The account dba01 is an Oracle DB account and is therefore unable to change the
credentials in a configuration file that is located on the Linux machine. As preparation, we
will now create a Logon account which will be used by the CPM to login to the Linux target
server and change the credentials stored in the app01.ini configuration file.
On your Components server, log in to the PVWA as paul.
Go to ACCOUNTS and press Add Account and enter the following:
System Type: *NIX

Platform Name: LIN SSH 30
Store in Safe: Lin-Fin-US
Address: 10.0.0.20
Username: app-account01
Password: Cyberark1
3/15/2022
Click on the newly created account and click on Verify to confirm that the CPM can
verify the account password.
Configure Usages on the Oracle platform
Login to the PVWA as Mike.
Now navigate to the ADMINISTRATION tab and click Platform Management.
Select ORA DBA 30 and press Edit.
Go to Automatic Password Management -> General, set SearchForUsages to Yes

and press Apply.
Right-click UI & Workflows and choose Add Usages.
After selecting Add Usages, you will have a new ‘Usages’ entry at the end of the UI &
Workflows section. Right click Usages and select Add Usage.
3/15/2022
Enter INIFile as the Value.
Press Apply and OK.
Add the Usage to the target account
Now go to ACCOUNTS and open the dba01 account using the Classic UI.
3/15/2022
If the previous steps were configured properly, you should be able to see a new tab
called INI File in the Account Details page. In the new tab, click on Add.
Enter the following and click on Save:
Address: 10.0.0.20
File Path: /var/opt/app/app01.ini
Connection Type: SSH
INI Parameter Name: Password
INI Section: Server
Backup Password File: No
Click on the new Usage:
3/15/2022
And then click on Associate.
Select the app-account01 account and click on Associate.
3/15/2022
Note: The reason we are associating a logon account with the Usage is because the
target account (dba01) does not have permissions or the ability to change the
password in the configuration file (app01.ini). The CPM will use the Logon account
(app-account01) to connect to the target Linux machine and change the password in
the configuration file.
Review the details of the Usage in the Accounts Details page and make sure
everything is configured properly.
3/15/2022
Go to the Account Details for the primary account (dba01), click the Change button
page.
Once the password for the primary account has changed, click on the Usage, and
verify that the Usage is now set for immediate change.
Review the Account Details page again after a few minutes to confirm the CPM has
changed the password for the Usage as well.
Note: This process can take several minutes to complete. The usage has interval settings,
just like the account. When the account changes, it scans the Vault for usages,
marks those usages for change, and then, according to those intervals, the changes
take effect. So, it will be a few minutes between when the password changes and
the file changes.
Perform the following steps to verify the password dba01 in the Vault matches the
password in the app01.ini file.
First, log in to the PVWA as Robert and locate the dba01 account. Select Show to
see the password of dba01. Copy the password to Notepad.
3/15/2022
Now, log in to the PVWA as Paul and connect to 10.0.0.20 with the app-account01
account.
Enter the following:

cat /var/opt/app/app01.ini | grep Password
If everything was configured properly, you should be able to confirm that the
password in the file matches the new dba01 password in the Vault.
3/15/2022
Privileged Access Workflows

In this section, we will configure the Master Policy for three Privileged Access
Workflows:
• Reason for access

• Dual control
• Exclusive passwords
Require users to specify reason for access
In this section we will test the Require users to specify reason for access workflow as well
as configure predefined reasons.
Activating the Policy
Log into the PVWA as mike and go to POLICIES -> Master Policy -> Privileged
Access Workflows, select Require users to specify reason for access, and press
Add Exception.
Select LIN SSH 30 and press Next.
3/15/2022
Set Require users to specify reason for access to Active. Set Allow users to specify
reason for access to Inactive. Click on Finish.
Add Predefined Reasons for Access
Navigate to the ADMINISTRATION tab and click Platform Management.
Select the LIN SSH 30 and click on Edit.
3/15/2022
Right-click on UI & Workflows and select Add Privileged Account Request.
Expand Privileged Account Request and then right-click on Predefined Reasons.

Select Add Reason to add predefined reasons.
Add the following predefined reasons (you may also add your own if you wish).
3/15/2022
When you finish, click on OK to save and exit.
Testing Predefined Reasons for Access
Now, log into the PVWA as Carlos and select the user01 account. Click on Connect.
Select one of the predefined reasons, for example, Emergency Reboot. Then click on
Connect again to download the RDP file.
Click on the RDP file to connect to the target machine.
Once the connection to the target machine has been established, navigate to the
Activities tab and verify you can see the Audit details for the Connect action.
3/15/2022
When you are finished, disconnect from the target machine.
Require dual control access approval
Dual control – requiring a manager to validate a request for access approval for certain
accounts – is a 2-step process:
1. You must activate the policy Require dual control password access approval, either
globally or by exception for a certain Platform (which is the usual case and what we
will do).
2. Add an approver to a Safe, either a group or a user, with at least the List Accounts
and Authorize account requests permissions.
This minimum configuration would give the manager/approver the right to validate the
requests, but not the right to use the passwords to connect to target systems (they only
have List, not Use or Retrieve).
Activating the Policy
Log into the PVWA as mike and go to POLICIES -> Master Policy -> Privileged
Access Workflows, select Require dual control password access approval, and
press Add Exception.
3/15/2022
Click Active. Review (but do not modify) the other options available. When ready,
press Finish.
3/15/2022
fg
Adding an approver to a Safe
The workflow process is configured through Safe membership. We need to add a

manager to a Safe containing accounts that are managed by the Platform for which we
have created our exception so that he/she can approve requests. In our example,
members of the group ITManagers will be able to approve requests, but they will not able
to Retrieve the passwords or Use them.
Log on to the PVWA as Paul and go to POLICIES -> Safes.
Highlight Lin-Fin-US and press the Members button.
Click Add Member.
3/15/2022
Enter ITManagers in the Search field, select acme.corp in the Search In field, and
press Search.
Select the ITManagers group.
Under Access, remove the checks for Use accounts and Retrieve accounts for this
group.
Scroll down and expand the Workflow link to access the Authorize account requests
check box. Check the Authorize account requests authorization box with Level 1
remove the Access Safe without confirmation permissions.
3/15/2022
Press Add.
Testing Dual Control
Testing this workflow requires us to wear a number of hats. We configured the system as
a Safe Manager – Paul – now we are going to become ordinary users of the system.
• We will first log in as a user who has the right to use a password, but only with
manager approval – Carlos.
• We will then put on our manager hat and check our email, notice that we have a
notification for an approval request pending, log into the PVWA as that manager
user – Tom – using the link provided, and approve the request.
• Finally, we will return to the PVWA as Carlos, find the approval notification, and
access the target system with the password.
Note: Because we will be changing users, you might want to use two browsers or separate
browser sessions. You can use incognito mode to open two separate sessions with
two separate users.
3/15/2022
First, login to the PVWA as the LDAP user Tom with the password Cyberark1 (note
Tom can now see Linux accounts as well as Windows, but he is unable to use the
Linux accounts, only approve Dual Control requests by members of the Linux team).
Next, open a different browser or incognito mode in Chrome, and login in as the
LDAP user Carlos with the password Cyberark1.
Locate the logon01 account and select the Request Connection button.
Select a Reason to access the account. Note that you are unable to enter free text
and can only see the pre-defined reasons we configured in the previous exercise.
Activate the Timeframe and specify FROM the current date in the morning TO the
end of the last day of the class. Also activate Multiple access is required and then
press on the Send Request button.
3/15/2022
Launch a new browser session and open the email client (there is a short-cut in the
browser toolbar).
Login as Tom. You should have received an e-mail with the new request (if you do
not receive an email, make sure the ENE service is running on the Vault).
Note: Unfortunately, because we are using Mike to login to the Windows OS, we will not
be able to click on the link in order to navigate directly to the Incoming requests
page. Instead, we will login to the PVWA and navigate manually.
Login to the PVWA as Tom (password Cyberark1) if you are not already logged in.
Go to Accounts and select Incoming Requests.
3/15/2022
Locate the incoming request from Carlos and press the Confirm button.
Enter a reason and press Confirm.
Before signing out, go to the Accounts View. Take note of the fact Tom is unable to
make requests to view the logon01 password or use it to connect.
3/15/2022
Sign out and close the browser to terminate the Tom session.
Browse to the email client and login as Carlos. You should receive an e-mail stating
the request has been confirmed.
Login to the PVWA as Carlos (password Cyberark1) if you are not already logged on,
then go to the Account View page. Notice the Status of the request is now
confirmed. You can now use the password and connect to the previously requested
account.
Sign out of the Carlos session.
Exclusive Passwords with Automated Release and One-time Use
In this exercise, you will configure the Windows Server Local accounts added earlier for
exclusive access with an automatic release based on the Minimum Validity Period.
Adding a Master Policy exception for Exclusive Passwords
Exclusive Passwords are configured in the Master Policy.
login to the PVWA as mike.
Go to POLICIES -> Master Policy and select Enforce check-in/check-out exclusive

access and click Add Exception.
3/15/2022
Select WIN SRV LCL ADM 45 and press Next.
Press the Active button to enable Enforce check-in/check-out exclusive access and
click Finish.
3/15/2022
Adding a Master Policy exception for One-Time Passwords
To allow for an automatic release of a checked-out password, you will need to enable the
policy Enforce one-time password access for the platform WIN SRV LCL ADM 45.
Highlight Enforce one-time password access and press Add Exception.
Select WIN SRV LCL ADM 45 and press Next.
Press Active to enable one-time password access for this platform and then click
Finish.
Reducing the Minimum Validity Period
Note: This next step is for testing/training purposes only and should not be used in a
production environment.
We will set the Minimum Validity Period to 5 minutes, so that we can see our results more
quickly. The MinValidityPeriod parameter is configured in the Platform.
Go to ADMINISTRATION -> Platform Management, select WIN SRV LCL ADM 45,
and click Edit.
Go to Automatic Password Managment -> Privileged Account Management.
Set MinValidityPeriod to 5.
3/15/2022
Press Apply and OK to close the Platform and then sign out of the PVWA.
Right-click the restart-services.bat on the desktop of your components server and

select Run as administrator. This will cause the CPM server to reload all policies and
force your configuration changes to to take affect immediately.
Testing Exclusive Passwords
In this section, we will test our configuration of exclusive passwords with automatic
release. We will use the users Tom and John. Tom is the Safe Manager (therefore its
owner) and John is a member of the Active Directory group WindowsAdmins.
Login to the PVWA as the LDAP user Tom with the password Cyberark1.
Go to ACCOUNTS.
Click on the localadmin01 account and click the Show button. Tom has now
checked out the password.
3/15/2022
You should be able to see the password as well as disclaimer stating the password is
available for the next 5 minutes, after which it will be rotated.
Log out of the PVWA and log back in as John. You should notice a lock icon next to
the localadmin01 account.
Note: Only Tom or a user who has the "Unlock Account" permissions on that Safe can
release the account manually by using the “Check-in” option, however we will not
use this option as we want to see the system release it automatically at the end of
the Minimum Validity Period.
Hover over the lock icon, it should say “The account is checked-out by Tom”.
If you press Connect, you will be able to download the RDP file. However, if you click
on the RDP file and attempt to launch a connection, you will receive an error
message.
3/15/2022
After several minutes (remember the minimum validity period was set to 5 min), John will
be able to access the password and the CPM will have changed the password.
Hint: If the account is not released after several minutes, run the restart-services.bat file
and check again.
Testing Automatic release by PSM
Starting with v11.7, the PSM can also release an account locked by exclusive access upon
closing the remote session. Perform the following steps to test automatic release by the
PSM:
Login to the PVWA as mike and navigate to ADMINISTRATION -> Platform

Management. select WIN SRV LCL ADM 45 and click Edit.
Navigate to Privileged Session Management and set

ExclusiveUnlockAfterPSMSession to Yes.
Right-click the restart-services.bat on the desktop of your components server and

select Run as administrator. This will cause the PSM server to reload all policies and
force your configuration changes to to take affect immediately.
3/15/2022
Login to the PVWA as John and locate the localadmin01 account. Click on Connect.
After the session to the target machine has been established, confirm the account is
locked by John.
Now, disconnect from the target machine.
If everything has been configured correctly in the previous steps, the localadmin01
should be unlocked immediately by the PSM (without password rotation). To confirm,
open the Account details page and look at Activities. You should be able to see that
the account has been unlocked by the PSM.
3/15/2022
Then, after a few minutes, the account password will also be rotated by the CPM
(thanks to the One-time password setting).
3/15/2022
Discovery and Onboarding

In the following exercises you will use the Accounts Feed feature to discover and onboard
accounts to the system.
Accounts Feed
In this section you will configure rules for automatically onboarding accounts discovered
using the Accounts Feed feature, run a Windows Discovery to discover and automatically
onboard accounts, and lastly you will manually onboard accounts that were not covered by
the automatic onboarding rule.
Configure Automatic Onboarding Rules
In this section, you will configure Onboarding Rules to add newly discovered accounts to
the Vault without any human intervention.
Login to the PVWA as mike.
Go to Accounts -> Accounts Feed -> Onboarding Rules.
Click on Create rule.
3/15/2022
In Select system type, select Windows.
In Select Scope select the following:
Machine Type: Server
Account Type: Local
3/15/2022
Account Category: Any
Privileged Account Type: Any
Username (begins…): discovery
Click Next.
In Assign to platform select WIN SRV LCL ADM 45.
3/15/2022
In Store in Safe select Win-Srv-Fin-US.
In Define rule properties enter the following name: Discovery users and click Next.
Review your rule and if everything seems to be in order, click on Create rule.
3/15/2022
Configure and Run Windows Accounts Discovery
The Accounts Discovery process requires an account to log in to the domain and scan the
individual machines. We will use the cybrscan account we created in the first exercise.
Note: The user cybrscan is an Active Directory account created especially for the
purposes of running Accounts Discovery scans. It is a member of the Domain
Admins AD group.
Go to Accounts -> Accounts Feed -> Pending & Discovery -> Discovery
Management and click New Windows Discovery.
3/15/2022
Enter acme.corp in the Domain field and then use the Click to select an account
from the Vault link.
Select the account cybrscan that we created in an earlier exercise and click the
Select account button.
3/15/2022
Back in the main dialog, you will see a summary of the account selected. Now scroll
down to the next section.
In the What to scan? section, click Browse.
3/15/2022
Select the Servers container and press OK.
Under What recurring pattern to set for this Discovery? Select Onetime, then
click Done.
3/15/2022
You will receive a message saying that the Windows discovery has been added.
Press OK.
Press the Refresh icon to update the status. You may need to back out of the
window and go back in to see the state change. This can take a few minutes. You
should see the status change from Pending to Running.
3/15/2022
After several minutes, the process should appear as Completed.
Note: The discovery will complete with errors. This is expected in our environment.
Go to Accounts -> Accounts View. If you configured your automatic rules properly,
you should be able to see all the “discoveryXX” accounts in the accounts view (there
are 10). You should have assigned a reconcile account to the platform, so the
accounts added should also be reconciled or scheduled for immediate reconciliation.
3/15/2022
Manually onboard discovered accounts
In this section, we will manually onboard an account that was discovered but for which
there was no automatic onboarding rule.
Go to the Pending Accounts list, enter localadmin02 in the Keywords field, and run
a search.
Select the resulting localadmin02 account. Click on the 1 under Dependencies to

see the dependency associated with the account.
Note: The account localadmin02 has a scheduled task dependency (schedtask02)

associated with it. By onboarding the account, we will also onboard the scheduled
task dependency. Click on Close when ready.
3/15/2022
Note: One of the main benefits of discovery and onboarding is the ability to discover
dependencies tied to Windows accounts. Unlike the previous exercise, this time the
dependency will be onboarded along with the target account, and the CPM will
manage the dependency without any human intervention.
Press the Onboard Accounts button.
In the Onboard Accounts window, select the following:
Store in Safe Win-Srv-Fin-US
Assign platform WIN SRV LCL ADM 45
Password Automatically reconcile password

(this will only be available if the assigned
platform contains a reconcile account)
3/15/2022
Press Onboard. You should receive a message saying “Successfully onboarded 1

account(s) and related dependencies. Press Done.
Go to the ACCOUNTS page and search (press the magnifying glass icon top
right) for the newly created account. Because the platform was configured for
automatic reconciliation, you should see that the account has been reconciled.
Confirm that you can also see there is a dependency associated with the account.
3/15/2022
To confirm the scheduled task is also working, open a command line interface and
input the following command.
schtasks /run /s target-win /tn SchedTask02
Now, login to the email client as Mike and verify that you received the email
confirming schedtask02 is working.
Add Multiple Accounts from File
Frequently there is a need to upload many known accounts into CyberArk PAM from an
existing repository. This is especially valuable during the early stages of
implementing CyberArk PAM, migrating from another solution, or when onboarding a new
department into the PAM solution.
In this section you will:
• Upload an accounts file
• View the status of the upload process
3/15/2022
• Download a detailed result file with the failed accounts and error messages
Open the File explorer on your Components server and go to c:\Add-Accounts.

Open the accounts-Linux.csv file. Make sure to select Comma in Separator Options.
Review the file and the properties of the accounts we are about to upload to the
CyberArk PAM solution.
3/15/2022
Now, login to the PVWA as mike.
Go to ACCOUNTS -> Accounts View and select Add accounts from file.
First, review the instructions in the page. Note you can also download a sample CSV
file. When you are ready, click on Drag and drop file or browse. Navigate to
c:\Add-Accounts and select the accounts-Linux.csv file. Review the page and click
Upload.
You should see a notification on your screen reporting the success of the action.
3/15/2022
Refresh the page. Search for logon and confirm the accounts were onboarded.
You may also select some of the accounts and launch a Verify or Change action to
confirm the CPM is able to manage the target accounts.
3/15/2022
Privileged Session Management – Part 1

In this section, we will perform several tests to see the various privileged session
management options that are available with CyberArk PAM.
First, we will disable the PSM globally and then activate it for specific platforms using
exceptions.
We will then perform tests to ensure that privileged session management is functioning
properly using the various connection methods available:
• Privileged Session Manager (PSM) through the PVWA

• PSM for Windows
• PSM for SSH
Remove Privileged Access Workflows Exceptions
To simplify the PSM testing, we will first disable the Privileged Access Workflows that we
modified in earlier exercises.
Note: Do NOT disable the Privileged Access Workflow Allow EPV transparent
connections.
Log in to the PVWA as mike using LDAP authentication.
Go to POLICIES -> Master Policy
In the Privileged Access Workflows section, highlight Require dual control

password access approval and click on Exceptions. Then click on the LIN SSH 30
link.
3/15/2022
In the Edit Exception window click on the red Remove Exception button.
Click on Yes to remove the exception.
Remove all the other exceptions we created under Privileged Access Workflows
and make sure all workflows are set to Inactive except for Allow EPV transparent
connections… If you disable this, you will not be able to connect using the PSM.
3/15/2022
Disabling the PSM Globally
The PSM is enabled through the Master Policy. The PSM can be enabled either globally
for all platforms or disabled globally and only activated through exceptions, which is what
we will test here.
Login to the PVWA as mike using LDAP authentication.
Go to POLICIES -> Master Policy.
In the Session Management section, highlight Require privileged session monitoring

and isolation and deactivate it.
Privileged Session Manager
This method allows users to connect securely via the PSM to all types of systems and
applications through the unified PVWA web portal user interface.
Adding Exceptions
Once deactivated, with Require privileged session monitoring and isolation still
selected, press Add Exception.
3/15/2022
Press the Active button and press Finish.
Repeat the above steps to enable PSM for the ORA DBA 30 and WIN SRV LCL ADM
45 platforms.
3/15/2022
Connect with a Linux Account
We will first test connecting securely to a Linux machine using SSH via the PSM. In this
exercise, you will connect to the PSM using RDP, and the PSM will run PuTTy to connect
you to the target Linux machine
Login to the PVWA as Paul, go to the ACCOUNTS page, and locate user01. Press
the Connect button.
You will notice an RDP file has been downloaded. Choose to open it with Remote
Desktop Connection (default) and press OK.
At the Remote Desktop Connection window, press the Connect button
If everything was configured correctly, you should see a message that your session is
being recorded.
Press Yes to accept the host key if you are prompted.
Optionally, run some Linux commands.
3/15/2022
mkdir test
rm -R test
Type exit to end the session.
Connect with an Oracle Account
Log out of the PVWA and log back in as the user Robert.
In the main Accounts window, find the account dba01 and click the Connect button.
On the Remote Desktop Connection window, press Connect.
You should see a message stating that your session is being recorded.
Note: If you receive a Remote Desktop Connect pop-up, “Your Remote Desktop Services
session has ended”, retry the connection component. You may have to connect a
couple of times before seeing the message.
Later in the lab exercise, you will be logging in as an auditor and looking for any sessions
that issued commands with the word ‘salary’.
Run the following commands:
select * from dual;

create table psm01 (id01 int, psm01 varchar(40));
select * from scott.salary;
update scott.salary set salary =’1,000,000’ where id01=1;
Type exit to end the session.
Connect via HTML5 Gateway
In this section, we will see how to configure the PSM HTML5 Gateway, which enables us
to tunnel sessions between end users and the PSM server using a secure WebSocket
protocol (port 443). This eliminates the need to open an RDP connection from the end
user's machine. The RDP session is delivered to the end user through a browser tab,
rather than via an RDP window.
3/15/2022
Enable the HTML5 Gateway
Note: In this environment, the HTML5 Gateway has already been installed for you. It is
running on the same Linux server as the PSM for SSH, but it has not been enabled
in the PVWA.
First, login to the PVWA as mike, go to ADMINISTRATION -> Configuration

Options -> Options.
Next, go to Privileged Session Management -> Configured PSM Servers ->

PSMServer -> Connection Details -> PSM Gateway.
Set the Enable parameter to Yes and click the Apply button.
Click on Apply and then OK to save your changes.
Connect via HTML5 Gateway
Now log in as the user John and go back to the ACCOUNTS page and locate
localadmin01.
Press the Connect button. This time, instead of downloading an RDP file, you will
receive a pop-up asking whether you want to map your local drives and whether you
want to Connect using HTML5 GW. By default, both are disabled, so enable them
both. Provide a reason for the launching the connection, and then click Connect to
launch an HTML5 connection.
3/15/2022
Note: Press Yes to accept the host’s RSA key, if asked.
Note: The ability to toggle between RDP file and HTML5GW connections is defined at the
Connection Component level. For your convenience, the functionality has been
preconfigured for RDP and SSH connections in this lab.
To enable this functionality for other connection types other than RDP or SSH, go to
Options -> Connection Components -> PSM-RDP -> User Parameters and copy
the AllowSelectHTML5 parameter. Then paste it in a different connection
component, for example: PSM-WinSCP
A new tab opens in the browser and you can see the RDP toolbar at the top.
Transfer files via HTML5 GW
In this section we will copy a file from our workstation to the remote machine via the
HTML5 Gateway.
3/15/2022
Grab the tab and move it to create a separate window from your PVWA session.
Then reduce the PVWA window and resize the RDP window so that you can see the
desktop of the COMPONENTS server, as shown in the image below.
On your COMPONENTS desktop, you will find a file named 2-TRGT-WIN.txt. Drag
and drop this file into the browser RDP window.
You should be able to see the following message stating that the file has been copied
to the mapped drive Z on COMPONENTS, which you can view on the remote
machine TARGET-WINDOWS. Click on Close.
3/15/2022
Lastly, copy the file from the Z on COMPONENTS drive that was created on the
target machine to the desktop on TARGET-WINDOWS.
Now we are going to copy a file in the other direction, from the remote machine back to our
workstation.
Still working in the browser RDP window (so on TARGET-WINDOWS), make a copy
of the file named 2-TRGT-WIN.txt that is now on the Desktop of TARGET-
WINDOWS, and name it 2-COMP-SRV.txt.
Next, open the Download directory Z on COMPONENTS. Drag and drop the 2-
COMP-SRV.txt. file that is on the desktop of the TARGET-WINDOWS into the
Download directory. The file should be automatically downloaded to the local
workstation using the browser download. You should then be able to find the file in
the Downloads folder your the local workstation (that is, the Components server).
3/15/2022
When you are finished, disconnect from the target server.
Connect using PSM Ad-Hoc Connection
Next, you will configure a PSM Ad-Hoc Connection (previously known as Secure
Connect), which allows you to launch a PSM connection using unmanaged accounts.
First, log into the PVWA as mike, and go to ADMINISTRATION -> Platform
Management.
Select PSM Secure Connect and activate it.
Hint: PSM Secure Connect is at the bottom of the list.
Go to POLICIES -> Master Policy.
In the Session Management section, select Require privileged session monitoring

and press Add Exception.
Select PSM Secure Connect and press Next.
Select Active and press Finish.
Now go to the ACCOUNTS page and click on Ad-Hoc connection.
3/15/2022
Platform PSMSecureConnect
Client: WinSCP
Address: 10.0.0.20
User Name: root01
Password: Cyberark1
Map Local Drives: Checked
(scroll down)
Port 22
Press Connect.
3/15/2022
Press Connect to accept the connection.
Press Yes to accept the host’s RSA key.
Optional: When you have connected to WinSCP, copy a file from the PSM server to
the target machine.
Suggestion: C:\Add-Accounts\accounts-Linux.csv.
3/15/2022
Note: The Ad-Hoc connection will open in the browser unless you disable the HTML5GW.
If you want to launch the connection using an RDP file, go to OPTIONS ->
Privileged Session Management -> Configured PSM Servers -> PSMServer ->
Connection Details -> PSM Gateway, and set Enable to No.
Press F10 to exit and quit the application.
Privileged Session Manager for Windows
PSM for Windows (previously known as “RDP Proxy”) enables users to connect through
PSM to any remote target securely with a standard remote desktop client application like
mstsc or an RDP connection manager.
You can also use preconfigured RDP files. When using RDP files, you can configure a
single RDP file to connect through PSM without providing the target system details or
configure separate RDP files that include the target system details in advance. In this
exercise we will look at both options for using preconfigured RDP files.
Connect using RDP file without providing the target system details:
In the first example, we will use a preconfigured RDP file without providing the target
system details in advance.
On the desktop of the Components server, you will find an RDP file titled PSM for
WIN.
Double click on the file. If prompted, click on Connect.
3/15/2022
You may receive a certificate warning. Just click Yes to accept the certificate.
Vault username: John

Password: Cyberark1
3/15/2022
Next, input the target system details:
User Name: localadmin01

Address: target-win.acme.corp
Lastly, specify PSM-RDP as the connection type:
3/15/2022
Confirm you were able to connect to the target system as localadmin01. Then
disconnect from the target system.
Connect using RDP file with the target system details
In this example, we will use a preconfigured RDP file that includes the target system
details in advance. Perform the following steps:
Right-click to open the PSM for WIN RDP file for edit using Notepad++.
Scroll to the bottom of the file. Note the two different alternate shells in the file. One
is commented out, the other is active.
3/15/2022
Edit the RDP file as follows to switch the active shells. This will include the target
system details in advance. The two lines should appear as below:
alternate shell:s:psm /u localadmin01 /a target-win.acme.corp /c PSM-RDP

# alternate shell:s:psm
Save the file and exit Notepad ++.
Double click on the RDP file to launch the connection. If configured properly, you will
be prompted only for the Vault user credentials. After you authenticate as John, the
connection to the target machine as localadmin01 should be made automatically.
Note: You can use any RDP client application to connect to any target system via the
PSM. When setting up your RDP client, make sure to input the following details:
- PSM Address
- Vault username
- RDP Start Program setting
For more details on configuring RDP clients, please review the online
documentation.
Privileged Session Manager for SSH
PSM for SSH (previously known as PSM SSH Proxy or PSMP) is designed to provide a
native Unix/Linux user experience, connecting to any SSH target.
On the Components server, open PuTTy. You can find a shortcut for PuTTy in the
task bar.
3/15/2022
Use the following connection string to connect to the Target Linux machine using the
logon01 account where the Vault user is Carlos.
Carlos@logon01@10.0.0.20@psm-ssh-gw.acme.corp
Hint: To be able troubleshoot easily, make sure you mark “Never” under “Close window
on exit”
Click Yes to accept the server’s host key:
3/15/2022
When prompted for a password, enter the password for Carlos (password:
Cyberark1)
Execute a few simple, non-destructive commands (remember, you are a privileged

user) such as pwd and ls -al to generate some session activity. When you are
done, enter exit and hit Enter to close the session.
3/15/2022
Privileged Session Management – Part 2

In this section, we are going to look at some of the audit information that was gathered by
CyberArk PAM during our PSM testing. We will also be monitoring live sessions and test
session termination and suspension. To do so, we will need to connect as a user who is a
member of the Auditors group – Cindy.
PSM Session Terminators
As mentioned, we will be testing live monitoring, as well as session suspension and

session termination. While all members of the Auditors group can monitor live sessions,
not all members of the Auditors group have permissions to terminate or suspend sessions.
Only users who are also members of the built-in PSMLiveSessionTerminators group have
permissions to do so. For your convenience, Cindy, the ACME corporation auditor, has
been pre-added to this group.
Monitor, Suspend, and Terminate Active Sessions
Login to the PVWA as John and open a privileged session using the localadmin01
account via the PSM.
Logout of the PVWA (or use incognito mode) and login in via LDAP as Cindy.
Go to the MONITORING pane.
3/15/2022
Go to Active Sessions and locate the session opened by John and click on Monitor.
You should now be able to monitor John’s session as it happens.
As Cindy, try to Monitor, Suspend, Resume, and ultimately Terminate the session.
Note: Not all members of the Auditors group can terminate, suspend, or resume sessions.
These permissions are only available to users who are also members of the internal
PSMSessionTerminators group.
3/15/2022
Monitor Recordings
As Cindy, verify that you can see the recordings related to your prior sessions and try
to play some of these recordings. Note that recordings related to PSM for SSH are
presented in the classic UI.
You can also search recordings by activities in a privileged session. For example,
enter salary in the Session activities field and press Apply. Once you locate the
SQL recording, click on Play.
Review the recording. Click on the session line for more detail and find the command
“select * from scott.salary”. Note that the recording will now start at the command
selected. Close the playback window when you are done.
3/15/2022
3/15/2022
Privileged Threat Analytics

In this section, we will be looking at the CyberArk Privileged Threat Analytics (PTA)
component. Both the target Linux and Windows servers have been configured to forward
security information to the PTA.
We will be looking at:
• Unmanaged privileged access
• Suspected credential theft and automatic password rotation
• Suspicious password change and automatic reconciliation
• Suspicious activities in a session and automatic suspension
• Security rules exceptions
Note: Because the PTA server can become unpredictable in the Skytap environment if it
gets suspended, it has been configured not to start automatically. To perform these
next steps, you will need to start your PTA server manually in Skytap.
First, power on the ptaserver VM using the play button in Skytap.
Once the server is up and running, login to the PVWA as mike and navigate to the
System Health pane. Confirm the PTA is now connected and that two targets are
being monitored.
3/15/2022
Detections and Automatic remediation for UNIX/Linux
Unmanaged Privileged Access
In this section you will observe how the PTA detects when privileged accounts are being
used and then check if they are being managed by CyberArk. If the account is not
managed, the PTA will generate a security event and add the account to the list of
Pending Accounts. The Vault Administrator can then onboard the account to the relevant
safe. Automatic Onboarding Rules can also be applied.
First, we need to establish an SSH session to the target Linux server to create an event on
the PTA, which we will review using the Security pane in the PVWA.
Open PuTTy from the Components server and open an SSH session to Target
Linux as root02 (password: Cyberark1).
3/15/2022
Login to the PVWA as mike and go to Security -> Security Events and verify that
you can see the “Unmanaged privileged account” alert related to root02.
Note: “root.*” is defined by default as a privileged user in the PTA. You can add other
usernames (using regular expressions) that should also be detected by the PTA as
privileged accounts to be managed by CyberArk PAM. To add additional
usernames to the PTA administrative interface and go to SETTINGS -> Privileged
Groups and Users.
Go to Accounts Feed -> Pending & Discovery. Select root02 from the list (use
“Refine By” to search for the account if needed) and click on Onboard Accounts.
3/15/2022
Onboard the account to the Lin-Fin-US safe and associate the account with the LIN
SSH 30 platform.
Enter “Cyberark1” as the default password.
You should also return to Security -> Security Events and close the Security event
now that it has been dealt with.
3/15/2022
Note: You may notice that there are also other Unmanaged privileged access events
related to accounts that are managed in the Vault. This is because the PTA has not
been made aware of those accounts yet. The PTA has a task that is scheduled to
run once a day by default to retrieve the account list from the Vault. We have
configured the PTA in this lab to run the task every minute, which means that any
account you now onboard, will be recognized by the PTA almost immediately. Feel
free to close the other Unmanaged privileged access events, as they are a false
positive in our case.
Suspected Credential Theft and Automatic Password Rotation
In this section, you will configure the PTA to detect when privileged accounts are being
used without first retrieving the password from CyberArk PAM and trigger the CPM to
initiate a password change.
Login to the PVWA as Paul and go to POLICIES -> Safes. Select the Lin-Fin-US
safe and click on Members.
Click on Add Member and search for the PTAUser in the Vault. Select the PTAUser.
Keep the default permissions and expand Account Management. Select “Initiate
CPM account management operations” and click on Add.
3/15/2022
Repeat the above step to add the PTAAppUser to the Lin-Fin-US safe as well
(including the “Initiate CPM account management operations” permission).
Close and exit from your putty session to 10.0.0.20 if it is still open.
Once again, open PuTTy from the Components server and open an SSH session to
Target Linux as root02 (password: Cyberark1).
3/15/2022
Login to the PVWA as mike and go to Security -> Security Events and verify that
you can see the “Suspected Credentials Theft” alert related to root02.
Open the Activities tab for the root02 account to verify that the CPM changed the
password after the PTA detected the suspected credential theft alert and under
Activities added the relevant file category for Immediate Change.
3/15/2022
Note: To detect Suspected Credential Theft, the PTA compares the login time on the
target machine with the last time the password was retrieved from the Vault. By
default, the PTA creates a Suspected Credential Theft event if the password was
not retrieved within the last 8 hours. For this lab, we have configured the PTA to
raise an alert if the password was not retrieved within the last 2 minutes.
Suspicious Password Change and Automatic Reconciliation
In this section you will configure the PTA to detect when a password is being changed
manually, bypassing the CPM, and have the PTA trigger the CPM to reconcile the
password.
For this exercise to work, you must associate a reconcile account with root02.
Note: If you performed the optional exercise on SSH key, you can use the root01 account
you created previously. If you have not already added the root01, do so now,
creating it as a normal password account (exactly like logon01).
Login to the PVWA as Paul and go to Accounts -> Accounts View and select the
root02 account. Click on Details then in reconcile account, click the […] then Link.
Select root01 as the reconcile account and click OK to link the account.
3/15/2022
Go to Accounts -> Accounts View and select root02 again and launch an SSH
connection via the PSM.
Type the following command to change the password of root02 back to Cyberak1:
passwd root02
Go back to the PVWA as mike and go to Security -> Security Events. You should
be able to see two new alerts. One for a “Suspicious activities detected in a
privileged session”, and one for “Suspicious password change”. Verify that you
can see the “Suspicious password change” alert and that an automatic password
reconciliation was initiated.
3/15/2022
Go to Accounts -> Accounts View and select root02. Verify that root02 has been
reconciled by the CPM.
Suspicious Activities in a Session and Automatic Suspension
In this section you will configure the PTA to detect when a risky command is used in a
privileged session and to suspend the session automatically.
Login to the PVWA as mike and go to Security -> Security Configurations ->
Privileged Session Analysis and Response. Find the SSH passwd command (the
command is used to change the password manually) and click on Edit.
3/15/2022
Configure the risk to a Score of 90 and the Session response to Suspend. Click on
Save.
3/15/2022
Log in to the PVWA as Paul and go to Accounts -> Accounts View and select the
root02 account. Launch a privileged session by clicking on the connect button.
After the session opens, try to run the passwd root02 command again. The
session should be suspended immediately, and a message should appear letting the
user know the session is suspended.
Login to the PVWA as Mike. Go to Security -> Security Events and verify you can
see the “Suspicious activities detected in a privileged session” alert. Verify that
the session got a score of 90.
Login to the PVWA as Cindy (our auditor) and go to the Monitoring pane. You will
see Paul’s connection in Active Sessions with the options to Terminate, Suspend,
Resume, or Monitor the session. If you had already closed the session, you would
be able to play the recording.
3/15/2022
Security Rules Exceptions
In this section, we will tweak the rule we created in the last section so that if a designated
user needs to execute passwd during a session, their session will not be suspended out.
Log into the PVWA as mike and go back to Security -> Security Configurations,
select the passwd rule and click the Edit button.
To create an exception to the rule, click on Change scope.
3/15/2022
Enter the username Paul in the field, hit Enter, and then click the Change Scope
button. You will then be returned to Edit Rule dialogue. Click Save to close the
dialogue.
To test the rule, you can log in to the PVWA as the user Paul, connect using any of
the accounts in the Lin-Fin-US safe, and run the passwd command. Your session
should not be suspended. Try the same with Carlos. This time your session should
be suspended as before.
Detections and Automatic Remediation for Windows
Unmanaged Privileged Access
In this section you will observe how the PTA detects when a Windows account is being
added to a privileged group and then checks if the account is being managed by
CyberArk. If the account is not managed, the PTA will generate a security event and add
the account to the list of Pending Accounts.
Unlike the previous example, in this case the account is detected by the PTA as soon as
the account is granted privileged permissions, allowing PTA to respond and take control
over this unmanaged privileged account. This solution shortens the time it takes to detect
an attacker or a malicious insider who attempts to create a backdoor account, bypassing
the organizational policy.
First, login to the PVWA using LDAP authentication with John.
3/15/2022
Locate the localadmin01 account on target server target-win.acme.corp and click on

Connect.
As localadmin01 on the target server, open Computer Management and navigate to

Local Users and Groups -> Users. Right-click on Users and select "New User…".
Add a new user called backdoor. Set the password to Cyberark1 and select
Password never expires. Then click on Create.
3/15/2022
Right-click on the newly added user and select properties. Go to the Member Of tab
and click on Add…
Type "Administrators" and then Check names…. Click on OK to add the backdoor
user to the local Administrators group.
3/15/2022
Log into the PVWA as mike and go back to Security -> Security Events. After about
20 seconds or so, you should be able to see a new Security Event for Unmanaged
Privileged Account, notifying the CyberArk Security administrator that an account
called backdoor, which is not managed by CyberArk, was added to the local
privileged Administrators group.
On the left navigation select Accounts, then go to Accounts Feed -> Pending &
Discovery. Select backdoor from the list (use “Refine By” to search for the account if
needed) and click on Onboard Accounts.
3/15/2022
Onboard the account to the Win-Srv-Fin-US safe and associate the account with the
WIN SRV LCL ADM 45 platform. Choose to Automatically reconcile the password
to take full control of the backdoor account. Click on Onboard.
Verify that the backdoor account has been reconciled by the CPM.
3/15/2022
Suspicious Activities in a Windows Session and Automatic Suspension
In this section you will configure the PTA to detect when a risky command is used in a
Windows privileged session and to suspend the session automatically. We will use this
ability to prevent malicious users from adding another backdoor account.
Login to the PVWA as mike and go to Security -> Security Configurations ->
Privileged Session Analysis and Response. Click on "Add rule".
3/15/2022
Under Category select Windows titles. Under Pattern enter:
(.*)New user(.*)
Under description enter: "Prevent malicious insiders from adding a backdoor user".
Set the risk score to 80 and set the session response to Suspend. Then click on
Add.
Login to the PVWA as John. Launch another privileged session as localadmin01 on

target server target-win.acme.corp. Try to add a second backdoor user. If the above
steps were configured successfully, the system should suspend your session,
preventing you from adding another backdoor user.
3/15/2022
Login to the PVWA using LDAP authentication as mike. Go to Security -> Security
Events and verify you can see the “Suspicious activities detected in a privileged
session” event. Verify that the session got a score of 80.
3/15/2022
Click on Resume to re-activate the suspended session.
Connect to the PTA Administration Interface
The PTA has a separate administration interface that is used for initial configuration and
can be used to monitor threats and run reports.
In our environment, you can access the PTA Administration interface with the
following information. There is a shortcut for the PTA in the bookmarks bar:
Address: https://ptaserver.acme.corp
User name: administrator
Password: CyberArk1234
3/15/2022
When you log in, you should see information related to the activities we performed
earlier.
3/15/2022
Reports
In this section you will be asked to create three types of reports.
Generate “Privileged Accounts Inventory” report
Login to the PVWA as mike and go to the Reports pane.
Click on Generate Report.
Click Next to generate the “Privileged Accounts Inventory” report.
Review the options to filter the report, but keep the default values, then click Next.
3/15/2022
Click Finish to generate the report.
Select the refresh icon at the bottom of the page until the report status shows
“Done”. Open the report by clicking on the Excel icon.
Click OK to open with the default LibreOffice Calc.
3/15/2022
After going over the report, save the new report to the desktop of the Components
server. If you are asked if you want to save the document in its current format, click
Keep Current Format.
Generate “Safes List” Report and “Users List” report
On the Components server, open the PrivateArk Client and login as Mike (using
LDAP authentication)
Under Tools -> Reports, click on Safes List to generate a safes list report
3/15/2022
Click the Report Output tab and save the new report to the desktop of the
Components server.
Open the LibreOffice Calc application (you can use the search functionality to easily
locate the app).
3/15/2022
Use LibreOffice Calc to open the SafesList report file on your desktop. Under
“Separator options” choose Separated by: Comma. Click OK.
3/15/2022
After reviewing the report, save a copy of the report to the desktop of the
Components server.
Select Use Text CSV Current Format.
Repeat these steps creating a Users List report and copy the report to the desktop
of the Components server.
By the end of this exercise, you should have 4 reports on the desktop. These reports
are “Privileged Accounts Inventory”, “Safes List”, “Users List”, and “Locations”.
Generate reports using EVD
In this section we will use the Export Vault Data (EVD) utility to generate reports. The
EVD utility exports data from the Vault to TXT or CSV files, from where they can be
imported into third-party applications or databases. Each report is saved in a different file.
Additional information about using EVD can be found in the online documentation.
Enable the Auditor user
First, we will enable the built-in Auditor user. Login to the PrivateArk Client as
Administrator (using PrivateArk authentication).
Locate the built-in Auditor user and click on Update.
3/15/2022
Untick the box for Disable User.
Go to the Authentication tab and set the password to Cyberark1.
Click on OK, then Close, and finally logoff the PrivateArk Client.
3/15/2022
Create the Cred file
Now using Windows Explorer, go to C:\ExportVaultData.
Open the Vault.ini file using notepad and set the Vault IP address: 10.0.10.1. You
may also change the Vault name to "Primary" or “Primary Vault” (but it is not
mandatory).
Save the Vault.ini file and close it.
Open a command prompt. Change directories to c:\ExportVaultData\CreateCredFile

and run the following command to generate a credential file:
CreateCredFile.exe auditor.cred
Set the following parameters according to the below:
Vault Username [mandatory] ==> Auditor

Vault Password (will be encrypted in secret file) ==> Cyberark1
Disable wait for DR synchronization before allowing password change (yes/no)
[No] ==> yes
Run the utility in unsecure mode (yes/no) [No] ==> yes
For all other parameters, you can simply hit the Enter button to accept the default
values. Your command output should look like the following:
3/15/2022
Export Vault Data
Now we are ready to run the report.
Change directories to c:\ExportVaultData:
cd ..
Now run the following command:
ExportVaultData \VaultFile="C:\ExportVaultData\Vault.ini"
\CredFile="C:\ExportVaultData\CreateCredFile\auditor.cred" \Target=File
\LogNumOfDays=4 \LogList="C:\ExportVaultData\loglist.csv"
Note: It might be helpful to type this long command into a text file and then copy and paste
it into the terminal window. Also note that the path to the credential file auditor.cred
is different from the path to the Vault.ini file because we generated it in a sub-
directory.
3/15/2022
Note: The above example will create a log activity report for the Vault defined in
the Vault.ini file in C:\ExportVaultData. The user who will access the Vault to
generate this report is defined in the auditor.cred file in C:\ExportVaultData. The log
activities report will be saved in a file called loglist.csv. The log is generated for the
preceding 4 days.
A new file called loglist.csv was generated in the C:\ExportVaultData folder. Review
the file using LibreOffice Calc to see the Activities log report generated by EVD.
3/15/2022
Backup and Restore

In this section, you will use the Replicator utility to test backup and restore of the Vault
data. Like all the other components, the Replicator utility has already been installed in
your environment by the implementation team.
In this exercise we will be using two CyberArk built-in users. The first user is Backup,
which has permissions to backup all safes. We will use Backup to execute the back up of
all safes. The second user is Operator, which has authority to restore all safes. We will
user Operator to restore a safe. These two users are disabled by default, so for this
exercise you will need to enable both users in your environment in the same way we did
for the Auditor user in the previous exercise. Set the password for both users to
Cyberark1 for ease of use.
Configure the CyberArk Replicator Utility
Configure the Vault.ini file
On the Components server, open Windows File Explorer and go to C:\Program

Files (x86)\PrivateArk\Replicate.
Note: If prompted, click Continue to get access to the folder.
Double-click the Vault.ini file.
In the Vault.ini file, enter “Primary Vault” for the VAULT parameter (although this is
not mandatory).
3/15/2022
Enter the IP address of your Vault server in the ADDRESS parameter: 10.0.10.1
VAULT = “Primary Vault”

ADDRESS=10.0.10.1
PORT=1858
Save and close the file.
Locate the output directory – tsparm.ini
In the same directory, open the file tsparm.ini and note the output location of the backup.
Create the credential file – backup.cred
This process is almost identical to the credential file generation that we performed in the
preceding exercise. In this case, the CreateCredFile.exe is in the same directory as
Vault.ini.
Open a command prompt and change directories to the Replicate folder:
cd “c:\Program Files (x86)\PrivateArk\Replicate”
Run the following:
CreateCredFile.exe backup.cred
Vault Username [mandatory] ==> backup
Vault Password…==> Cyberark1
Disable wait for DR synchronization before allowing password change (yes/no)
[No] ==> yes
Run the utility in unsecure mode (yes/no) [No] ==> yes
Set the parameters according to the values given above.
3/15/2022
Run a Backup
Note: Make sure you have enabled the Backup user (and set the password to Cyberark1)
prior to running the backup command. The process is identical to enabling the
Auditor user performed earlier. The Backup user is located under the System
branch.
To perform a backup, run the following command from the Replicate folder:
PAReplicate.exe vault.ini /logonfromfile backup.cred /FullBackup
If the backup is successful, you should see several messages indicating that files are
being replicated with a final message stating that the replication process has ended.
If the replicate was successful, proceed to the next steps. If not, verify the configuration
information and try again.
3/15/2022
Delete the TEST Safe
In this exercise, we will delete a safe that we will later restore from the backup made in the
previous exercise.
Login to the PVWA as Mike and search for root10 account (stored in a safe called
TEST).
Next, go to POLICIES -> Safes.
Select TEST and click the Delete button.
You will receive a prompt asking you to confirm deletion. Press Delete to confirm
that you would like to delete the safe and contents.
Lastly, you will receive a message stating that the safe cannot be deleted due to safe
retention rules. The safe has not been permanently deleted, but it has been removed
from usage. Click Close.
3/15/2022
To confirm that the contents of the TEST safe have been removed go to the
Accounts page.
Enter root10 in the search box and press the Search button.
The root10 account that you were able to locate earlier, should not appear.
Run a Restore
In this section, we will restore the TEST safe from the backup we performed earlier.
Because the TEST safe has not been permanently deleted, we will restore the contents of
the safe to a new safe named TEST-RESTORE.
Note: Make sure you have enabled the Operator user (and set the password to
Cyberark1) prior to running the restore command. The process is identical to
enabling the Auditor user performed earlier.
Note: The Operator user is located under the System branch.
3/15/2022
Go back to the command prompt, making sure you are still in the Replicate directory,
and run the following command:
PARestore.exe vault.ini operator /RestoreSafe TEST /TargetSafe TEST-RESTORE
You will be prompted for the password for the Operator user, which should be
Cyberark1.
Once you see the message that restore has been completed, go back to the PVWA
(as Mike) and search for root10 again. You should now see the root10 account using
address 10.0.0.21, residing in safe TEST-RESTORE.
Note: The Target Safe (TEST-RESTORE) is the name of the restored Safe. The restore
process will not overwrite an existing Safe, so we must create a new one.
3/15/2022
Disaster Recovery
In this section we will test the Disaster Recovery (DR) procedures for automatic failover
and manual failback. The exercise will include the following steps:
1) First, we will configure the Disaster Recovery module on the DR server to perform
an automatic failover in case the Primary Vault is no longer reachable.
2) We will execute a full replication from the Primary Vault to the DR Vault.
3) We will test an automatic failover from the Primary Vault to the DR Vault. As part
of the test, we will also confirm that our end users can still access critical systems
via CyberArk, without any human intervention.
4) We will set the Primary Vault to act as DR and replicate all data back from the DR
Vault to the Primary Vault.
5) We will then perform a manual failback from the DR Vault to the Primary Vault
6) Lastly, we will set the DR Vault back to DR mode and confirm our end users are
still able to connect to critical systems via CyberArk.
Note: The below steps have already been performed by the implementation team:
The PrivateArk Server, PrivateArk Client, and Disaster Recovery module have all
been installed on both your vault01a and DR servers by the implementation team.
A second DR user called “DR_Failback” was manually created by the

implementation team during the deployment of the Primary Vault for the purpose of
supporting the failback procedure from the DR site back to the primary site.
However, both the DR and DR_Failback users are currently disabled. You will need
to enable these users to complete the Disaster Recovery exercises.
Step 1: Enable Automatic Failover on the DR Vault
As noted above, the implementation team has already installed the PrivateArk Server,
PrivateArk Client and Disaster Recovery service on the DR server. However, to avoid
an unwanted automatic failover during the first days of the course, automatic failover was
disabled, and the DR user deactivated. We are now going to enable the DR user and
Automatic Failover to the DR Vault.
On the Components server, connect as the Administrator user with the PrivateArk
Client to the Primary Vault and enable the DR user.
3/15/2022
Note: Do NOT change the password as the DR user has already authenticated to the
Vault during initial implementation and the password for the user has already been
rotated. If you change the password to Cyberark1, you will need to create a new
cred file as well. The DR user is located under the System branch.
Next, power on the 08-DR server. Remember, it will take a moment for the machine
to start.
Sign into Windows on the DR server as Administrator.
Open the file explorer and navigate to C:\Program Files (x86)\PrivateArk\PADR\Conf.

Double click on the padr.ini file to edit it with Notepad.
3/15/2022
Change the EnableFailover setting to Yes and delete the last two lines of the file (if
present). This will trigger a full replication when we restart the Disaster Recovery
service, ensuring we have the most up-to-date data.
Note: Notice FailoverMode is currently set to No. Do NOT change this setting. It will
automatically change later when we test the failover process.
Save the file and exit Notepad.
Step 2: Execute a full replication to the DR Vault
In this step, we will simply re-start the CyberArk Disaster Recovery service. In so doing,
the service will read the changes we made to the file PADR.ini.
On the DR server, open the Windows Services applet. There is a shortcut in the task
bar.
Restart the CyberArk Vault Disaster Recovery service.
3/15/2022
Now go to the desktop. Right click on the Get-DR-log.ps1 file located on the desktop
and select Run with PowerShell.
Note: The above script will run a tail on the padr.log file located in C:\Program Files
(x86)\PrivateArk\PADR\logs\ folder. The tail will allow you to monitor the actions
performed by the Disaster Recovery service in real time. If you are prompted to
allow running the script, select Yes.
Confirm the Disaster Recovery module has completed the replication of data from the
Primary Vault. You should see entries with informational codes PAREP013I
Replicating Safe and at the end, PADR0010I Replicate ended.
Note: Keep the tail running for the remainder of the exercise.
Back on the Components server, login to the PVWA as Mike. Navigate to SYSTEM
HEALTH to review the current system health. Note that currently Vault 10.0.10.1 is
considered PRIMARY while Vault 10.0.14.1 is considered DR.
3/15/2022
Step 3: Execute Automatic Failover Test
Now, we will execute an automatic failover test by stopping the Primary Vault server. If
everything works as expected the Disaster Recovery module on the DR server will
recognize that the Primary Vault is offline and trigger an automatic failover.
Sign into Windows on the Primary Vault server (Vault01A) as Administrator.
Open the Server Central Administration app and stop click on the red traffic light to
stop PrivateArk Server service.
Once the Primary Vault has stopped, return to the console of the DR Server.
Monitor the the tail on the padr.log file. You should see messages stating that the
Disaster Recovery service is unable to reach the Primary Vault.
3/15/2022
Note: If you are not seeing new entries in the log file after a few minutes, press Enter. If
you are still not seeing new entries, close the PowerShell window and run the script
again.
After 5 failures, the DR Vault will go into failover mode (this is the default setting).
Check the padr.log and review the sequence of events.
Note: The entire process should take around 5 minutes.
Confirm Automatic Failover on the DR Vault
On the DR server (10.0.14.1), open the Windows Services applet and confirm the
CyberArk Vault Disaster Recovery service has terminated.
3/15/2022
Confirm the PrivateArk Server service is now running on the DR server (10.0.14.1).
Confirm Automatic Failover of PVWA and PSM
In this section we will confirm our end users (like John) can still access critical systems via
CyberArk, even though the Primary Vault is offline, without human intervention.
Note the implementation team has already configured the PVWA and PSM to
automatically failover to the DR Vault when the Primary Vault is no longer available. To
support automatic failover, the Vault.ini file for both services has been configured with the
IP addresses of both the Primary Vault and the DR Vault separated by a comma.
Here you can see the configuration of the PVWA Vault.ini file:
3/15/2022
To confirm that both the PVWA and PSM automatic failover was successful, return to
the console of the Components server.
Open Chrome and verify that you can still login to the PVWA as John, even though
the Primary Vault is offline.
Now, verify you can launch a secure session to the target Windows machine using
the localadmin01 account via PSM. If everything worked as expected, John should
still be able to access the target server via CyberArk, without any human
intervention.
Note: You may need to try to launch the connection via PSM a couple of time before it
works, as it may take a few minutes before the PSM fails over to the DR Vault.
Step 4: Execute a full replication back to the Primary Vault
Before we failback to the Primary Vault we must first make sure we replicate all the latest
data from the DR Vault (which served as the active Vault for the duration of resolving the
incident). In this section we will use the Disaster Recovery module on vault01a to
replicate data back from the DR Vault to the Primary Vault.
Note: The implementation team has already installed the Disaster Recovery module on
vault01a, and manually created a separate DR user for the purpose of performing
replication from the DR Vault back to the Primary Vault.
The new user is called DR_Failback, and has been made a member of the built-in
group DR_Users. The user was assigned the following Vault authorizations: Backup
All Safes and Restore All Safes.
From Components, use PrivateArk Client to connect to the DR Vault and enable
the user DR_Failback.
3/15/2022
Note: Do NOT change the password as the DR_Failback user has already authenticated
to the Vault during initial implementation, and the password for the user has already
been rotated. If you change the password to Cyberark1, you will need to create a
new cred file as well.
Note: the DR_Failback user is located under the System branch.
Open the console on vault01a (10.0.10.1).

Make the following changes to the padr.ini file on vault01a:
• Set FailoverMode to No.
• Delete the last two lines (log number and timestamp of the last successful
replication) in the file.
Note: The above changes will trigger the Disaster Recovery module on the Primary Vault
to perform a full replication of the data from the DR Vault once the service is
restarted.
Save the file and close it.
Start the ‘CyberArk Disaster Recovery’ Service on the Primary Vault.
3/15/2022
Right click on the Get-DR-log.ps1 file located on the desktop of the vault01a and
select Run with PowerShell.
Note: If you are prompted to allow running the script, select Yes.
Monitor the tail of the padr.log to verify that the Primary Vault has replicated all the
changes from the DR Vault.
On the Components server, login to the PVWA as Mike. Navigate to SYSTEM

HEALTH to review the current system health. Note that now Vault 10.0.10.1 is
considered DR while Vault 10.0.14.1 is considered PRIMARY.
3/15/2022
Note: Contrary to the PVWA and PSM, the CPM is not configured to perform an
automatic failover, which is why it is showing as disconnected in the image above.
This is to avoid the situation of split brain between the two Vaults. To support
password rotation in the DR site, we will need to manually failover the CPM to the
DR Vault (by setting the DR Vault IP address in the vault.ini file of the CPM). We
will not perform manual failover for the CPM in this exercise.
Step 5: Execute failback procedure by using Manual Failover
Now that all the data has been replicated back from the DR Vault to the Primary Vault,
we can proceed with performing a manual failback from the DR Vault to the Primary
Vault. The failback procedure will be performed using a Manual Failover.
Make sure you are working on vault01a (10.0.10.1).

Set ActivateManualFailover to Yes.
3/15/2022
Save the file and close it.
Restart the CyberArk Disaster Recovery service on vault01a (10.0.10.1). The

service should start and stop immediately (because of the ActivateManualFailover
setting). Then the PrivateArk Server service should start.
Important: The above steps are critical for a successful failback from the DR Vault to the
Primary Vault. Reverting to the Primary Vault without first performing a proper
failover can result in data inconsistencies.
Confirm Manual Failover on the Primary Vault
Monitor the tail running on the padr.log file on vault01a (10.0.10.1). Confirm you can
see the messages stating that the Failover process ended successfully, that the Vault
service is starting, and that the Disaster Recovery service has terminated.
Verify that the the CyberArk Vault Disaster Recovery service has terminated on
vault01a (10.0.10.1).
3/15/2022
Verify that the PrivateArk Server service has started successfully on vault01a
(10.0.10.1).
Step 6: Set the DR server back to DR mode
In the last section of this exercise, we will set the DR server back to DR mode.
Return to the console of DR (10.0.14.1).
On the DR server, edit the padr.ini file and make the following changes:
• Set FailoverMode to No.
• Delete the last two lines (log number and timestamp of the last successful
replication) in the file.
• Save and exit the file.
3/15/2022
Using the Windows Services applet, stop the PrivateArk Server service on DR
(10.0.14.1).
Note: Click Yes to stop the Cyber-Ark Event Notification Engine service as well.
Then, start the CyberArk Vault Disaster Recovery service on DR (10.0.14.1).
3/15/2022
Check the tail running on the padr.log file on the DR server (10.0.14.1) and confirm
that a full replication process started and that the replication (from the Primary Vault
to the DR Vault) has ended succesfuly.
Confirm Automatic Failover for PVWA and PSM
In this step we will confirm that our end users can still access critical systems via
CyberArk.
Login to the PVWA as John and launch a secure connection to the target Windows
machine using the account localadmin01. If everything works as expected, John
should be able to launch the secure connection without any human intervention.
3/15/2022
Lastly, login to the PVWA as Mike and navigate to SYSTEM HEALTH. Confirm
server 10.0.10.1 once again acts as PRIMARY and server 10.0.14.1 acts as DR.
Confirm all other components are connected.
Note: It may take a little longer for the PSM for SSH service to failover, but eventually it
should failover to the functioning Vault.
Important: Due to some limitations in our lab, it is important to disable both the DR and the
DR_Failback users (using the PrivateArk Client) until the time you want to work
again on the disaster recovery exercise.
3/15/2022
Common Administrative Tasks
Rotating CPM Logs
The CPM log files can be automatically uploaded to a Safe in the Vault according to a
predefined period in the CPM parameters file. Each time a log file is uploaded to the
Vault, it is copied to the History subfolder in the Log folder, and the CPM begins writing to
a new log file.
Log into the PVWA as mike and go to ADMINISTRATION -> Configuration

Options.
You should see that PasswordManager is already selected as the CPM. If there
were multiple CPMs you would select the appropriate CPM from the pulldown list.
Click CPM Settings.
3/15/2022
Select Configuration -> General and scroll down to set the following parameters.
LogCheckPeriod: 1
LogSafeName: CPM_Logs
Click OK.
Create a safe called CPM_Logs and assign PasswordManager as the assigned

CPM.
Modify the Members list to add the Vault Admins group.
Grant the Vault Admins group all safe permissions.
The Vault Admins group will now be able to access the CPM logs.
3/15/2022
3/15/2022
Optional Exercises
Just-in-Time (JIT) Access
A major step in the Privilege Access Management program is to secure the Windows local
administrators. This is essential to reduce the risk of lateral movement. CyberArk enables
securing local administrator credentials, as well as using PSM to access those accounts.
There are cases, however, where managing the local administrator passwords is not
possible at the initial stage of deployment, whether because of objection from the IT users,
or other reasons. Just-in-Time (JIT) access allows you to gain control over local
administrator security without inconveniencing administrative users. It can be used as an
intermediate step towards full implementation of Vaulting the local administrator accounts.
You can grant Windows admins on-demand, ad-hoc privileged access to Windows targets,
for a predefined number of hours (4 hours by default).
During this time, domain users can request to access a system as a local administrator. If
authorized, the system temporarily adds the logged-on Windows users into the target
system's local administrator group, without the need to manage the credentials of the local
administrator on that target. This allows for a frictionless and lightweight solution that
enables your organization to introduce privileged controls and help establish habitual
security, before moving into a robust PAM program.
The workflow, as exhibited in the following diagram, starts when an end user requests
access to a designated target machine and then is added to the local admin groups. The
end user is notified that they have been granted access (or not), and once granted, is able
to access the target machine using their own login for 4 hours (by default). After this
period, the user is automatically removed from the local admin group.
3/15/2022
Set up the JIT Access Platform
In this exercise, you will set up Just-in-Time access for the Windows admin user (John),
allowing John to be added to the local admin group on the target system for 4 hours.
Log into the PVWA as mike.
Go to ADMINISTRATION -> Platform Management and duplicate the WIN SRV

LCL ADM 45 Platform to a new platform called WIN SRV JIT. You may add a
description stating accounts associated with this platform are not managed by the
CPM.
Click on Edit to edit the new platform. In the new platform set the following
parameters to NO.
• UI & Workflows
• AutoChangeOnAdd
• Automatic Password Management -> Password Change
• AllowManualChange
• PerformPeriodicChange
• Automatic Password Management -> Password Verification
• VFAllowManualVerification
• VFPerformPeriodicVerification
3/15/2022
• Automatic Password Management -> Password Reconciliation
• RCAllowManualReconciliation
• RCAutomaticReconcileWhenUnsynched
In the new platform, go to UI & Workflows -> Properties. Remove the Username
property from Required, and add a new property called Username under Optional.
In the new Platform, right-click on Automatic Password Management, and select

Additional Policy Settings.
Under Additional Policy Settings, set AllowDomainUserAdHocAccess to Yes.
3/15/2022
You will see a pop-up dialog warning you to use the AllowedSafes parameter to limit
the use of this policy to only those Safes where it is appropriate. Click Yes.
Note: For JIT access, a domain account that has been configured as a reconcile account
should be associated with the platform. In our case, this has already been defined in
the base platform we duplicated: WIN SRV LCL ADM 45
Note: For security best practice, you need to limit the Safes that are required for ad hoc
access, by setting the AllowedSafes parameter with a regular expression that lists
the Safes that this platform can be applied to. This too has already been defined in
the base platform we duplicated: WIN SRV LCL ADM 45
Note: You can also set the time, in minutes, after which a user is automatically removed
from the Administrators group on the target machine. By default, the parameter is
set to 240 minutes (4 hours).
Add the Local Administrator Account
Go to Accounts View and click on Add Account. Add the local administrator
account of the Target Windows server:
3/15/2022
System Type: Windows

Assign to Platform: WIN SRV JIT
Store in Safe: Win-Srv-Fin-US
Address: target-win.acme.corp
User Name: Administrator
Password: Cyberark1
Logon To (optional): <click the Resolve button> TARGET-WIN
Test Just-in-Time Access
First, open MSTSC (you can use the search functionality to find the application).
Attempt to connect to target-win.acme.corp as acme\John.
3/15/2022
You should receive an error stating that John is not authorized for remote login:
Now, login to the PVWA as John. Search for the Target Windows local Administrator
account and click on Get Access.
If you configured everything successfully, you should receive a notification saying

you’ve been granted admin access for 4 hours.
3/15/2022
Now try to launch another RDP connection to the Target Windows server as
acme\John. You should be able to login this time.
After successfully connecting to the Target Windows server, go to Computer

Management -> Local Users and Groups -> Groups and open the local
Administrators group. Verify that acme\John was added to the group.
Disconnect from the Target Windows server.
3/15/2022
Custom File Categories
File category is the CyberArk term for the properties or fields available on accounts
(Address, User Name, etc.). This section will detail the steps required to create and use
custom file categories, allowing you to categorize accounts based your organization’s
requirements.
In this final exercise, we will create a custom file category called BusinessUnit and provide
a list of possible choices: International, Retail, and Corporate. We will then modify our
Oracle platform so that when users add new accounts, they will be required to associate
the new account with one of these business units. Finally, we will make the new
parameter searchable within the PVWA and, of course, we will test what we have done.
Creating the Custom File Category
On the Components server, from the PrivateArk Client, log onto the Primary Vault
as Administrator and go to File -> Server File Categories.
Press the New… button.
3/15/2022
In the Add File Category window, enter the following:
Name: BusinessUnit
Type: List
Valid values: International, Retail, and Corporate
After each value is added, select the Required Category checkbox and click OK and
then OK again to close the File Categories dialog box.
Log out of the PrivateArk Client.
3/15/2022
Adding the Custom File Category to the Platform
Now we’ll make the new BuinessUnit File Category a required field for accounts assigned
to the ORA DBA 30 platform.
Log into the PVWA as mike and go to the ADMINISTRATION tab and click Platform
Management.
Highlight ORA DBA 30 and press Edit.
Go to UI & Workflows -> Properties -> Required. Right-click and select Add
Property from the context menu.
Enter BusinessUnit in the Name field and then Business Unit – Select one in the
DisplayName field.
Press Apply and OK. This will make the parameter BusinessUnit a required field on
any accounts attached to the ORA DBA 30 policy, but will display a more helpful
name when they need to use it.
Making the File Category Searchable
Now we will make the new BusinessUnit file category searchable.
Go to ADMINISTRATION -> Configuration Options -> Options.
3/15/2022
Right-click on Search Properties and select Add Property.
Enter BusinessUnit in the Name field and press Apply and OK. This will allow the
new file category to be searchable.
Sign out of the PVWA session.
Testing the New File Category
Login to the PVWA as Robert.
Locate the account dba01, click on the ellipsis button, and select Edit.
3/15/2022
Under Additional Properties, you will see your new display name: Business Unit –
Select One. Select Retail and press Save.
Enter retail in the Search field on the ACCOUNTS tab and press Enter.
3/15/2022
dba01 should be returned based on the new file category.
3/15/2022

Pam Admin Exercise Guide Ilt

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

Pam Admin Exercise Guide Ilt

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pam Admin Exercise Guide Ilt

Uploaded by

Copyright:

Available Formats

CyberArk University

Privileged Access Management Administration

CyberArk University Exercise Guide page 1

INTRODUCTION TO CYBERARK PRIVILEGED ACCESS MANAGEMENT .................................................................... 13

GETTING TO KNOW THE ACME.CORP ENVIRONMENT...........................................................................................................13

USER MANAGEMENT ........................................................................................................................................... 38

KNOW THE PLAYERS .....................................................................................................................................................38

SECURING WINDOWS DOMAIN ACCOUNTS ......................................................................................................... 57

PLATFORM MANAGEMENT ............................................................................................................................................57

CyberArk University Exercise Guide page 2

SECURING UNIX SSH ACCOUNTS .......................................................................................................................... 75

VAULT ADMINISTRATOR TASKS – MIKE ............................................................................................................................75

SECURING ORACLE DATABASE ACCOUNTS ........................................................................................................... 93

VAULT ADMINISTRATOR TASKS .......................................................................................................................................93

LINKED ACCOUNTS .............................................................................................................................................. 98

SECURING SSH ACCOUNTS USING A LOGON ACCOUNT........................................................................................................98

SECURING UNIX ACCOUNTS WITH SSH KEYS ...................................................................................................... 108

DEPENDENTS – SECURING SERVICE ACCOUNTS / USAGES ................................................................................. 119

MANAGING A SCHEDULED TASK USAGE .........................................................................................................................119

CyberArk University Exercise Guide page 3

REQUIRE USERS TO SPECIFY REASON FOR ACCESS ..............................................................................................................133

DISCOVERY AND ONBOARDING ......................................................................................................................... 153

ACCOUNTS FEED ........................................................................................................................................................153

PRIVILEGED SESSION MANAGEMENT – PART 1 .................................................................................................. 170

Remove Privileged Access Workflows Exceptions ............................................................................................170

PRIVILEGED SESSION MANAGEMENT – PART 2 .................................................................................................. 190

PSM SESSION TERMINATORS .......................................................................................................................................190

PRIVILEGED THREAT ANALYTICS ........................................................................................................................ 194

CyberArk University Exercise Guide page 4

REPORTS ............................................................................................................................................................ 217

GENERATE “PRIVILEGED ACCOUNTS INVENTORY” REPORT..................................................................................................217

BACKUP AND RESTORE ...................................................................................................................................... 227

CONFIGURE THE CYBERARK REPLICATOR UTILITY..............................................................................................................227

DISASTER RECOVERY.......................................................................................................................................... 233

STEP 1: ENABLE AUTOMATIC FAILOVER ON THE DR VAULT ................................................................................................233

COMMON ADMINISTRATIVE TASKS ................................................................................................................... 249

ROTATING CPM LOGS ................................................................................................................................................249

CyberArk University Exercise Guide page 5

JUST-IN-TIME (JIT) ACCESS .........................................................................................................................................252

CyberArk University Exercise Guide page 6

CyberArk University Exercise Guide page 8

CyberArk University Exercise Guide page 9

You may need to adjust your bandwidth setting on slower connections.

CyberArk University Exercise Guide page 10

CyberArk University Exercise Guide page 11

CyberArk University Exercise Guide page 12

Introduction to CyberArk Privileged Access Management

Getting to Know the acme.corp Environment

Our environment consists of a total of 8 virtual servers. Some host CyberArk

CyberArk University Exercise Guide page 13

Host name IP Address Operating system Role

dc01 10.0.0.1 Windows 2019 Domain controller

components 10.0.20.1 Windows 2019 CyberArk component server

psm-ssh-gw 10.0.30.1 CentOS Linux 7 CyberArk server hosting:

ptaserver 10.0.30.2 CentOS Linux 7 CyberArk Privileged Threat

vault01a 10.0.10.1 Windows 2016 CyberArk Vault and the

DR 10.0.14.1 Windows 2016 CyberArk Vault and the

target-win 10.0.21.1 Windows 2019 Target Windows server