PAM ADMIN Exercise Guide v11 7 Self Paced

CyberArk University
Privileged Access Security Administration
Exercise Guide
CyberArk University Exercise Guide page 1
6/27/2021
© 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 ..................................................................................................................................................... 7
USING SKYTAP...............................................................................................................................................................7
INTERNATIONAL USERS ...................................................................................................................................................9
INTRODUCTION TO CYBERARK PRIVILEGED ACCESS MANAGEMENT .................................................................... 12
GETTING TO KNOW THE ACME.CORP ENVIRONMENT...........................................................................................................12

Acme Servers ......................................................................................................................................................12
GETTING TO KNOW CYBERARK PAM ...............................................................................................................................14
LOG INTO THE COMPONENTS SERVER ...............................................................................................................................14
PVWA ......................................................................................................................................................................16
Log in as Mike ....................................................................................................................................................16
Activate the PSM ................................................................................................................................................19
Deactivate “Reason for Access” .........................................................................................................................20
Connect to an Account in the New UI .................................................................................................................20
Retrieve a Password in the Classic UI .................................................................................................................23
PRIVATEARK CLIENT .....................................................................................................................................................26
Connecting .........................................................................................................................................................26
Accessing a File in a Safe ....................................................................................................................................27
Modifying the View ............................................................................................................................................30
REMOTE CONTROL CLIENT .............................................................................................................................................31
THE VAULT SERVER ......................................................................................................................................................32
USER MANAGEMENT ........................................................................................................................................... 37
KNOW THE PLAYERS .....................................................................................................................................................37

LDAP INTEGRATION AND DIRECTORY MAPPING ................................................................................................................37
Review LDAP Integration and pre-defined Directory Mappings .........................................................................38
Test the LDAP Integration and Pre-defined Mappings .......................................................................................44
Configure Custom Directory Mapping ................................................................................................................44
Test Custom Directory Mapping .........................................................................................................................46
UNSUSPEND A SUSPENDED USER .....................................................................................................................................51
LOG IN WITH MASTER ...................................................................................................................................................53
PASSWORD MANAGEMENT – PART 1 .................................................................................................................. 54
SECURING WINDOWS DOMAIN ACCOUNTS .......................................................................................................................54

Platform Management.......................................................................................................................................54
Safe Management ..............................................................................................................................................59
Account Management........................................................................................................................................63
EDITING THE MASTER POLICY .........................................................................................................................................66
6/27/2021
Password Management .....................................................................................................................................67
SECURING UNIX SSH ACCOUNTS ....................................................................................................................................70
Vault Administrator Tasks – Mike ......................................................................................................................70
Safe Manager Tasks – Paul ................................................................................................................................73
Auditor Tasks ......................................................................................................................................................85
PASSWORD MANAGEMENT – PART 2 .................................................................................................................. 88
LINKED ACCOUNTS .......................................................................................................................................................88

Securing SSH Accounts Using a Logon account ..................................................................................................88
Securing Windows Server Local Accounts via a Reconcile Account ....................................................................91
SECURING ORACLE ACCOUNTS .......................................................................................................................................97
Vault Administrator Tasks ..................................................................................................................................97
Safe Manager Tasks ...........................................................................................................................................99
SECURING AN ACCOUNT WITH SSH KEYS ........................................................................................................................101
Generating a Key-Pair ......................................................................................................................................101
Verify You Are Able to Log in with the Private Key ...........................................................................................106
Duplicating a Platform – Vault Administrator Task .........................................................................................108
Add an Account with an SSH key – Safe Manager Task ...................................................................................109
USAGES – SECURING SERVICE ACCOUNTS .......................................................................................................................110
Manage Scheduled Task Usage ........................................................................................................................111
Managing a Configuration File Usage ..............................................................................................................116
PRIVILEGED ACCESS WORKFLOWS ..................................................................................................................... 124
REQUIRE USERS TO SPECIFY REASON FOR ACCESS ..............................................................................................................124

Activating the Policy .........................................................................................................................................124
Add Predefined Reasons for Access ..................................................................................................................125
Testing Predefined Reasons for Access ............................................................................................................127
REQUIRE DUAL CONTROL ACCESS APPROVAL ....................................................................................................................128
Activating the Policy .........................................................................................................................................128
Adding an approver to a Safe...........................................................................................................................130
Testing Dual Control .........................................................................................................................................131
EXCLUSIVE PASSWORDS WITH AUTOMATED RELEASE AND ONE-TIME USE ............................................................................135
Adding a Master Policy exception for Exclusive Passwords .............................................................................135
Adding a Master Policy exception for One-Time Passwords ............................................................................136
Reducing the Minimum Validity Period ............................................................................................................137
Testing Exclusive Passwords .............................................................................................................................138
Testing Automatic release by PSM ...................................................................................................................140
DISCOVERY AND ONBOARDING ......................................................................................................................... 143
ACCOUNTS FEED ........................................................................................................................................................143

Configure Automatic Onboarding Rules ...........................................................................................................143
Configure and Run Windows Accounts Discovery ............................................................................................146
6/27/2021
Manually onboard discovered accounts...........................................................................................................151
ADD MULTIPLE ACCOUNTS FROM FILE ...........................................................................................................................154
PRIVILEGED SESSION MANAGEMENT................................................................................................................. 158
Remove Privileged Access Workflows Exceptions ............................................................................................158

Disabling the PSM Globally ..............................................................................................................................160
PRIVILEGED SESSION MANAGER....................................................................................................................................160
Adding Exceptions ............................................................................................................................................160
Connect with a Linux Account ..........................................................................................................................161
Connect with an Oracle Account ......................................................................................................................163
HTML5 Gateway ...............................................................................................................................................163
Connect using PSM Ad-Hoc Connection ...........................................................................................................169
PRIVILEGED SESSION MANAGER FOR WINDOWS ..............................................................................................................171
Connect using RDP file without providing the target system details: ..............................................................171
Connect using RDP file with the target system details .....................................................................................174
PRIVILEGED SESSION MANAGER FOR SSH .......................................................................................................................175
AUDITING USER ACTIVITY IN THE PSM (MONITORING) ......................................................................................................177
PSM Session Terminators .................................................................................................................................177
Monitor, Suspend, and Terminate Active Sessions ...........................................................................................178
Monitor Recordings ..........................................................................................................................................179
PRIVILEGED THREAT ANALYTICS ........................................................................................................................ 181
DETECTIONS AND AUTOMATIC REMEDIATION FOR UNIX/LINUX..........................................................................................181

Unmanaged Privileged Access .........................................................................................................................181
Suspected Credential Theft and Automatic Password Rotation .......................................................................184
Suspicious Password Change and Automatic Reconciliation ...........................................................................187
Suspicious Activities in a Session and Automatic Suspension...........................................................................189
Security Rules Exceptions .................................................................................................................................191
DETECTIONS AND AUTOMATIC REMEDIATION FOR WINDOWS ............................................................................................193
Unmanaged Privileged Access .........................................................................................................................193
Suspicious Activities in a Windows Session and Automatic Suspension ...........................................................197
CONNECT TO THE PTA ADMINISTRATION INTERFACE ........................................................................................................200
REPORTS ............................................................................................................................................................ 202
GENERATE “PRIVILEGED ACCOUNTS INVENTORY” REPORT..................................................................................................202

GENERATE “SAFES LIST” REPORT AND “USERS LIST” REPORT..............................................................................................204
GENERATE REPORTS USING EVD ...................................................................................................................................207
REPLICATIONS .................................................................................................................................................... 211
BACKUP AND RESTORE ................................................................................................................................................211

Configuring the CyberArk Replicator ................................................................................................................211
Running a Backup.............................................................................................................................................212
Delete the TEST Safe.........................................................................................................................................213
6/27/2021
Running a Restore ............................................................................................................................................214
DISASTER RECOVERY.......................................................................................................................................... 216
STEP 1: ENABLE AUTOMATIC FAILOVER ON THE DR VAULT ................................................................................................216

STEP 2: EXECUTE A FULL REPLICATION TO THE DR VAULT ...................................................................................................218
STEP 3: EXECUTE AUTOMATIC FAILOVER TEST .................................................................................................................220
Confirm Automatic Failover on the DR Vault ...................................................................................................222
Confirm Automatic Failover of PVWA and PSM ...............................................................................................222
STEP 4: EXECUTE A FULL REPLICATION BACK TO THE PRIMARY VAULT ...................................................................................223
STEP 5: EXECUTE FAILBACK PROCEDURE BY USING MANUAL FAILOVER .................................................................................226
Confirm Manual Failover on the Primary Vault ...............................................................................................227
STEP 6: SET THE DR SERVER BACK TO DR MODE ..............................................................................................................228
Confirm Automatic Failover for PVWA and PSM ..............................................................................................229
COMMON ADMINISTRATIVE TASKS ................................................................................................................... 231
ROTATING CPM LOGS ................................................................................................................................................231
OPTIONAL EXERCISES ......................................................................................................................................... 233
JUST-IN-TIME (JIT) ACCESS .........................................................................................................................................233

Set up the JIT Access Platform ..........................................................................................................................234
Add the Local Administrator Account ..............................................................................................................236
Test Just-in-Time Access ...................................................................................................................................236
CUSTOM FILE CATEGORIES...........................................................................................................................................240
Creating the Custom File Category ...................................................................................................................240
Adding the Custom File Category to the Platform ............................................................................................242
Making the File Category Searchable...............................................................................................................243
Testing the New File Category .........................................................................................................................244
6/27/2021
6/27/2021
CyberArk Privileged Access Security 11.7 – 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. The button is
highlighted in red in the image below. Note that all but two of the machines in this image
are already running.
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.
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.
6/27/2021
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 PAS
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.
You may need to adjust your bandwidth setting on slower connections.
6/27/2021
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 Language Settings “Add a language.”
6/27/2021
Click “Add a language.”
Select your language. Click Next and then Install
6/27/2021
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.
6/27/2021
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 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.
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.
6/27/2021
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
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.
Because we won’t need them immediately, we will start up the ptaserver and DR later in
the course.
6/27/2021
Getting to know CyberArk PAM
In this first section, 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
• Vault Server Central Administration
All actions should be performed on the Components server unless otherwise indicated.
Log into the Components server
First, we need to log into Windows. 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.
In Skytap, click on the screen for the 02 – components virtual machine. This will
open a browser window with the machine’s login screen.
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.
6/27/2021
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.
And you should find yourself logged into the Components server with the Active
Directory credentials of the CyberArk Vault Administrator.
6/27/2021
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.
Note: The screenshots in this guide have been made using the Chrome browser, which
works very well and is probably the fastest.
6/27/2021
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.
6/27/2021
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.
6/27/2021
Activate the PSM
As you can see in the image above, the Connect button is 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.
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.
6/27/2021
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.
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 by connecting 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.
6/27/2021
Depending on the browser, 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 will then be prompted to allow
the RemoteApp program to run. Click Connect.
6/27/2021
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.
6/27/2021
Note: The password for this user was retrieved by the PSM from the Vault and inserted
into the PuTTY session at the moment 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 UI.
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 UI.
Click the link.
6/27/2021
Here, you are looking at the Account Details for root10 in the Classic UI. Notice that
we are still in the version 10 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.
6/27/2021
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 UI. The
other two options are for the moment only available in the Classic UI. 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 PasswordManager (in other words, the CPM). Press refresh until you
see the password has been changed.
6/27/2021
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.
6/27/2021
Enter the username and password for the internal CyberArk Administrator user.
Note: It is not possible to login 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.
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.
6/27/2021
You will probably 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.
6/27/2021
The file is extracted from the Safe and displayed. Take a moment to view some of
the log messages and then close the file.
6/27/2021
To indicate to the Vault that we are finished with the file, right-click on it again and
select Return to Safe.
Modifying the View
You can change how you view the Safes by going to the View menu. Click View and
then Details.
You can either use the Logoff button or simply close the PrivateArk Client. Both
will close the Safe and terminate your session.
6/27/2021
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.
On the Components server, open a command-line window (either the classic

Windows command line or PowerShell) 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 (11.7.17.0)
Working with agent on: 10.0.10.1
Loaded component from [C:\Remote Control Client\PARClusterVaultClient.dll]

Loaded component from [C:\Remote Control Client\PARDRClient.dll]
Loaded component from [C:\Remote Control Client\PARENEClient.dll]
Loaded component from [C:\ Remote Control Client\PARVaultClient.dll]
PARCLIENT>
Once you have the PARCLIENT prompt, get the current Vault status by running:
PARCLIENT> status vault

Vault is running.
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

Password:*********
Vault was started, pending service running. use status command for further
details.
6/27/2021
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 have to 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.
Log in with the local administrator account: Username administrator, password

Cyberark1. You will receive an authorization warning message.
6/27/2021
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.
6/27/2021
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.
You will be asked to confirm Vault shutdown. Click Yes to shutdown the Vault.
6/27/2021
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.
6/27/2021
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.
6/27/2021
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:
6/27/2021
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.
Review LDAP Integration and pre-defined Directory Mappings
To review the LDAP integration and existing directory mappings, you must use the built-in
CyberArk Administrator account (password: Cyberark1).
Launch a browser and open the PVWA page. Click on CYBERARK.
6/27/2021
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. Hover the mouse over the tab and select
LDAP Integration.
Note that CyberArk PAM has been integrated with the acme.corp domain and that
four directory mappings have been defined.
6/27/2021
As you can see, there are 4 AD groups and each AD group is mapped to selected
CyberArk roles 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.
6/27/2021
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.
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.
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. In other words,
members of the AD group CyberArk Vault Admins will be assigned the following Vault
authorizations when they authenticate to CyberArk for the first time:
6/27/2021
Now click on Edit.
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.
Scroll down to Mapping Criteria and click on View users.
6/27/2021
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).
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?
• What Vault authorizations are assigned to users who meet the criteria?
6/27/2021
Test the LDAP Integration and Pre-defined Mappings
Now that we can log into CyberArk PAS using Active Directory accounts, test the
integration by logging in with the following accounts (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.
6/27/2021
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.
Select the following Vault Authorizations: Activate Users, Audit Users, and Reset
Users’ Passwords then click on Next.
6/27/2021
Verify your settings in the Summary page. If all is ok, click on Save.
Logoff the PVWA.
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.
6/27/2021
Right-click on the Primary Vault and select Properties.
Click on Advanced.
6/27/2021
Select LDAP authentication and then click on OK.
Click on OK again (no need to change the default username).
Double click on the Prod icon login to the Prod vault. Enter Dexter as the username
and Cyberark1 as the password.
Note that you should not see any Safes when logged in to the PrivateArk Client as
Dexter.
Navigate to Tools > Administrative Tools > Users and groups.
6/27/2021
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.
Select another user, for example, Mike, and review the user’s Vault authorizations.
Then click on Trusted Net Areas…
6/27/2021
As you can see, the user is now active (there is no need to deactivate it). In the event
the Mike or any other user gets suspended, you will now be able to re-activate the
user using Dexter or any other user of the CyberArk Help Desk group, by clicking on
Activate.
Click on close and then Logoff the PrivateArk Client.
6/27/2021
When finished, change the default authentication method for the Prod server back to
PrivateArk authentication.
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 power 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.
6/27/2021
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.
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.
6/27/2021
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.
In order 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),
you will need to point it to the relevant location.
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”
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.
6/27/2021
Password Management – Part 1
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 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, hover
over the wrench icon to expand the Administration menu and then click on
Platform Management.
6/27/2021
Expand the Windows section to view the platforms there.
Select the Windows Domain Accounts platform and press the Duplicate button.
6/27/2021
Enter as the name WIN DOM ADM 15 (you can also give it a meaningful description)
and then press Create.
Select the WIN DOM ADM 15 platform and press the Edit button.
Click on UI & Workflows and change AutoVerifyOnAdd from No to Yes.
6/27/2021
Note: This setting will prompt the CPM to automatically verify the password whenever a
new account assigned to this platform is added.
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).
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.
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.
6/27/2021
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
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.
6/27/2021
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. The Platforms we will be using in this course are:
- Oracle Database
- Unix via SSH
- Unix via SSH Keys
- Windows Domain Accounts
- Windows Server Local Accounts
You can deactivate the Platforms we won’t be using. Doing so is best practice and will
help avoid errors. We can always reactivate a Platform if we need to, but if it is
deactivated, no one will use it by mistake.
Note: As we have duplicated the Windows Domain Accounts platform to a new platform,
you can now deactivate the Windows Domain Accounts platform.
To deactivate a platform, select the platform, click on the ellipsis and select
Deactivate:
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, Access Control (Safes), and then click
Add Safe.
6/27/2021
Enter CyberArk-Service-Accounts as the Safe name. You can provide a

meaningful description. Leave the other values at their defaults and press Save.
On the Safe Details page, click the Add Member button to grant other users access
to this safe.
6/27/2021
Enter “cyberark v” (without the quotes) in the Search field, leave Vault as the value in
the Search In field, and click Search.
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.
6/27/2021
Now add another CyberArk group to the Safe: CyberArk Safe Managers. In the
Access section, give them only the List Accounts permission. We will need this for a
later exercise.
6/27/2021
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.
First select the System Type. Click on Windows
Next, select the Platform we created for domain accounts: Win Dom Adm 15.
6/27/2021
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>
6/27/2021
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.
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.
6/27/2021
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:
Safe: CyberArk-Service-Accounts
Name: Operating System-WINDOMADM15-acme.corp-cybrreconcile
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.
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
6/27/2021
Password Management
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.
Change the value to 60 and then click the diskette icon to save your change.
6/27/2021
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.
Select the Platform WIN DOM ADM 15 and click Next.
6/27/2021
Change the value from 60 to 15 and click Finish.
You should now see an exception to the Master Policy.
6/27/2021
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 very 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.
6/27/2021
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,

click on the three points at the end of the line, and select Duplicate.
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.
6/27/2021
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.
Go Automatic Password Management > General.
Change ImmediateInterval to 1
Note: Changing the ImmediateInterval field to 1 is only suitable for testing but 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.
6/27/2021
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
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 PAS, 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). In
order to access this, you may need to select “Additional details & actions in classic
interface”, as shown below.
6/27/2021
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 limited permissions).
Go to POLICIES > Access Control (Safes).
Click Add Safe.
6/27/2021
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.
Press Add Member to grant other users access to the new Safe.
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.
6/27/2021
Now add another group. This time add the LDAP group CyberArk Vault Admins with
the following permissions:
6/27/2021
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.
On the Add Account page, first select the system type *NIX and click Next:
6/27/2021
Select the LIN SSH 30 platform and click Next:
Select the Safe we created earlier: Lin-Fin-US and click Next.
6/27/2021
Note: In the image above, only one safe appears. Why is that?
Enter the account details shown below and click on Add:
Address: 10.0.0.20
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.
6/27/2021
You will be asked to confirm the password change. Click Change.
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.
6/27/2021
Click on the account logon01 and click the Connect button.
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.
6/27/2021
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.
And then a PuTTY window will appear with your SSH connection to the machine
targe-lin as logon01.
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.
6/27/2021
Log out of the PVWA.
6/27/2021
Test the New Account as a Normal End User
Our first test verified that we are able to 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 has to use
CyberArk PAM to get his or her job done – can use the account to connect to the target.
There is an AD account 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.
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.
6/27/2021
Click the Connect button.
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 in order 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.
6/27/2021
Sign out of the PVWA and log in using LDAP Authentication as cindy.
In the left-hand toolbar, click on the Monitoring tab.
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.
6/27/2021
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.
6/27/2021
Password Management – Part 2

In Password Management – Part 1, we worked with a few simple use cases: Windows
domain accounts and Linux accounts. In Part 2, we will look at several more examples of
different types of accounts managed by CyberArk PAM. Specifically, we will look at:
• Linked Accounts
• Securing Oracle Accounts
• Securing an Account with SSH Keys
• Manage Service account platforms
Linked Accounts
Securing SSH Accounts Using a Logon account
In this exercise you will add to our 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 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, and then runs the password
change.
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
6/27/2021
Password: Cyberark1
Press Add.
On the Account Details page, press the Verify button and select OK to the pop up
to confirm. 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”)
Open the account details page using the Additional details & actions in classic
interface link.
Press the Associate button next to Logon Account.
6/27/2021
Select the logon01 account created earlier – you may need to search to see this user
– and click Associate.
Back in the Account Details view, press the Verify button and click OK to confirm.
If you receive the following message, press OK.
6/27/2021
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. In order 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.
6/27/2021
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.
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.
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.

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.
6/27/2021
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.
6/27/2021
Note: Don’t forget to enable automatic password change and verification. Also, think
about what appropriate values for password length and complexity would be.
Note: Don’t forget to add the relevant exception to the Master Policy in order to enable
automatic password rotation every 45 days.
Note: 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 > Access Control (Safes) and click Add 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.
6/27/2021
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.
6/27/2021
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>
Note: After adding the account, when you select it 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.
6/27/2021
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.
Securing Oracle 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.
6/27/2021
Select ORA DBA 30 and select Edit.
Go to UI & Workflows and set AutoChangeOnAdd to Yes.


verified by the CPM automatically and without user intervention
Go to Automatic Password Management > General.
• Set ImmediateInterval to 1.
• Set AllowedSafes to Ora-.
Press Apply.
6/27/2021
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 in order 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,
of course, named Robert.
Creating a Safe
Log in to the PVWA as LDAP user Robert and go to POLICIES > Access Control
(Safes).
Press the Add 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.crop).
6/27/2021
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
Safe Ora-Fin-US
User Name dba01
Address 10.0.0.20
Password Cyberark1
Confirm Password Cyberark1
Port 1521
Database xe
6/27/2021
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’.
After a minute or two, press the Show button to display the new password.
Securing an Account 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 and
click Generate.
6/27/2021
As instructed, you need to make mouse movements in the blank area to generate
random data for the key.
When the key is generated click Save Private Key.
6/27/2021
Click Yes to store they key without a passphrase. The CPM does not support private
keys with passphrases.
Name the key root01.ppk and save it to your Documents directory.
6/27/2021
Select all the text in the ‘Public key for pasting into Open SSH authorized keys file’
box and copy it to your clipboard.
Use PuTTY to connect to Target Linux.
6/27/2021
Log in as root01 with the password Cyberark1.
Edit your authorized key file with vi.
6/27/2021
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.
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 -- (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 Are Able to Log in with the Private Key
Now we will test that we are able to authenticate with the private key.
6/27/2021
Open PuTTY again.
Type 10.0.0.20 in the Host Name box, but do not connect yet. Navigate to
Connection > Data.
Enter root01 in the Auto-login username field.
Navigate to Connection > SSH > Auth.
Click Browse and browse to the ppk file you created earlier.
6/27/2021
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).
Select Duplicate.
Name your platform LIN KEYS 90 and click Create.
Select LIN KEYS 90 and select Edit.

6/27/2021

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 in order 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
Private Key: Browse to find the root01.ppk file you
created earlier.
You may also paste the content of the
private key.
6/27/2021
Click Add.
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.
Usages – Securing Service Accounts
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
Service Dependencies
When working with service dependencies, all service accounts on the remote machine must
be managed by the CPM. During standard service dependency management, if a service is
dependent on another service on the same remote machine, when the CPM tries to change
the service account password, its service accounts in the Vault will be disabled and a
corresponding message will be written in the CPM log. This means that all dependent
services will be handled by the root of the dependent services.
6/27/2021
Manage Scheduled Task Usage
The virtual machine “Target Windows” (target-win - 10.0.21.1) contains two scheduled
tasks: schedtask01 and schedtask02. They are both configured to send an email to
Mike and John every time they are run and 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.
Now run the following command:
schtasks /run /s target-win /tn SchedTask01
6/27/2021
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 and open the email client at
https://webmail.acme.corp/mewebmail/Mondo/lang/sys/Login.aspx (there is a short
cut in the browser toolbar titled "Webmail), and login as mike with the password
Cyberark1.
Now, log in to the PVWA as Tom and go to the localadmin01 Account Details. Open
the classic interface.
6/27/2021
Locate the Scheduled Task tab. 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.
6/27/2021
Note: In many cases, the service account would be blocked from modifying its own
password. If that is 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).
Wait for the localadmin01 password to change.
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.
After the Windows password has been changed, select the scheduled task, and open
the Account Details. You will see that the usage password is now scheduled for
immediate change.
6/27/2021
Wait for the usage password to change and then re-run the scheduled task from the
command prompt.
Now check your email. This time you should receive a message stating that “The
scheduled task is working”.
6/27/2021
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
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=OraServer
Username=dba01
Password=Cyberark1
[Database]
Db=xe
Port=1521
6/27/2021
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
Click on the newly created account and click on Verify. Confirm that the CPM can
verify the account password.
Configure Usages on the Oracle platform
Login to the PVWA as Mike.
6/27/2021
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.
Enter INIFile as the Value.
6/27/2021
Press Apply and OK.
Add the Usage to the target account
Now go to ACCOUNTS and open the dba01 account using the Classic UI.
If the previous steps were configured properly, you should be able to see a new tab
called INI File in the Accounts 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
6/27/2021
INI Section: Server

Backup Password File: No
Click on the new Usage:
Click on Associate.
6/27/2021
Select the app-account01 account and click on Associate.
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.
6/27/2021
Review the details of the Usage in the Accounts Details page and make sure
everything is configured properly.
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
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.
6/27/2021
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.
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.
6/27/2021
Privileged Access Workflows

In this section, we will configure the Master Policy for Privileged Access Workflows.
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.
6/27/2021
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.
6/27/2021
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).
6/27/2021
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.
6/27/2021
When you are finished, disconnect from the target machine, and move on to the next
exercise.
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.
6/27/2021
Click Active. Review (but do not modify) the other options available. When ready,
press Finish.
6/27/2021
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 a group called 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 > Access Control (Safes).
Highlight Lin-Fin-US and press the Members button.
Click Add Member.
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.
6/27/2021
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.
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).
6/27/2021
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.
Enter a reason to access. Note you are unable to enter free text and can only see the
predefined 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.
Launch a new browser session and open the email client at

https://webmail.acme.corp/mewebmail/Mondo/lang/sys/Login.aspx (there is a short
cut in the browser toolbar).
6/27/2021
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.
6/27/2021
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.
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.
6/27/2021
Login to the PVWA as Carlos (password Cyberark1) if you are not already logged on,
and 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.
Using PVWA, login as mike.
Go to POLICIES > Master Policy and select Enforce check-in/check-out exclusive

access and click Add Exception.
Select WIN SRV LCL ADM 45 and press Next.
6/27/2021
Press the Active button to enable Enforce check-in/check-out exclusive access and
click Finish.
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.
6/27/2021
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.
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.
6/27/2021
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.
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.
6/27/2021
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.
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.
6/27/2021
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 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.
6/27/2021
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.
6/27/2021
Then, after a few minutes, the account password will also be rotated by the CPM
(thanks to the One-time password setting).
6/27/2021
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 in order 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.
6/27/2021
In Select system type select Windows.
In Select Scope select the following:
Machine Type: Server
Account Type: Local
Account Category: Any
Privileged Account Type: Any
Username (begins…): discovery
6/27/2021
Click Next.
In Assign to platform select WIN SRV LCL ADM 45.
In Store in Safe select Win-Srv-Fin-US.
6/27/2021
In Define rule properties enter the following name: Discovery users.
Review your rule and if everything seems to be in order click on Create rule.
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.
6/27/2021
Go to Accounts > Pending & Discovery > Discovery Management and click New
Windows Discovery.
Enter acme.corp in the Domain field.
Use the Click to select an account from the Vault link and select the cybrscan
account.
6/27/2021
In the What to scan? section, click Browse.
6/27/2021
Select the Servers container and press OK.
Under What recurring pattern to set for this Discovery? Select Onetime, then click
Done.
You will receive a message saying that the Windows discovery has been added.
Press OK.
6/27/2021
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.
After several minutes, the process should appear as Completed.
Note: it is also possible the discovery will complete but with errors. This is normal in our
environment.
6/27/2021
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. If you
assigned a reconcile account to the platform, the accounts added should also be
reconciled or scheduled for immediate reconciliation.
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 that 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.
6/27/2021
press the Onboard Accounts button.
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.
In the Onboard Accounts window, enter the following:
6/27/2021
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)
Press Onboard.
You should receive a message saying “Successfully onboarded 1 account(s) and

related dependencies. Press Done.
6/27/2021
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.
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 mail client as Mike, and verify 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
6/27/2021
• View the status of the upload process
• 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 PAS
solution.
Now, login to the PVWA as mike.
6/27/2021
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 select Upload.
6/27/2021
You should see the following notification on your screen.
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.
6/27/2021
Privileged Session Management

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.
In the Edit Exception window click on the red Remove Exception button.
6/27/2021
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.
6/27/2021
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.
6/27/2021
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.
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
6/27/2021
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 to your desktop. 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. In the example below the user is running:
mkdir user16
rm –R user16
Type exit to end the session.
6/27/2021
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.
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.
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.
6/27/2021
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.
6/27/2021
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.
6/27/2021
Transfer files via HTML5 GW
In this section we will copy a file from our workstation to the remote machine via the
HTML5 Gateway.
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.
6/27/2021
You should be able to see the following message on your screen. Click on Close.
Lastly, copy the file from the Z on COMPONENTS drive that was created on the
target machine to the desktop on TARGET-WINDOWS.
6/27/2021
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 on the local workstation.
When you are finished, disconnect from the target server.
6/27/2021
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.
Platform PSMSecureConnect
Client: WinSCP
Address: 10.0.0.20
User Name: root01
Password: Cyberark1
Map Local Drives: Checked
(scroll down)
Port 22
Press Connect.
6/27/2021
Press Yes to accept the host’s RSA key if asked.
6/27/2021
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.
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.
6/27/2021
Double click on the file. If prompted, click on Connect.
Vault username: John

Password: Cyberark1
6/27/2021
Next, input the target system details:
User Name: localadmin01

Address: target-win.acme.corp
Lastly, specify PSM-RDP as the connection type:
6/27/2021
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:
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.
6/27/2021
# alternate shell:s:psm /u localadmin01 /a target-win.acme.corp /c PSM-RDP

alternate shell:s:psm
Edit the RDP file as follows to include the target system details in advance:
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 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.
6/27/2021
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”
When prompted for a password, enter the password for Carlos (password:
Cyberark1)
6/27/2021
Execute a few simple, non-destructive commands (remember, you are a privileged

user) such as pwd and ls -al in order to generate some session activity. When
you are done, enter exit and hit Enter to close the session.
Auditing user activity in the PSM (Monitoring)
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.
6/27/2021
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.
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.
6/27/2021
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.
6/27/2021
Close the playback window when you are done.
6/27/2021
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.
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).
6/27/2021
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.
6/27/2021
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.
Optionally, return Security > Security Events and close the Security event now that
it has been dealt with.
6/27/2021
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 scheduled task that is by
default scheduled to run once a day 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 PAS and trigger the CPM to initiate a
password change.
Login to the PVWA as Paul and go to POLICIES > Access Control (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.
6/27/2021
Repeat the above step to add the PTAAppUser to the Lin-Fin-US safe as well
(including the “Initiate CPM account management operations” permission).
6/27/2021
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).
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.
In the PVWA, go to the root02 account and verify that the CPM changed the
password.
Open the Activities tab 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.
6/27/2021
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 the purpose of 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. Using the classic UI, associate root01 as the reconcile account for
root02.
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
6/27/2021
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.
Go to Accounts > Accounts View and select root02. Verify that root02 was indeed
reconciled by the CPM.
6/27/2021
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.
Configure the risk to a Score of 90 and the Session response to Suspend. Click on
Save.
6/27/2021
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.
6/27/2021
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.
Click on Resume to resume the suspended session
Note: mike can resume the session only because we added the user to the
PSMLiveSessionTerminators group.
Login as cindy and go to the Monitoring pane. If the session is still in progress, you
should see in Active Sessions with the options to terminate, suspend or monitor the
session. If you already closed the session, you should be able to play the recording.
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.
6/27/2021
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.
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.
6/27/2021
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.
6/27/2021
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.
6/27/2021
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.
6/27/2021
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 Access, 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.
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
in order to take full control of the backdoor account. Click on Onboard.
6/27/2021
Verify that the backdoor account has been reconciled by the CPM.
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".
6/27/2021
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.
6/27/2021
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.
Click on Resume to resume the suspended session.
6/27/2021
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
When you log in, you should see information related to the activities we performed earlier.
6/27/2021
6/27/2021
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.
6/27/2021
Review the options to filter the report but keep the default values, then click Next.
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.
6/27/2021
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
6/27/2021
Click Report Output 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).
6/27/2021
Use LibreOffice Calc to open the SafesList report file on your desktop.
Under “Separator options” choose Seperated by: Comma
Click OK.
After reviewing the report, save a copy of the report to the desktop of the
Components server.
Select Keep 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 3 reports on the desktop. These reports
are “Privileged Accounts Inventory”, “Safes List” and “Users List”.
6/27/2021
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.
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.
Untick the box for Disable User.
6/27/2021
Go to the Authentication tab and set the password to Cyberark1.
Click on OK. Then Close. And finally, logoff the PrivateArk Client.
6/27/2021
Now using the 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 and run the

following command to generate a cred file: CreateCredFile.exe auditor.cred
Set the following parameters according to the below (keep all other parameters as
default by simply pressing 'Enter'):
Vault username=Auditor
Vault Password=Cyberark1
Now run the following command:
6/27/2021
ExportVaultData \VaultFile="C:\ExportVaultData\Vault.ini"
\CredFile="C:\ExportVaultData\auditor.cred" \Target=File \LogNumOfDays=4
\LogList="C:\ExportVaultData\loglist.csv"
Note: The above example will create a log activities 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, also in C:\ExportVaultData.
The Log is generated for the last 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.
6/27/2021
Replications
Backup and Restore
In this section, you will use the CyberArk Replicator utility to test backup and restore of
the Vault data. Like all other components, the CyberArk Replicator utility has already
been installed in your environment by the implementation team.
Note: 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. The two users are disabled by
default; however, the implementation team has already enabled those two users in
your environment. The password for both users was set to Cyberark1.
Configuring the CyberArk Replicator
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.
6/27/2021
In the Vault.ini file, enter “Primary Vault” for the VAULT parameter (although this is
not mandatory).
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.
Open a Command Prompt.
Enter cd c:\Program Files (x86)\PrivateArk\Replicate.
Run the following:
CreateCredFile.exe backup.cred
Vault Username [mandatory] ==> backup
Vault Password…==> Cyberark1
Press enter to accept the defaults for the remaining questions as they are not
relevant in our environment.
Running a Backup
To perform a backup, run the following command from the Replicate installation 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.
6/27/2021
If the replicate was successful, proceed to the next steps. If not, verify the configuration
information and try again.
Delete the TEST Safe
Login to the PVWA as Mike and search for root10 account (stored in a safe called
TEST).
Next, go to POLICIES > Access Control (Safes).
Highlight TEST and click the Delete button.
Press Yes to confirm that you would like to delete the safe and contents.
You will receive a message that the Root folder cannot be deleted for 7 days.
However, the contents of the safe should have been removed.
6/27/2021
To confirm that the contents of the TEST safe have been deleted 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.
Running a Restore
Go back to the command prompt 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.
You will receive a message stating that the restore process has ended.
6/27/2021
Go back to the PVWA 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 to create. The
restore process does not overwrite an existing Safe – it creates a new one.
Therefore, this name must not correspond with an existing Safe.
6/27/2021
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.
Both the DR and DR_Failback users have already been enabled.
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. We are now going to enable Automatic Failover on the DR Vault.
Power on the 08-DR server, if it is not already powered on.
6/27/2021
Sign into 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.
Change the EnableFailover setting to Yes.
6/27/2021
Note: Notice FailoverMode is currently set to No. Do NOT change this setting. It will
automatically change later when we test the failover process.
Next, delete the last two lines of the file. This will trigger a full replication when we
restart the Disaster Recovery service, making sure we have the most updated data.
Save the file and exit Notepad.
Step 2: Execute a full replication to the DR Vault
On the DR server, open the Windows Services applet. You will have a shortcut in the
task bar.
6/27/2021
Restart the CyberArk Vault Disaster Recovery service.
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.
Note: if you are prompted to allow running the script, select Yes.
6/27/2021
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.
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.
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.
6/27/2021
Sign in to the console of your Primary Vault server (Vault01A) as Administrator.
Open the Server Central Administration app and stop click on Stop Server.
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.
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.
6/27/2021
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.
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 Carlos) 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 PSM Vault.ini file:
6/27/2021
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.
Open the console on vault01a (10.0.10.1).

6/27/2021
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.
Restart the ‘CyberArk Disaster Recovery’ Service on the Primary Vault.
6/27/2021
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.
6/27/2021
Note: Contrary to the PVWA and PSM, the CPM is not configured to perform an
automatic faliover. 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.
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.
6/27/2021
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).
Verify that the PrivateArk Server service has started successfully on vault01a
(10.0.10.1).
6/27/2021
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.
Using the Windows Services applet, stop the PrivateArk Server service on DR
(10.0.14.1).
6/27/2021
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).
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.
6/27/2021
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.
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.
6/27/2021
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.
Select Configuration > General and scroll down to set the following parameters.
LogCheckPeriod: 1
LogSafeName: CPM_Logs
Click OK.
6/27/2021
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.
6/27/2021
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 smoothen out your local
administrators’ security. It can be used as an intermediate step towards full implementation
of Vaulting the local administrators. 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 ad hoc target machine, and is subsequently 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.
6/27/2021
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 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.
• AutoChangeOnAdd
• AllowManualChange
• PerformPeriodicChange
• VFAllowManualVerification
• VFPerformPeriodicVerification
• RCAllowManualReconciliation
• RCAutomaticReconcileWhenUnsynched
6/27/2021
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.
6/27/2021
Note: For JIT access, a domain account which is used 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:
Store in Safe: Win-Srv-Fin-US

System Type: Windows
Platform Name: WIN SRV JIT
Address: target-win.acme.corp
User Name: Administrator
Password: Cyberark1
Logon To (optional) <click the Resolve button>
Test Just-in-Time Access
First, open MSTSC (you can use the search functionality to find the application).
6/27/2021
Attempt to connect to target-win.acme.corp as acme\John.
You should receive an error stating that John is not authorized for remote login:
6/27/2021
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.
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.
6/27/2021
Disconnect from the Target Windows server.
6/27/2021
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 Prod Vault as
Administrator and go to File > Server File Categories.
Press the New… button.
6/27/2021
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.
Log out of the PrivateArk Client.
6/27/2021
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.
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 press Apply and OK. This will make
BusinessUnit a required field on any accounts attached to the ORA DBA 30 policy.
6/27/2021
Making the File Category Searchable
Now we will make the new BusinessUnit file category searchable.
Go to ADMINISTRATION > Configuration Options > Options.
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.
6/27/2021
Sign out of the PVWA session.
Testing the New File Category
Login to the PVWA as Robert, go to the Classic interface and in the ACCOUNTS tab
and open the dba01 account.
Click on the Edit button. Select Retail and press Save.
Enter retail in the Search field on the ACCOUNTS tab and press Go.
6/27/2021
dba01 should be returned based on the new file category.
6/27/2021

PAM ADMIN Exercise Guide v11 7 Self Paced

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 v11 7 Self Paced

Uploaded by

Copyright:

Available Formats

CyberArk University

Privileged Access Security Administration

CyberArk University Exercise Guide page 1

INTRODUCTION TO CYBERARK PRIVILEGED ACCESS MANAGEMENT .................................................................... 12

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

USER MANAGEMENT ........................................................................................................................................... 37

KNOW THE PLAYERS .....................................................................................................................................................37

PASSWORD MANAGEMENT – PART 1 .................................................................................................................. 54

SECURING WINDOWS DOMAIN ACCOUNTS .......................................................................................................................54

CyberArk University Exercise Guide page 2

PASSWORD MANAGEMENT – PART 2 .................................................................................................................. 88

LINKED ACCOUNTS .......................................................................................................................................................88

PRIVILEGED ACCESS WORKFLOWS ..................................................................................................................... 124

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

DISCOVERY AND ONBOARDING ......................................................................................................................... 143

ACCOUNTS FEED ........................................................................................................................................................143

CyberArk University Exercise Guide page 3

PRIVILEGED SESSION MANAGEMENT................................................................................................................. 158

Remove Privileged Access Workflows Exceptions ............................................................................................158

PRIVILEGED THREAT ANALYTICS ........................................................................................................................ 181

DETECTIONS AND AUTOMATIC REMEDIATION FOR UNIX/LINUX..........................................................................................181

REPORTS ............................................................................................................................................................ 202

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

REPLICATIONS .................................................................................................................................................... 211

BACKUP AND RESTORE ................................................................................................................................................211

CyberArk University Exercise Guide page 4

DISASTER RECOVERY.......................................................................................................................................... 216

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

COMMON ADMINISTRATIVE TASKS ................................................................................................................... 231

ROTATING CPM LOGS ................................................................................................................................................231

OPTIONAL EXERCISES ......................................................................................................................................... 233

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

CyberArk University Exercise Guide page 5

CyberArk University Exercise Guide page 7

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

CyberArk University Exercise Guide page 8

From the Start Menu , go to Language Settings “Add a language.”

CyberArk University Exercise Guide page 9

Click “Add a language.”

Select your language. Click Next and then Install

CyberArk University Exercise Guide page 10

CyberArk University Exercise Guide page 11

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 12

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

target-lin 10.0.0.20 CentOS Linux 6.5 Target Linux server

CyberArk University Exercise Guide page 13

Getting to know CyberArk PAM

Log into the Components server

CyberArk University Exercise Guide page 14

CyberArk University Exercise Guide page 15

• Log in as Mike, our CyberArk Vault Administrator

CyberArk University Exercise Guide page 16

CyberArk University Exercise Guide page 17

CyberArk University Exercise Guide page 18