This is the second article on a series around Centrify's role to participate or enhance the Microsoft Enhanced Security Administrative environment.

The first article on the series covered MS ESAE in FAQ form and introduces 10 Principles derived from this environment.

In this article, we provide information about how centrify can enable the implementation of the general principles and recommendations. 


Plesase read the original article (link below) to get the full context of the information:


In this series we discuss Microsoft's Enhanced Security Administrative Environment (ESAE) and how Centrify participates and provides additional capabilities in this model.


The first article on the series is an introductory post on the topic.


Security questions are like a second password prompt. Just like passwords, users tend to create weak or easy to guess answers. Unlike passwords, security questions usually do not have policies to enforce complexity, uniqueness and guessability.


Here are some tips to help make your security question answers stronger:

1. Use a non-corresponding answer.

Using an answer that does not correspond to the question will make it harder for unauthorized users to guess or find your answer. For example, if the question is your first car model, answer with "blankcowblueYogurt". If the question is your mother's maiden name, don't use your mother's maiden name as the answer. Your mother's maiden name might be easily acquired through social media, social engineering, stolen records, public records, malware, easily guessed or many other methods.


2. Avoid answers that are vulnerable to social engineering.

Even if you use a non-corresponding answer to a security question, unauthorized users may still randomly attempt to use information that could be acquired through social media or social engineering such as the name of your child, pet, school, or company.


3. Follow password complexity rules for your answers.

Security questions are just like a second password. Hackers may use brute force or dictionary attacks on a security question. Following password complexity rules can help to make your security question answers more secure.


An easy to remember and yet complex answer is to use four random words like "blankcowblueYogurt".




4. Use spaces if possible.

Older generation brute force and dictionary attacks don't account for spaces. For modern tools, it can make it longer and harder to crack if there are spaces. Add a space in your answer if allowed. "blank cow blue Yogurt"  


Centrify MFA can use security questions for:

  • AD password reset / account unlock
  • Computer login (Windows / Linux / Unix)
  • Privilege elevation (Windows / Linux / Unix)
  • Remote access through Centrify's password vault.
  • Password checkout for shared privileged accounts.
  • AWS Workspaces
  • Horizon View
  • Accessing a web application
  • Accessing the Centrify User and Admin Portals. 
  • VPN access

Centrify users can set up their security question(s) through the Account tab in the Centrify User portal.

This walkthrough is intended for CPS tenant admins who are not database admins but would like a basic understanding of what is needed to add a SQL/ORACLE DB. The example in this blog will be using a SQL database. 


Are you looking for some data that just isn’t covered in the stock reports?


You’ve come to the right place!  In this blog, I want to show you some of the basics of writing your own custom reports.


custom login screen.png

Using a custom Centrify login URL offers a number of benefits, inlcuding branded login screen, Integrated Windows Authentication, and being able to log in using your short name or samAccountName. This article will walk you through configuring your custom login URL for your Centrify tenant.


1. Log into your Centrify Admin Portal.

2. In the left column, navigate to Settings > Customization > Tenant URLs, then click on the Add button.


3. Enter your preferred unique name that is not used by another Centrify customer, then press Save. For example

custom name.png


Once this is complete, you can log into the Centrify portal with your custom login URL.

Centrify User Portal:

Centrify Admin Portal:



This article discusses the different approaches to populate information into the Centrify Privilege Service vault.  The stage in process of implementing a PIM solution dictates many of the strategies to be used.  At the time of this writing, we are looking at version 17.8, but as you know, releases come every month, therefore, the strategies discussed in this post are subject to change as more capabilities, system types or accounts are added.


We will be focusing on the Linux CLI toolset and the PowerShell Samples.


The Lifecycle

A Shared Account strategy is part of what's needed to continuously overcome the challenges around PIM.  These bullets correspond to where many of our prospects or customers are:

  • Brand new to a shared account strategy.
  • No shared account solution, but a very mature process.
  • Migrating from an existing shared account solution.
  • Optimizing the day-today-operations of an existing shared account strategy.
  • Adjusting strategies (e.g. favored shared account, over least privilege).


Two Types of Activities

I think we can easily condense the strategies into two categories: population and onboarding:

  1. Population activities happen when the shared account strategy is brand new, or a migration is in place (maybe switching solutions or going through M&A activities).
  2. Onboarding activities relate to the orchestration and automation of the regular IT operations (adding systems, accounts, domains, databases, etc).

As of this writing, the tools included with privilege service are:

  • Wizard - manual way of onboarding resources and accounts (out of scope for this article).
  • Import - CSV import for systems and local accounts.
  • Discovery - AD-based for Windows or Linux computers, Scheduled Tasks, Services and their corresponding identities
    (will be briefly mentioned, but covered in depth in a different article).
  • CLI Tools for Linux - cenroll & csetaccount, included with Identity Broker.
  • PowerShell Samples for Windows(tm) - available at your request.
  • REST API - Learn all about them here (out of scope for this article).


The Import Tool

This tool is useful if you're populating a new vault, or if you have a CSV of  the sytsems and accounts that you want to onboard. The import tool is tied to the job system.


  • Name - name of the system in privilege service.
  • FQDN - fully qualified domain name (resolvable) or IP address for the system. If using IP, can't use for zone-role workflow.  
  • ComputerClass  - the type of system.  As of this writing:  UNIX, Windows, Generic SSH, CheckPointGAiA, IBM System i, Juniper , Cisco IOS, Cisco NX-OS, & HP NonStop.  This can potentially change every month.
  • Description - the description of the system.
  • ProxyUser -proxy account to be used.
  • ProxyUserPassword -self-descriptive.
  • ProxyUserIsManaged - determines if the proxy account's password is managed or unmanaged by privilege service.
  • User   -  local account.
  • Password - local account password.
  • Managed - If the account is managed or unmanaged by privilege service.
  • UseProxy - if a proxy account will be used to access this system.
  • UserDescription - description of the user.  
  • Domain - if the account is joined to an AD domain, this is the domain name.  .
  • DomainOperationsEnabled - this is to set if the zone-role workflow if needed.



Privilege Service provides an AD-based Discovery tool.  Discovery has the flexibility that it can be used to populate for the first time or in point occasions as well as ongoing.



From system launch to system termination - the process



Enrollment Codes

Enrollment codes allow for a system to automatically be added to privilege service with access control options like owner, # of systems allowed, IP restrictions and sets.
Enrollment codes are a great tool to enable automation or DevOps scenarios.


PowerShell Samples and Onboarding

The idea behind the PowerShell Samples is to be able to align newly-built Windows systems with the registration in the Privilege Service vault to protect shared accounts or to enable the secure access capability.  Alternatively, systems can be organized in sets.  The samples work with enrollment codes or interactively with user/password combinations.  The latter part is reserved for human interaction.


What you need:

  1. PKI Trust pre-requisite:
    The IWA root certificate for the service or tenant should be trusted (manually or via enterprise trust); same for the certificate used for SSL for the platform (not an issue with SaaS, but yes with customer managed if not following proper PKI practices).  This MFA-centric article, discusses the topic.
  2. Centrify Samples:  Available on github or attached to this post (see below).
  3. An administrative local Windows account to perform the system tasks.


PowerShell Samples in Action

Long command lines are split


Enrollment and onboarding a local account

# This is a sample script that runs at POST; once the system is built, 
# patched and joined to Active Directory. # The assumptions are that an enrollment code has been issued and that
# the modules can be loaded (in this case from the X:\CIP drive # and that the proper sets have been put in place.
# Loading Modules Import-Module X:\CIP\cps\Centrify.Cloud.PowerShell.CIP.psm1 Import-Module X:\CIP\cps\Centrify.IdentityPlatform.Powershell.psm1 # E.g. Enroll code, FQDN, Name, and endpoint are required, sets are optional. # Enrollment Code: B8674D29-890C-4036-AEAB-682DBEF6CA78 # FQDN or IP: member.centrify.vms # Name: member-vault # Service Address: https://vault.centrify.vms # Sets: PCI and Engineering (JSON notation, attribute Name) $enrollcode = "YADAYADA-YADA-YADA-YADA-YADAYADAYADAYA" $computer = ($(Get-WmiObject Win32_Computersystem).name
| Out-String -Stream).ToLower() $computerfqdn = [System.Net.Dns]::GetHostByName(($env:computerName)).HostName
| Out-String -Stream $sets = "Engineering, PCI" $sets_json = "[ { 'Name': 'Engineering' }, { 'Name': 'PCI' }]" $vault = 'https://vault.centrify.vms' Enroll-CIPSystem -EnrollCode $enrollcode -FQDN $computerfqdn
-ResourceName $computer -Endpoint $vault -Sets $sets_json # Onboard the Local Administrator account. # This is a placeholder. Good script here:
# # Return the temporary random password to $localpasswd, this will be rotated
# automatically.
$localpwd = 'R@nd0mG%$56bagethatWILLC6ng3soon' $accountname = 'Administrator' Set-CIPAccount -AccountName $accountname -AccountPassword $localpwd
-isManaged $true # Set Centrify Vault Metadata in the Description of the AD Computer Object $joined = (Get-Date).DateTime | Out-String -Stream $desc = "Sets: $sets. Enrolled to CPS on $joined." Set-ADComputer $computer -Description $Desc


PowerShell Samples Usage

1. First, import modules
What's needed: path to the PowerShell modules

Import-Module C:\[insert-path-here]\Centrify.IdentityPlatform.Powershell.psm1
Import-Module C:\[insert-path-here]\Centrify.Cloud.PowerShell.psm1

2. Enroll a system
What's needed: An enrollment code, the name, the FQDN or IP and the endpoint 
(tenant URL). Enroll-CIPSystem -EnrollCode [code] -FQDN [fqdn/ip] -ResourceName [system-name]
-Endpoint [https://your-url-here] Example: Enroll-CIPSystem -EnrollCode "B8674D29-890C-4036-AEAB-682DBEF6CA78"
-FQDN 'member.centrify.vms' -ResourceName 'member-vault'
-Endpoint 'https://vault.centrify.vms' What happens when a system is enrolled? 1. The system is added to CPS. 2. A service account is created in CIP with the default suffix. 3. The system is added to a built-in role called "Centrify Agent Computers." 4. The service account is added with the grant, view, edit and delete"
permissions at the system level. Note that you can add a system to a set.
Another example: Adding a system to the Engineering and PCI Sets: Enroll-CIPSystem -EnrollCode "B8674D29-890C-4036-AEAB-682DBEF6CA78"
-FQDN 'member.centrify.vms' -ResourceName 'member-vault'
-Endpoint 'https://vault.centrify.vms'
-Sets "[ { 'Name': 'Engineering' }, { 'Name': 'PCI' }]" 3. Unenroll a system What's needed: an administrative account. Examples: Unenroll-CIPSystem -Delete $true
# proper way to leave CIP this will remove the service account. Unenroll-CIPSystem -cleanupOnly
#cleans locally in the system, equivalent to a forced adleave. 4. Vault an account What's needed: resource/domain/database, account name, password and if it's
managed or not; if other system, database or domain, the system must
be authorized to add accounts in the resource. Examples # Sets the local account opieadmin as managed Set-CIPAccount -AccountName 'opieadmin' -AccountPassword 'ThisStringwillChangeS00n!'
-isManaged $true # Sets the remote account testuser in the system engcen6 as unmanaged Set-CIPAccount -resourceName 'engcen6' -AccountName 'testuser'
-AccountPassword 'SecretsAreToBeProtected!' -isManaged $false What happens when a system is enrolled? 1. The account is added under the resource in question. 2. The system that performed the addition, is added with all account
permissions except portal login. 5. Check-out a password What's needed: credential type, name and checkout lifetime. If other system,
database or domain, the system must be authorized to view the top level resource
and view+checkout at the account level. Examples: Get-CIPAccount -AccountName 'opieadmin' -lifetime 2 Get-CIPAccount -domainName "" -AccountName "your-user" -lifetime 2 Get-CIPAccount -databaseName "db-name" -AccountName "your-db-account" -lifetime 2 Other Commandlets: - Remove-CIPAccount - removes a system/domain/database account. - Centrify-GetAccountID - gets the unique identifier for an account.


Linux Client CLI Tools

The help topic contains all the commands included with the client. Let's focus on the same sequence above, but for Linux.

What you need:

  1. PKI Trust pre-requisite
    The IWA root certificate for the service or tenant should be trusted (manually or via enterprise trust); same for the certificate used for SSL for the platform (not an issue with SaaS, but yes with customer managed if not following proper PKI practices).  This MFA-centric article, discusses the topic.
  2. CentrifyCC bits
    These can be obtained from the Infrastructure > Linux Agent section of the Admin Portal, from the Centrify Repo, or distributed via RPM.
  3. Sudo or superuser-like privileges.


CLI in Action

Enrollment with cenroll

# E.g. Enroll code, FQDN, Name, and endpoint are required, sets are optional.
# Enrollment Code: B8674D29-890C-4036-AEAB-682DBEF6CA78
# FQDN or IP: centos7.centrify.vms
# Name: centos7-v
# Service Address:  https://vault.centrify.vms
# Sets:  PCI and Engineering 

$ sudo cenroll --tenant vault.centrify.vms 
--code B8674D29-890C-4036-AEAB-682DBEF6CA78 --verbose --features all
--agentauth identity-broker-users --name centos7
--address centos7.centrify.vms --resource-set PCI, Engineering Enrolling in Centrify identity platform https://vault.centrify.vms/
using enrollment code... Feature enabled: Application-to-Application Password Management Feature enabled: Centrify Agent Authentication Starting Centrify agent... Centrify agent started. [output truncated]


Adding account passwords to the vault with csetaccount

# Set the account password to something random 
# Send it as a parameter for csetaccount using the --stdin option
# Always clean-up.

# Creating random string
sudo cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1 
> /tmp/temp.file # Changing account password sudo yes `cat /tmp/temp.file` | passwd root # Vaulting the credential sudo csetaccount --verbose --managed=true --stdin root < /tmp/temp.file verbose: setting account through cclient # Housekeeping sudo rm -f /tmp/temp.file


The account and password are onboarded under the system in question.



The system rotates the password immediately.


The system can read and delete the password (ready for the EoL use case).


Deleting an account and unenrolling a system

# Deleting an account from the vault
$ sudo cdelaccount --silent root

# Unenrolling a system (e.g. prior to decommision or termination) using the 
# system account $ sudo cunenroll --delete --machine

The Linux agent allows for the onboarding of database (Oracle, SQL Server) or Active Directory domain retrieval for CLI or machine to machine scenarios (see cgetaccount).


AWS and GCP Automation

In AWS and GCP, the lifecycle (launch instance/terminate instance) can be automated using the methods above and Centrify has provided some assets also available via GitHub.


Below are the variables that require information (to vault systems automatically):

# Specify the customer tenant URL to enroll in cenroll CLI

# Specify the enrollment code to use in cenroll CLI

# Specify the roles to grant "AgentAuth" right in cenroll CLI

# Specify the features to enable in cenroll CLI

# Specify the type of network address. Possible values:
# "PublicIP" (default), "PrivateIP" or "HostName"

# Specify the prefix of the login name to use for this computer in the Centrify
# identity platform. The format is <prefix>-<AWS instance ID>.


Expect the methods to continue to evolve, just like the system types and capabilities are added monthly.


We want to hear from you

What can we improve?  Always use the comments or leverage the idea exchange and community.

In this post, I cover some of the key audit events Centrify captures, where one can find them if they want to send these logs to SIEMs and other tools.


In this article, we outline the steps to create the pre-requisite building-blocks of a test lab for Centrify Privilege Service customer-managed on-premises deployments.


  • Setup Active Directory, DNS and Certificate Services
  • Setup a Management Server (consoles)
  • Setup Shared Storage  and Disks
        - Using FreeNAS
        - Using Microsoft File and Storage Services
        - Using NetApp Ontap
        - Formatting Disks
  • Configuring Cluster Nodes
  • Set up a Windows Cluster
  • Configure Connector Systems
  • Request an SSL Certificate (with the private key)
  • Download Centrify Privilege Service


Proposed Lab Diagram


I - Setting-up Active Directory and Basic Services
(with DNS and Certificate Services) and adding domain-joined systems

This is considered baseline infrastructure (and knowledge).  We will defer this section to other resources:

II - Your Management Server

Typically you should not be running software in domain controllers or critical servers; however in Windows you need to have a management server; ideally a secure workstation.  The administrative consoles required are:

  • Active Directory Users and Computers - used to perform AD operations.
  • DNS Management - used in this lab to create/delete a CNAME record.
  • Failover Cluster Manager - used for Windows Clustering operations.
    To install the 3 consoles above with PowerShell
    Install-WindowsFeature RSAT-DNS, RSAT-ADDS-Tools, RSAT-Clustering, GPMC
  • Centrify Access Manager - used to manage Centrify zone data in Active Directory.
  • Centrify Audit Analyzer - used to review SSH or Windows recorded sessions.
  • Group Policy Management - used to set up any relevant policies.

III - Setting-up Shared Storage

  iscsi.pngYou need either a real NAS/SAN setup, or you can build it using iSCSI. 

Sample PowerShell (for the Windows setup)

# Housekeeping
Import-Module -Name ServerManager

# Installing features (e.g. File and Storage Services, iSCSI and Clustering console)
Install-WindowsFeature FS-iSCSITarget-Server, iSCSITarget-VSS-VDS
Install-WindowsFeature RSAT-Clustering

# Create iSCSI Virtual Disks (e.g. disk path c:\CPS)
Import-Module -Name iSCSITarget
New-IscsiVirtualDisk -UseFixed -Path c:\CPS\cps-data.vhdx -Size 10GB
New-IscsiVirtualDisk -UseFixed -Path c:\CPS\cps-witness.vhdx -Size 520MB 

# Create iSCSI Targets (e.g. 2-node cluster with and 22)
New-IscsiServerTarget -TargetName cps-target -InitiatorId IPAddress:, IPAddress:

# Associate Disks with Target (e.g. disk path c:\CPS)
Add-IscsiVirtualDiskTargetMapping -TargetName cps-target -Path c:\CPS\cps-data.vhdx
Add-IscsiVirtualDiskTargetMapping -TargetName cps-target -Path c:\CPS\cps-witness.vhdx


The setup consists in 2 disks:

- A data disk that will contain the Privilege Service database; the capacity has to be set based on the nature of your lab environment.  The 100GB size has been chosen arbitrarily The data disk is formatted with NTFS and has two folders:

  • cps-db:  the folder designated for the database.
  • backups: the folder designated for backups.

- A witness disk that will support the Windows Failover Cluster in establishing quorum.

This disk only needs to be formatted using NTFS.


Warning:  Although you will be setting online, formatting and configuring the logical drives in one system, it's possible that the drive letters get changed after the Windows Cluster is set up.  Keep this in mind.


IV - Cluster Nodes


Note:  At the time of this writing, the cluster nodes must run Windows Server 2012 R2.

  1. Log on to the first node using a domain user with local administrative rights.
  2. Install the Windows Failover Cluster Feature (and management tools).
    Install-WindowsFeature Failover-Clustering, RSAT-Clustering
  3. Run a Windows Update
    (this is to make sure your system is up-to-date).
    Reboot if needed.
  4. Open the iSCSI initiator application (answer Yes when prompted to start the service automatically).
  5. Type the name of the system hosting your shared storage (e.g. freenas) and press connect.
  6. Open Disk Management (you should see the two disks);
  7. Right-click the first disk (on the left square), select Online (repeat for the second disk).
  8. Right-click the first disk (on the left square), select Initialize Disk;  Press OK.
  9. Right-click the first disk and select New Simple Volume.  Follow the wizard and:
    Format: NTFS (quick format).
    Size: Maximum
    Volume Label:  cps-disk
    Drive Letter: E:\
  10. Right-click the second disk and select New Simple Volume.  Follow the wizard and:
    Format: NTFS (quick format).
    Size: Maximum.
    Volume Label:  cps-witness.
    Drive Letter: F:\
  11. Open Windows Explorer and in drive E:\ create two folders:  cps-db and backups.
  12. Log on to the 2nd cluster and repeat steps 1-4; repeat until all cluster members have confirmed iSCSI service automatic startup and verified access to the shared disks.

V - Setting-up a Windows Cluster

  1. Sign-in to one of your cluster nodes, and open Windows Service Failover Cluster  (as an Administrative Account).
  2. Select Create Cluster on the right Actions pane.  This starts the Create Cluster Wizard:
    - Before you begin:  Press next.
    - Select servers:  press Browse and select the cluster nodes; after these nodes are verified, press next.
    At this point, you may have to run the validation tests on the cluster.  Make sure you address any issues in this process.
    - Access point for administering cluster:  type the planned name for the cluster (e.g. cpsha) and IP address.
    - Confirmation:  make sure the "add all eligible storage to the cluster'  check is set and press Next.
    - Press finish when complete.
  3. In your newly created cluster, navigate to Storage > Disks.  Inspect the cluster Disks.  Make sure the large capacity disk continues to be the E:\ drive.  If this is not the case, in the bottom pane, right-click and select Change Drive Letter

VI - Centrify Connector Systems

Connectors can run on any current Windows 64-bit system.

  1. Sign-in to Windows with an administrative account.
  2. Run Windows Update.
  3. Reboot if necessary.

VII - Requesting an SSL Certificate (with the private key)

Before you request the certificate to be used for privilege service, you must know the service address (FQDN to be used).  For example:;  When requesting your SSL cert, make sure you add the Subject Alternative Names/DNS entries for the service name, and servicename+zso (if planning SmartCard or YubiKey authentication).

The request process varies depending  on what Certification Authority is being used.

Here are some useful links:


VIII - Download Centrify Privilege Service

  1. Log on to the Customer Support Site.
  2. Navigate to downloads.
  3. Add your code to Privilege Service On-Premises.
  4. Download (version 17.7 and above).





SSL Certificate

Windows Cluster



Putting-it all together, this is what you should have so far:

  • A Windows cluster with no roles (ideally 3 nodes to maintain HA while maintaining one node).
  • The cluster has connected to shared storage:
    E:\ for CPS database.
    F:\ for the cluster witness.
  • At leatst 2 domain-joined Windows systems that will act as Centrify Connectors.
  • A utility server with the required consoles (ADUC, Failover Clustering, DNS Management, etc).
  • Centrify Privilege Service 17.7 (and above) downloaded.
  • A PFX file for the x.509 SSL certificate and the service name in the SAN (e.g.
  • A network accessible location with all the files (installation bits, setup keys and SSL certificate).
  • A PFX file for the x.509 SSL certificate and the service name in the SAN (e.g.


Privilege Service On Premises -  High Availability - Where to next?

CoreOS Container Linux identities can be vaulted in stored in the Centrify Infrastructure Service Shared Account Password Management.


This article belongs to a series of blog posts related to the customer-managed version of Centrify Privilege Service. In this particular entry we center the discussion around strategies for Disaster Recovery.  If this is the first article you are reading, I recommend you go to the High Availability with Windows Server Failover Clustering post.


A quick primer on Disaster Recovery

 Based on Wikipedia's definition, Disaster recovery (DR) involves a set of policies, tools and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster.


DR differs from high-availability on one fundamental aspect: in a disaster, depending on the environment, type of issue and recovery strategies, there's a high-probability of data loss. For example, if the suitable recovery is either from a backup or a low latency replicated file, the data loss is in the gap between backup and restoration (or replication and recovery). A lot of the strategies are situation-dependent; perhaps a natural disaster has left the main site unable to function, and the DR systems take over while the other site is brought back on line.

When breaking-down any security controls there are preventive, detective and corrective controls:


Preventive Controls - High-availability mechanisms

See these posts that discuss topics around HA, backups and replication.

Detective Controls 

Privilege Service can be monitored via application monitoring, Windows Cluster Service events and connector monitoring.

Corrective Controls 

This is the core of this blog post. We will try to describe the people-process-technology needs for effective disaster recovery of privilege service.




Security practitioners agree that that in DR scenarios some infrastructure systems may not be recoverable at its full capacity because of the circumstance or because of the infrastructure design of the disaster recovery site. Rarely the DR site has the same specs of the real data center site (with the exception of ISPs or Public Cloud providers).

Finally, your disaster recovery strategy has to align with the business continuity plan and have clear point and time objectives.   Success in DR scenarios are dependent on having clear recovery point and time goals,  planning, policy, procedures and having well-trained people who have practiced recovery.


Planning for Disaster Recovery

Here are some discussion and planning topics:

- Do you understand the DR site connectivity and infrastructure?
- Is Active Directory present in the DR site?
- Is DNS present in the DR site?
These are basic questions. A baseline infrastructure is needed for the recovery to work.


- Are there any core infrastructure components (like core switches, routers, systems, databases, secrets) that are crucial in a DR scenario?
If you answer yes to this question, you should have a sealed envelope (or other electronic means) to get access to key credentials. This is because the vault needs storage, network, AD and DNS to work; but depending on the disaster recovery strategy, you may need credentials to get to the point of recovering the vault.


- Do you have a stand-by server or remote cluster pre-staged in the DR site?
This will speed-up the recovery. Once Storage, Network, Active Directory and DNS are up and running, CPS recovery can commence.


- Do you have the right people in place, with clear instructions on how to communicate and coordinate during the recovery? Are the designated leads familiar and capable of restoring Privilege Service?
This topic should be self-evident. DR exercises can flush out issues in these areas.

- Data layer - what's the strategy? backups vs. replicated database file?  How frequently backups are made and replicated to the DR site (or the how frequently the database file copy is replicated)
This consideration is all about speed of recovery.


- Is the cluster configuration file available?
This is quite important.  If you need to restore from backup or create your additional node, the configuration file has crucial information required during recovery.


- How the system is being used?
In environments where secure session access is more prevalent than password checkouts, there will be less data loss because the passwords are mostly unknown (except when break glass is needed).


In this exercise

  1. We have a stand-by Server in our DR site.
    Strategies may vary - you may need a cluster, but you can have a "single master" with your secrets to support the recovery effort This system may be part of the cluster (if it spans multiple sites), or simply a single-master server that has been configured to participate in the current installation (by using the configuration file).
  2. Choose your strategy based on your environment (or scenario)
    E.g. restore from backup or restore from file.
  3. Perform the recovery
  4. Test your results.
  5. Adjust any changes (generate report, update accounts)


Setting-up a Stand-by Recovery Server

  1. Install Windows Server 2012 R2 based on your corporate image.
  2. Configure the logical disks to match the original installation and create the folder structure.
  3. Set-up Centrify Privilege Service. 
  4. Configure Privilege Service with the cluster configuration file.
  5. Optional:  Add to Windows Clustering.


Restoring from Backup

Restoring from backup is quite simple with CPS, the only consideration is data loss. This is dependent on how the system is used and the backup frequency.  Time to recovery is dependent solely dependencies (such as storage, network and systems for recovery) and on how familiar the tech leads are with the restore process.


What you need

  • backup files
  • configuration file (if no stand-by system is available)
  • access to DNS system
  1. Log in to your DR Windows 2012 R2 system (with administrative credentials)
  2. Make sure the system has the same logical letter layout as the cluster nodes (e.g. if the database was configured with the e:\cps-db folder, this must be consistent).
  3. Optional: If you don't have a stand-by system, read the section above.
  4. In DNS, set up a CNAME record for the CPS service address (e.g. and point to your recovery server.
  5. Start the web and database Service (set to manual given that WSFC controls this normally).
    Start-Service W3SVC
    Start-Service cisdb-pgsql
  6. Run the restore program using the backup files.
On the scripts folder, type:
$ .\pg_restore.ps1  -SourceDir e:\backups -initdb -verbose


Now it's time to verify that the system can authenticate local (Centrify Directory users), followed by adding Connectors.


Restoring from Replicated Database file  (or orphaned file)

The consideration continues to be data loss. However, in this case, depending on the latency and replication frequency, this may be a very close copy of what was in production before the disaster struck.  The database engine and transaction logs will take care of the integrity of the data.


What you need

  • replicated file (or left-behind database)
  • configuration file (if no stand-by system is available)
  • access to DNS system
  1. Log in to your DR Windows 2012 R2 system (with administrative credentials)
  2. Make sure the system has the same logical letter layout as the cluster nodes (e.g. if the database was configured with the e:\cps-db folder, this must be consistent).
  3. Copy the replicated file to the destination that is expected based on the installation (e.g. E:\cps-db).
  4. Optional:See the previous sections.
  5. In DNS, set up a CNAME record for the CPS service address (e.g. and point to your recovery server
  6. Start the web and database Service (set to manual given that WSFC controls this normally - you may have to adjust depending on the length of the disaster).
  7. Verify that the system is working as expected

Restoring Normal Operations

The prescription of this section is dependent on the circumstance.

  • If the main site is unrecoverable, then you must plan to complete the cluster and add connectors to service the remaining sites.
  • If the main site is recoverable, then this depends on how you used the system.  If you had checkouts of accounts, those would have been rotated after use; those passwords will need to be updated once the original CPS cluster is back online.
  • Once everything is ready to resume normal operations, delete the CNAME record created during recovery and set the services to  manual (if they were changed).

Centrify Connectors and Disaster Recovery

Centrify connectors provide many services and for CPS they are absolutely needed, this means that you should have either connectors in your DR site (even if they are underutilized) or have the ability to spin them really quickly after the CPS server infrastructure is back up again.


Videos (wip)



Privilege Service On Premises -  High Availability and Disaster Recovery - Where to next?

Starting with version 17.7 of Centrify Privilege Service (customer managed/on premises), the standalone option has been removed and only highly-available configurations leveraging Windows Server Failover Clustering are supported.


This blog covers the process of upgrading Centrify Privilege Service while maintaining high-availability.


The Upgrade Process


upg-pro.png Cluster Upgrade Requirements

  • As of this writing, CPS On-Premises runs on Windows Server 2012 R2.
  • The upgrade requires at least 2 nodes, and ideally 3 nodes (to have at least a 2-node cluster when an upgrade is in progress).
  • Access and administrative rights to the Windows Cluster.
  • Centrify Privilege Service software (the version to upgrade to).
  • Administrative rights in the cluster nodes to perform the upgrade.

 Connector Upgrade Requirements

  • Connectors can run on Windows Server 2012R2 and up.
  • Since connectors are highly-available by default, all you have to worry about is having multiple systems servicing important sites or identify any subnets, systems, databases or domains that are serviced by an individual connector. 
    For those, a maintenance window is required.
  • Another consideration for the upgrade is current sessions when SSH or RDP and other dedicated connectors like for AD or LDAP Proxying and RADIUS.

 Steps Overview

 A. Cluster Node Maintenance Mode

  1. Log in to your Windows Server Failover Cluster console system.
  2. Open Failover Cluster Manager and connect to your cluster.
  3. Review the current Role owner.
  4. Review any issues with the cluster.
    Check the cluster events (or your SIEM console).  It's not a good idea to ride unhealthy clusters.
  5. Set your passive node in maintenance.  Nodes > [nodename] > Pause > Drain Roles

B. Running Privilege Service Upgrade (or System Patching)

  1. Log in to your cluster node (the one that was put on maintenance).
  2. Run the Centrify Privilege Service setup program (or other maintenance like Windows or hardware patching).
    For CPS upgrade, expect to do this process at least twice.  During upgrade, the setup program will attempt to talk to the active node.
  3. For CPS upgrade: Answer the PowerShell prompt.
    Note:  There are really only two options:  Y or N.  The default is N because you have to repeat the upgrade for all nodes until you reach the last one.

C. Reviewing IIS Application Pool Status  (only if using early access or prerelease)

  1. Open IIS Manager
  2. Navigate to Application pools and verify that the Centrify app pool is running.
  3. If it's stopped, start it.  If all of them are stopped and you get a Windows Process Activation error, you may have to reboot due to Windows Update dependency issue.

D. Getting the node system back in service

  1. Log in to your Windows Server Failover Cluster console system.
  2. Open Failover Cluster Manager and connect to your cluster
  3. Resume your recently upgraded node  (Cluster > Nodes > [node] > Resume > Do not Fail Roles Back)
  4. Transfer the CPS Role ownership to the recently-upgraded node.
  5. Monitor the Cluster transfer, IIS Service and Database Service (for example, the database service on node1).
    Get-Service cisdb-pgsql -ComputerName node1.example.vms

F. Verifying functionality

  1. Log on to privilege service
  2. In the upper right corner icon (your name is displayed), select About.
    This should reflect the new upgrade version.
  3. If this was the first node, repeat the same process from A to F until  you are done with all nodes.


Upgrading the Centrify Connector Infrastructure
Connectors provide CPS with the ability to reach systems, domains, databases, public/private clouds and offer an array of services including session and audit capture.  Connectors can be upgraded manually or automatically.  The options are outlined below:



Connector Planning Topics

  • What are the capabilities of the existing connectors, what AD or LDAP domains do they serve, are they at the same version level?
  • Are there any subnets, systems, databases or domains that are only being serviced by only one connector?
    Based on the screen shot above, looks like this subnet is under-served (only one connector).  Time to plan for a maintenance window, or add another connector to provide high-availability.
  • For IaaS (like Azure, AWS or Google Cloud):  Are there any Centrify connectors that may not have persistent connectivity to the server nodes?


Video - Upgrading a 3-Node Cluster and 2 Connectors
(17 min)

Privilege Service On Premises -  High Availablility - Where to next?

This article belongs to a series of blogs on the Customer-managed version of Privilege Service (now part of Centrify Infrastructure Services).  The topic is high-availability and in customer managed deployments, the Windows Server Failover Service (WSFC) is the key enabler for this capability.  In this article we'll discuss and demo some of the failover tests in a lab environment to illustrate.  If you're looking to create a similar test scenario, check out the previous article in the series: Installing Centrify Privilege Service + High-Availability with Windows Failover Clustering.


Success Criteria

High-availability is all about business continuity in case of known risks like software or hardware issues.  The goal of any computer system is to aim for 100% uptime, but from a mathematical standpoint this is impossible, however it's quite clear that a system that holds passwords should provide not only high-availability capabilities, but also recoverability and disaster recovery.   The focus of this lab is to work on the HA scenarios. 

This all starts with an impact assessment of the information system to the organization's business continuity.  The CIA rating (confidentiality-integrity-availability) will indicate importance when the last number is significant.  For this lab, we've come up with the


Simple Test Form


Test Environment



Windows Failover Clustering - Dependencies and Policies 101

Each "Role" in a Windows Server Failover cluster has dependencies.  The CPS generic script (iis_pgsql_cluster) has the following dependencies: network, storage (designated disk), role DNS name, the IIS service and the Centrify Identity Platform Database (cisdb-pgsql).

For more information about dependencies, please review some other examples from Microsoft TechNet articles:


The behavior of the roles in the cluster and its dependencies is highly customizable in WSFC; however, when performing this type of testing it's important o understand if the system is responding according to policy.  For example, let's explore the failover policy for the Centrify Privilege Service role (as configured by default in a 3-node cluster).
This means that the cluster will not restart if it fails "n-1" times.  In this case, this is a 3-node cluster.  After, 2 failures, the cluster needs to be restarted manually, and if it's within the 6 hour interval, each failure will make it stay down.

In addition, you can have a "preferred"  active node (perhaps one that has more resources).  Let's now inspect the policy for the Centrify generic script:


This means that within a 15 minute period, on IIS or PostgreSQL failure, the first failure will restart the corresponding service, the second failure within the period will force a node transfer from active (2nd failure) to the next best node.

The same policies exist at the disk, network and server name.


Finally, the reason for this explanation has to do with the evaluation of your tests.  For example, if I was testing HA failure of a service component (like the database), an excerpt of my testing looks like this:


Time Action Expected Result Results
T1:00 Stop the cisdb-pgsql service. Owner: node-1
The service will restart in the same node.
Up to T1:15, another failure of the web service or database will trigger a node change.
T1:05 Stop the World Wide
Web Publishing
Owner: node-2
The 'vault' role will be moved to the best possible node due to policy.


The other reason why we're covering this is to encourage critical thinking.  The policy settings for a lab or demo environment are very different than a production system, and the input goes directly to IT or security operations, in addition operator actions well-documented (as process), as well as trained technical personnel.


Testing Cadence (generic)

  1. Note the details about the test (time, current node in WSFC and in CPS, service status, etc)
  2. Have an understanding of the policy and expected results based on timing and environment.
  3. Cause the test failure
  4. Record the results.  Any deviation from expected results needs to be investigated.


Privilege Service HA Testing (videos)


  • Maintaining HA when putting an active node in maintenance mode (paused).
  • Maintaining HA while the database is being backed-up.
  • Maintaining HA during Centrify Privilege Service Upgrade (shutdown the active node during upgrade).
  • Maintaining HA during Centrify Connector Upgrade.


  • Stop the World Wide Web Publishing Service - based on rules, the service is restarted.
  • Stop the Centrify Identity Platform Database - based on rules and timing, the active node is transferred.


  • Simulate a Network Card failure (in this environment, also causes a Storage failure due to iSCSI)
  • Poweroff a CPS Service Active Node

Privilege Service On Premises -  High Availablility - Where to next?

As some of you know, Privilege Service (now part of Infrastructure Services) was designed as an Infrastructure-as-a-Service (IaaS) solution, and after it's relase and due to customer demand, we released a "customer-managed" version designed to be deployed and operated in an on-premises setting.

The goal of the lab is set-up the building-blocks to test the high availability capabilities of Privilege Service by leveraging Windows Server Failover Clustering (WSFC).


Lab Design




The design of this lab is based on the following test scenarios:

  • Administrative Failover (upgrades, patches, etc).
  • System, Network or Storage failure.
  • Connector Failover Strategy.
  • Disaster Recovery (backup/restore, orphaned or replicated database).


Process Overview


 What's required

Summarized Windows Failover Clustering requirements
Detailed requirements here:

  • Active Directory - required for management and role computer objects, delegation and name resolution (DNS).
  • Redundant Shared Storage  -  WSFC orchestrates the storage switching between active and passive nodes.
  • Redundant Network Components -  this is a requirement of any modern clustering technology (including WSFC) to provide the assurance of communications via multiple paths, backup network cards, etc. 
  • At least 3 Windows Server (2012R2) with Windows Failover Clustering and connected to the Storage and Network layers for the CPS Server and at least 2 to act as Centrify Connectors.  This will provide the assurance that even when the Windows servers are being updated (or Centrify's software) there is at least a 2-node cluster in service.
  •  A properly set-up Windows Cluster, passes all the key validation tests during cluster setup.

Note: If this will be a test lab, and data availability is not important, you can use iSCSI virtual disks and virtual network components.  Using such a configuration in a production environment does not constitute an effective availability control.


Centrify Privilege Service requirements

  • Have a planned hostname and URL for the service (e.g.
  • A static IP address for the corresponding role in Windows Failover Clustering.
  • Obtain an x.509 SSL certificate from a public or enterprise CA with the planned name for the service.
    (If planning to use Smart Cards, make sure the service name and the servicename +zso is added in the DNS name of the x.509 certificate.  E.g.  vault.centrify.vms, vaultszo.centrify.vms).  Make sure you have the password if the cert is protected.
  • Privilege Service software - minimum version 17.7.161 with PostgreSQL back-end.
  • Windows Cluster Nodes (ideally 3, and minimally 2)
    These are Windows Server 2012 R2 with Quad Cores and 16GB of RAM.  Plan for 50-100GB for the data.
  • At least 2 Windows Servers to be used as Centrify Connectors (to maintain high-availability).
    These are current 64-bit Windows Systems with Dual Core and 8GB of RAM
  • A Windows administrator (that can add/remove systems from the domain and local admin rights).
  • You should have or be ready to install a Windows Failover Cluster (DNS name and IP address decided) (e.g. cpsha/

What you should be familiar with

  1. Understanding of TCP/IP and name resolution, plus the ability to create DNS records and verify name resolution.
  2. Understanding of Active Directory administration and privileges to create computer objects.
  3. Administrative rights and familiarity with Microsoft Management Consoles like the Failover Cluster Manager tool.
  4. Understanding of  network attached storage (e.g. iSCSI or FibreChannel) partitions, volumes, logical disks.
  5. Understanding of Public Key Infrastructure concepts.



  • Is the cluster ready or does it need to be created, are the name and IP address secured?
  • What will be the name of the service? (e.g.
  • Have you secured a static IP address for the service name?
  • What will be the shared logical disk path for the Centrify Privilege Service database?  (e.g. E:\cps-db).
  • What will be the procedure to handle the configuration file?
    This file contains configuration, encryption and recovery data (without it, no new nodes can be added, and recovery from backup or orphaned database is impossible).
  • Is there a test plan to verify the highly available or recovery test cases?  (see subsequent post).
  • Are the ports required for CPS communication and Centrify Connectors clearly understood?
    E.g. HTTP and HTTPS (TCP 80/443), PostgreSQL (TCP/UDP 5432),  DirectConnect (TCP 30001).


Sample Lab Planning Notes


Block Diagram of Customer-Managed Privilege Service



Installation Overview

  1. Verify Pre-Requisites.
  2. First Node:  Installation and Verification.
  3. Installing Additional Nodes.
  4. Configuring Windows Failover Clustering for Centrify Privilege Service.
  5. Testing Administrative Failover.


Verifying Pre-Requisites
These steps are performed to make sure the Windows Failover Clustering components are ready for Centrify Privilege Service.

  1. Verify Communications with the cluster
    • Verify cluster Active Directory object (e.g. verify that the computer object in AD is alive an well).
    • Verify cluster DNS name resolution  (e.g. ping the cluster name from all systems).
    • Verify CPS port communications (e.g verify the Windows firewall and check for CPS communications).
  2. Open Windows Failover Clustering and connect to your cluster
  3. Verify Validation Report of the cluster  (Right-click Cluster > View Validation Report).
    What are you looking for?  Any warnings or errors in the report.  For example, the lab I'm using has a few flaws:
    Node member3.centrify.vms is reachable from Node member2.centrify.vms by only one 
    pair of network interfaces. It is possible that this network path is a single point
    of failure for communication within the cluster. Please verify that this single path
    is highly available, or consider adding additional networks to the cluster.
    There you have it.  I have only one NIC card, this is a single-point of failure.  In a truly highly-available scenario, I'd probably have a pair of NIC cards dedicated to communication and/or storage and a heartbeat interface (just to talk to the cluster), this multiplies the risk per each node added.
  4. Verify Storage Layer and Disk Layout
    • Make sure you understand the disk layout (e.g. logical letter and database and backups location); e.g. E:\cps-db and E:\backups.
    • Verify that all cluster members can own the shared storage.  (Pause each member and verify the storage switch).


First Node - Installation

Set all nodes but the first node to maintenance mode and secure the storage folder.

  1. Log on to your First node as a Windows Administrator (e.g. node-1).
  2. Open Failover Cluster Manager and connect to your cluster.
  3. Navigate to Cluster > Nodes and right click node-2, select  Pause > Drain Roles.
  4. Repeat for all except for the current node  (e.g. node-3, node-4 and so on).
  5. Verify that the shared disk designated for the CPS database is mounted in the current system.
    E.g. open Windows explorer and navigate to the designated drive (e.g. E:\).
  6. Optional:  If you haven't done so, create a folder for the CPS database (e.g. E:\cps-db).

Set name resolution of the service to the first node.
This step is required because during installation the setup the program will need to get a token from the web service, and it thas to be resolvable by name.  This step will be undone before the additional nodes are added.

  1. Open your DNS Management tool (e.g. DNS Manager).
  2. Create a new CNAME record in your DNS zone.  The record should be called as the service name (e.g. vault).  The CNAME should point to your node-1 system.
  3. Verify by pinging the service name (E.g. vault.centrify.vms) from all the systems.
    PS C:\> ping vault
    Pinging node-1.centrify.vms [] with 32 bytes of data:
    Reply from bytes=32 time<1ms TTL=128
    Reply from bytes=32 time<1ms TTL=128
    [output truncated]

Install Privilege Service (GUI installation)

  1. Run the Privilege Service installation program, this will start the setup wizard.
  2. Welcome Page > Press Next.
  3. EULA Page > Check the box and press Next.
  4. License Information > Type the case sensitive Company Name and Key, press Next.
  5. Feature Selection page > Select "Clustered Primary" and press Next.
  6. Destination Folder page > Select the preferred location (typically not the shared drive, this is NOT the database path).
  7. Ready to Install page > Press Install.
  8. Completed page> Press Finish (answer YES to the UAC prompt).

Install Privilege Service (PowerShell)
This part consists in answering these questions:

[output truncated]
Centrify Identity Service setup - Host Type: Primary
Starting clustered host setup: Thu, 28 Sep 2017 06:24:56 GMT

1. What username should the initial administrator account be created with?
(default: admin@opie.demo): Sample answer:
Don't select a suffix that conflicts internally, and retain this name because
it's the default sysadmin.
2. Initial administrator email address? (default:
Sample answer:
This address will only be relevant once the system is SMTP-enabled, feel free to
use your valid business e-mail address.

3. Initial administrator password?: ******** 4. Verify administrator password?: ********
Sample answer: Use a strong password or paraphrase, plan to change after setup.

5. FQDN to be used for this service? (default:
Sample answer:
This is the service name. When planning, make sure you understand the needs for
the service because once installed, it will respond just to that URL over HTTPS.

6. Would you like to provide a custom host certificate, if not, one will be
generated for you? [Y/N] (default: Y):
The best answer is Y, and to provide a valid x.509 SSL certificate. Although the
auto-generated cert, may be OK for testing, use a real cert for production.

7. Does your certificate require a password? [Y/N] (default: Y): N
Sample Answer: N (if it does not require it), answer Y and provide if needed.
8. Please Select folder for the service databases
This is when you browse for the database location. This has to be in a folder
on the cluster shared storage.
db.png [output truncated]
                       Setup / recovery file creation
 Setup will now create a zip file that contains important information needed
 to configure other cluster servers or to restore the database onto new systems
 in particular it contains non recoverable encryption keys. Centrify will not be able
 to recover backups without this file
 NOTE: The database backup tools do NOT backup it up
recovery.png Now browse for the location of this file. Secure accordingly because without it you
can't add any new nodes, restore from backup or orphaned database.

When CPS is ready, it's time to verify that it's set.

[output truncated]
Internet services successfully stopped
Stopping Postgres Service
Starting Postgres Service
Starting IIS
Attempting start...

Internet services successfully started

   Finished! Your system is now ready to be used via: https://vault.centrify.vms

Finishing web setup ...
Setup standalone/database host completed: Thu, 28 Sep 2017 06:41:21 GMT


First Node - Verification

  1. Browse to your service address (e.g.
    Note that if you did not get a good certificate (e.g. self-signed), your browser may require an exception.
  2. Attempt to log in with the credentials from the previous step (e.g.
  3. Navigate between the user and admin portals.
  4. Optionally, you can upload the configuration file ( as a secret.
    1. In the admin portal, go to Infrastructure > Secrets.
    2. Press Add File and Name it "CPS config file" and browse to the config file location.
    3. Press Save.
  5. Exit Privilege Service.


Adding Additional Nodes

  1. Sign-in to your next node (e.g. node-2) with administrative credentials.
  2. Run Privilege Service GUI Setup and this time, select Secondary Node and advance until PowerShell Configuration.
  3. During PowerShell, you'll get asked the location of the file created with the first node.
    Sample output:
    [output truncated]
    Centrify Identity Service setup - Host Type: Secondary
    Starting clustered host setup: Thu, 28 Sep 2017 05:04:15 GMT
    Stopping existing services
    Stopping IIS
    Attempting stop...
    Internet services successfully stopped
    Stopping existing services
    Stopping IIS
    Attempting stop...
    Internet services successfully stopped
    Initializing configuration for secondary server
    Ensuring VC redist is installed
    Please Select location of cluster config zip file
    This file was created in the 'config' directory of the primary server
    [output truncated] Trusting CA for this Machine Setup of secondary completed: Thu, 28 Sep 2017 07:35:58 GMT
  4. Repeat the process (1-3) in all the additional nodes.
  5. When completed with all nodes, copy the configuration file to a secure thumb drive, make copies and distribute securely and delete the configuration file from the primary node.


Configure Windows Server Failover Cluster for Privilege Service
Get the system, cluster and DNS ready

  1. Log in to your primary server (the one that is currently running).
  2. Stop the Centrify Identity Service Database Service and the Web Server.
    Use the services applet, or PowerShell (Admin):
    Stop-Service cisdb-pgsql
    Stop-Service W3SVC
  3. Open Windows Failover Cluster and resume the nodes in maintenance (note that if you choose to fail roles back, this may shift the disks).
  4. Use your DNS Management tool to erase the CNAME record that was created in the previous section.  The reason for this is that the new service (a WSFC Role) will have a DNS name controlled by Windows Clustering.
  5. Make sure that the service's DNS record vault is not resolvable by any of the systems.  If required, flush the DNS cache using the ipconfig /flushdns command.
    c:> ping vault
    Ping request could not find the host vault.  Please check the name and try again.

Installing Privilege Service as a Windows Failover Cluster Role

  1. Verify that the Centrify Identity Platform Database is stopped in the last active node.
  2. Open Failover Cluster Manager and connect to the cluster.
  3. Verify that all cluster nodes where CPS is installed are in the cluster.
  4. Right Click Roles and Select "Configure Role"; this starts the role configuration wizard.
  5. Before you begin page > press Next.
  6. Select Role page > select  Generic Script.
  7. Generic Script info page > Type or paste the path below, then press Next.
    C:\Program Files\Centrify\Centrify Identity Platform\scripts\iis_pgsql_cluster.vbs
  8. Client Access Point page > In Name, type the shortname for the service (e.g. vault) and the IP address for the service.
    If you get an error stating that the network name is in use, this means that you have not cleaned-up DNS or the system cache.
  9. Storage page > Check the box next-to the logical disk (this will be the same logical letter and drive that has the folder with the CPS database information).
    We have been consistently using the E:\ drive in this example.  Note that there are other ways to do this setup, one includes installing the cluster AFTER CPS installation, in that case, the "Cluster validation tests"  can potentially change the logical lettering of the drive.  Make sure this is kept consistent.
  10. Summary page > press Finish.
  11. Now it's time to inspect the role, and verify what is the active node.  Click on Roles and refresh.  You should see the service name and the current owner node.
  12. Use your browser to connect to the service again.  When you sign-in, go to the upper-right menu under the user name.

Testing an Administrative Failover

  1. On Windows failover cluster, connect to the cluster.
  2. Right-click the newly-created role (with the service name, e.g. vault) and elect Move > Best Available Node.
    This step will move the cluster ownership to another node.  Note the name.
  3. You can monitor the status of the service in the remote node (e.g. member4.centrify.vms)
    PS C:\> Get-Service cisdb-pgsql -ComputerName member4
    Status   Name               DisplayName
    ------   ----               -----------
    Running  cisdb-pgsql        Centrify Identity Service Database
    PS C:\> Get-Service w3svc -ComputerName member4
    Status   Name               DisplayName
    ------   ----               -----------
    Running  w3svc              World Wide Web Publishing Service
  4. Once you have confirmed the transfer was succesful, refresh your browser and confirm the  ownership.  Keep testing until all nodes are validated.
    At this point, after verifying administrative node change to all systems, we can add our connectors.

Adding Centrify Connectors

In this version, the Centrify Connector service cannot be used inside any of the cluster nodes.  To install a connector:

  1. Log on to a Windows 2012R2 (and up) 64 bit system.
  2. Open your browser and navigate to the service address (e.g.
  3. Go to Settings > Network and press Add Centrify Connector.
    For more detail on Centrify Connector setup, review this article:
  4. Once your connectors are installed, you can authenticate AD users and perform CPS services like Discovery or Import.



 What's next:  Configuration?

The next article on this series covers failover testing, however, for some of the testing to be complete, you must configure the system to be functional (populate sytstems, etc); configuring CPS is not in the scope of this article, however, here are some configuration items (in checklist form)

  • Verify that AD users can authenticate
  • Configure SMTP, Google Maps API or Twilio Service settings.
  • Configure Policies for User Access.
  • Configure System and Account Security Settings.
  • Configure Resource Subnet Mapping.
  • Create Roles and assign administrative roles (e.g. Privilege Service User, Privilege Service Administrator).
  • Configure and run a Network Discovery.
  • Import systems, accounts via CSV import.
  • Onboard Databases and Secrets.
  • Set up Workflow.
  • Configure SSH Gateway Settings.


Privilege Service On Premises -  High Availablility - Where to next?

After Preparing for your Privilege Management Deployment with the Centrify Infrastructure Service - Part 1, you will want to configure your Active Directory connection and start considering your network environment.



There are a lot of configurations that can be done before importing systems and managing accounts for Privilege Management in our Infrastructure Service. 


Before you get started, you will need to choose a deployment option. Centrify offers two methods that you can choose from for your organization. You can choose to use our cloud based service or to manage your own systems with our on-premises customer-managed deployment option. 


If you are looking to try this out for the first time, then you can sign up for a trial here -


-If you are going with the cloud deployment option, then you will need a Centrify tenant with the Privilege Service enabled. Your organization may already have one, but if not then you will need to start a new trial using the link above.


-If you are going with the customer-managed deployment option, then you will need to download and install the Centrify Privilege Service. If you have not purchased this software, then you can sign up for a trial using the link above.


-You will want to have at least two Centrify Directory Service accounts in System Administrator Role. This is to ensure that you are not the sole owner of administrative credentials to the service, in case of emergency. Also, it is a good practice to have some backdoor accounts that are still accessible in case the Active Directory connection is unavailable.


 System Administrator Role Memebers.png












Adding Centrify Directory Users

Creating Centrify Platform Administrators

System Administrator Role Permissions


-You will want to have a customized login suffix. This will be a unique suffix that your users will type to login. The login suffix also tell the authentication engine which identity repository and tenant to log a user into.


 Login Suffix.png














Creating a login suffix

How to use login suffixes


-You will want to have a customized tenant URL configured. This URL should be easy for users at your company to remember. You can create it in your Admin Portal Settings > Customization > Login > Tenant URLs.


Tenant URLS.png














 Tenant URLs


-You will want to define user security policies for login authentication to the Centrify Admin and User Portals.  You will want to determine wether additional forms of authentication, besides their passwords, will be required when users log in to the Centrify Platform. Enabling login authentication in the user security policies will allow you to set what conditions users are required to present a second or third authentication mechanism, like if they are outside of the corporate network.


Login Authentication User Security Policy.png




























Setting authentication policy controls 

Creating authentication rules

Creating authentication profiles

Authentication mechanisms


-If you are requiring a second or third authentication mechanism for login, then you will want to make sure that your users will be able to satisfy any authentication challenges that they are required to approve. 


What you need for each authentication mechanism


  • For SMS/text challenges, then check that the mobile attribute, specifically is set for your users in Active Directory and Centrify Directory. 


  • For phone call challenges, then check that any phone number attribute is set for your users in Active Directory and Centrify Directory


  • For email authentication mechanisms, check that the mail attribute exists and has been set for your users in Active Directory and Centrify Directory.


  • For RADIUS as an authentication mechanism, add the RADIUS server information, enable your Connector(s) to work as RADIUS clients, and enable the RADIUS policy. Also, the Connector(s) that you enable as RADIUS clients will need to be added to your RADIUS server  as a RADIUS client.


Enable 3rd Party RADIUS Authentication.png



























How to configure Centrify Identity Services platform for RADIUS

Configuring Connector as a RADIUS client

Configuring the Centrify Connector for use as a RADIUS client

Configuring a RADIUS server


  • If using OATH for MFA, configure OATH policy


Allow OATH OTP Intergration.png


























How to configure OATH OTP 





You can add an icon and link to your Identity Service Portal that takes you directly to the Privilege Service. 



Screen Shot 2017-09-22 at 1.24.38 PM.png


Centrify provides secure access to servers without exposing the password for shared privileged accounts such as root, (domain) administrator, or service accounts. By default, Centrify opens a secure shell or remote desktop session to the target system through the web browser. If you are connecting from inside the network,  you can configure Centrify to use the native SSH or RDP client instead of the browser. For instructions to set this up in Centrify, go to:


To complete this configuration for SSH this article will show you how to configure the Windows Path to locate the desired SSH client to use. Setting the path and environment variables will differ depending on the version of Windows you have on your computer. Administrator privileges are usually required to modify the path and environmental variables.


Windows 8 and Windows 10

  1. From the Desktop, right-click the very bottom left corner of the screen to get the Power User Task Menu.
  2. From the Power User Task Menu, click System.
  3. Click the Advanced System Settings link in the left column. Note: In Windows 10, you may need to scroll down to the Related settings section and click the System info link. In the System window that opens, click the Advanced system settings link in the left column.
  4. In the System Properties window, click on the Advanced tab, then click the Environment Variables button near the bottom of that tab.
  5. In the Environment Variables window (pictured below), highlight the Path variable in the "System variables" section and click the Edit button. Modify the path line by appending the path to the SSH client to the end. Each different directory is separated with a semicolon as shown below. See the example below in red.

C:\Windows\System32;C:\Windows;C:\Program Files;C:\Program Files (x86)\Centrify\Centrify PuTTY\




Windows 7, Windows Server 2008 and Windows Server 2012

  1. From the Desktop, right-click the Computer icon and select Properties. (For Windows Server 2012 and up, right-click on the icon labeled This PC.) If you don't have a Computer icon on your desktop, click the Start button, right-click the Computer or This PC option in the Start Menu, and select Properties
  2. Click the Advanced System Settings link in the left column.
  3. In the System Properties window, click on the Advanced tab, then click the Environment Variables button near the bottom of that tab.
  4. In the Environment Variables window (pictured below), highlight the Path variable in the "System variables" section and click the Edit button. Modify the path line by appending the path to the SSH client to the end. Each different directory is separated with a semicolon as shown below. See the example below in red.

    C:\Windows\System32;C:\Windows;C:\Program Files;C:\Program Files (x86)\Centrify\Centrify PuTTY\




As part of the security toolbox, we must deal with shared credentials, more specifically passwords.  Many of you know how Infrastructure Services can secure credentials, however, a lot of work is going on to enhance the DevOps or automation use cases.  In this article we'll explore the options available to retrieve passwords from the CLI using Centrify, how it works, how it's secured and how programs or scripts to retrieve them.

Using shared passwords in CLI scenarios while maintaining assurance

Passwords have been hard to get rid of, unfortunately, even with old technologies like Kerberos and PKI we must accommodate for the need to securely retrieve credentials.  However, at the same time we need to maintain assurance and enforce principles like:

  • Try to eliminate passwords
  • Limit lateral movement
  • Just in time/just enough access/privileges
  • Identity Assurance
  • Monitoring and Auditing
  • Policy enforcement, etc

The maturity model illustrates this best:

maturity model.png 

Eliminate Passwords

Centrify eliminates passwords in this use case by relying on PKI credentials; the process happens during enrollment when a system is onboarded by an authorized party.  The enrollment process looks like this:


Each system is represented by a service account in Centrify Infrastructure Service.  Please note that in order to modify the PKI settings on a system, you must have administrative rights (you you require privileged access on the client side), plus you must have either an enrollment code or a user credential of a user that can enroll a system into Centrify Infrastructure Services. 


In Linux, this is implemented with the cenroll command.  If ther's a manual enrollment, we also ask for MFA based on authentication profiles like here (enrolls a system called centos7 to a vault.centrify.vms using the admin@opie.demo credential and enables all features):

sudo cenroll --tenant vault.centrify.vms --user admin@opie.demo 
--verbose --features all --agentauth identity-broker-users
--name centos7 --address centos7.centrify.vms


If an Enrollment code is available, you can use it (the most common way of doing this, especially for automation), here's how it looks on Windows, with a code (enrolls a system called member-vault using an enrollment code):

Enroll-CIPSystem -EnrollCode "THISIS-WHERE-YOUR-CODE-GOES"  
-FQDN 'member.centrify.vms' -ResourceName 'member-vault'
-Endpoint 'https://vault.centrify.vms'


Access Control, Entitlements and Visibility
Centrify relies heavily on role-based access, but this is an interesting use case because it's highly-related to automation.  In this scenario, most likely a system will be built, and as part of the on-boarding it will automatically enroll to the Centrify platform.  Centrify includes a built-in group called:  Centrify Agent Computers;  by default, this group has visibility to systems, domains and databases.


As a best practice, don't overload the Centrify Agent Computers built-in group.  Just use it for visibility purposes.  Create sets and other roles, and leverage those instead.


For accounts, there are several entitlements

This means that you need View+Check out at the account level to check out a password.  This is a mechanism for least access and limiting lateral movement.


Policy Enforcement and Monitoring

The most common password checkout policies (like multi-checkout or lifetime) are geared towards interactive use, but for machine communications, Centrify offers the ability to override the checkout lifetime settings at the account level.



A great policy that can be implemented is the use of internal/external, datetime or even Risk.  This can be applied at the account level.



Because a compromised system, although with limited access is still a potential "stakeout" point, monitoring service account checkouts outside the applicable time or at a rate that is out of the blue, the monitoring and alerting capabilites of CIP provide several tools like:  Dashboards, Reports or the ability to send events to a security operations or SIEM tool.



Deployment Utilities

  • Enrollment codes:  allow Centrify clients to enroll the platform automatically.  The benefit of codes is that you can add restrictions (like how many times or from which networks they can be used) or organizational options like sets or RBAC.
  • Sets:  Sets are collections of objects in CPS; they allow for dynamic or static membership as well as controlling permissions.
  • Packages:  The CLI toolkits are delivered as part of the Centrify clients for Linux or Windows.
  • Policy overrides:  Password lifetime overrides allow for different policies at the parent or account levels.  This is useful when you need policies for human beings vs. machines.



The Centrify Agent for Linux, leverages the cgetaccount command (checking out the opieadmin local account password from as system called engcen6 for 5 minutes).


Here's more info about cgetaccount.

Here's how it looks in PowerShell  (checking out the sa SQL server account from the database enterprise for 2 minutes)



Note that these examples are interactive checkouts.  Ideally, a script or program would call this command to retrieve the password string and use it or assign it to a variable; as you can also see, the option to specify the checkout lifetime is available.


This is an area of a lot of interest for Centrify.  Stay tuned.


Early adopters of shared account password management  (SAPM) solutions have discovered that a single strategy (e.g. password-driven) does not provide the assurance for modern IT infrastructure.  Despite the quick way some audit comments can be mitigated with a shared password solution, when you explore the modern enterprise, there are many issues and opportunities for improvement.  In this article, we'll discuss the challenges with vaults, and how with Centrify we can either compensate, enhance or consolidate security capabilities.

The idea is to explore each topic, and propose and demonstrate a scenario, provide recommendations and use an example with Centrify Infrastructure Services. 


You can also use this series to explore the capabilities of Centrify Privilege Service (a.k.a Centrify's vault)


The Traditional Password-Driven PIM Design and its Challenges


The illustration above provides a generic diagram for a password-driven PIM design; the whole premise of this design was that if you can control access to the password of a shared privileged account, provide secure access services (like terminal/desktop transport, auditing and recording) all via the vault and centralize access via a portal, then the issue could be resolved.  In time, many issues were observed:

  • "Productivity-driven" abuse:  when vault users suddenly "camp" (check out credentials for a long time), lobby for multi-checkouts, "try to go around" the vault when they can.
  • Deferment of identity or privilege consolidation:   very prevalent on the UNIX/Linux world, suddenly it was OK to continue with identity duplication in /etc/passwd, /etc/group accounts as well as managing and maintaining sudoers file configurations.  This was also influenced by the advent of DevOps solutions that make configuration management much easier.
  • Challenges for security practicioners:  Due to all the moving parts, it is hard to prove the effectiveness of these controls; there are many moving parts, and not enough compensating controls at each critical area.
  • Identity duplication:  The "vault" over time became another identity silo, especially if the design implied that all the local passwords for privileged accounts (e.g. root, administrator, etc) along with the user's "administrative, or -a" account was also living there.  This means that rather than eliminate the problem of "too many passwords" we decided to embrace it and get a tool to manage the issue.
  • Did not solve the issues faced by most enterprises:  Modern enterprises need flexibility and productivity, there are challenges with Filers, client-server applications, high-frequency transaction and other scenarios where this solution set does not provide a solution or simply does not scale well.  There are enterprises that have solved the problem of centralization, but simply chose the wrong infrastructure; and they want to come to Active Directory for more than just authentication.
  • Did not survive the test of time:  Although credential password management is one of the fundamental tools to mitigate security breaches, the goal is to achieve security assurance as threats evolve as well.  A key example is that this model does not solve issues like PTH in Windows or works well in multi-private/public cloud scenarios.
  • It's not really protecting the target systems:  This is perhaps the biggest flaw of this design.  All it's doing it's securing a privileged account password; if the system is compromised, there's no active software locally to provide assurance.



These articles will cover how Centrify Infrastructure Services addresses many of the issues outlined above, from identity consolidation to auditing and monitoring, across different platforms, however we'll do it maintaining our Identity Maturity model:

maturity model.png

 Series Content

  • Identity consolidation as a way to avoid vault-bypassing and to maintain assurance
    • Maintains productivity
    • Promotes centralized administration
    • Eliminates friction to adopt other identity-driven controls (like MFA or Risk-based access control)
    • Maintains flexibility for different types of enterprise challenges and apps
  • MFA across multiple contexts and use cases to provide identity assurance
    • At login (portal and system)
    • When using a shared account with secure access
    • When checking-ount a password 
    • When elevating privileges
    • When accessing a legacy platform
  • Securing the target systems with Centrify Zones
    • Using Centrify Local Account Management as a temporary phase
    • On the target system (UNIX, Linux or Windows)
    • Enforcing least access and least privilege
    • Embracing temporary access controls
  • Demonstrating the efectiveness of the controls
    • Monitoring (easy security operations integrations)
    • Attestation (portal, system)
    • Auditability and reportability (portal, systems)
  • Automation, DevOps and Operations
    • Components required
    • How processes are affected
    • Using an ITSM Solution to consolidate access requests

Combining Shared Accounts with Least Privilege


Article format

In each article, we'll try to define a challenge and illustrate the different ways Centrify can compenate or enhance the challenged caused by the Password-driven design.  We'll try to use existing articles when possible to reference past Tech Blogs.  As we add articles to this series, we'll list them below.



Integrating Active Directory with the Centrify Identity Platform allows you log into the Centrify Admin Portal with domain credentails. This article will walk you through the integration and System Administrator role assignment.


1. Integrate Active Directory with the Centrify Identitly Platform

Install the Centrify Connector on a 64-bit Windows member server. See instructions. Once the Centrify Connector has been installed, all domain users will now be able to log into the Centrify User Portal with domain credentials. To grant permissions to log into the Admin Portal, you will need to add the domain user(s) or group(s) to the System Adminstrator role or any other role with administrative rights.


2. Add domain user(s) or group(s) to the System Adminstrator role

a) In the Centrify Admin Portal, go to the left column and navigate to Core Services > Roles.


b) Click on the System Administrator role. 

c) Select Members then click Add and search for your desired domain user(s) and/or group(s) that you want to grant administrative rights to the Centrify Admin Portal.


Now you can log in with your domain credentials to the Centrify Admin Portal.

Ever want to generate a report for the status of particular local accounts?  Need to know  when a password is due back from a CheckOut.  Here is a quick report to have in your back pocket.  Plus you will learn how easy it is to customize reports as well.


Your Centrify Privilege Service (CPS) deployment could go a lot smoother with this checklist. This checklist is a high overview of the necesarry tasks to prepare, deploy, configure, and validate a CPS environment.


You may be familliar with storing shared account passwords and how to retreive them via password checkouts using Centrify Privilege Service (CPS).  But did you know that in addition to storing passwords, you can now also store secrets such as API keys/tokens and encryption keys within CPS?  This short article will describe how you can store these secrets and make them available for use, while ensuring their security using role-based access control and multifactor authentication.secret1.jpg






This technical blog post [with Videos] is intended to highlight the Centrify Identity Platform REST API Framework and its capabilities, specifically as it relates to automating the management of privileged accounts...


The goal of this article is to set up the building-blocks to test Centrify Server Suite and Privilege Service in an AWS environment.  This article is the foundation for several how to guides in development.


Audience:  Technical leads  looking to test capabilities in a lab environment.

Knowledge level:  You must be familiar with AWS, Linux , Windows, TCP/IP, Domain Name System and with basic Centrify product capabilities.



  1. Standard Edition Level - allows you to complete labs related to Centrify DirectControl
  2. Privilege Service Level - allows you to complete labs related to Privilege Service


Basic AWS Setup

The basic steps to set up an AWS Playground lab are:

  1. Sign Up for AWS

  2. Create an IAM User (optional)

  3. Create a Key Pair

  4. Create a Virtual Private Cloud (VPC)

  5. Create a Security Group

Once you have this set-up, we can talk about some planning scenarios.


Planning to modify your Security Rules

  1. In this playground, here's the connectivity you'll need:
    • RDP from your client to your Windows systems
    • SSH from your client to your Linux instances
    • You need your instances to talk to each other via AD ports and others (to simplify things, you can allow any traffic between your EC2 instances).

Create an S3 Bucket

Official instructions here:

  1. Sign in to the AWS Management Console and open the Amazon S3 console at
  2. Click Create Bucket.
  3. In the Create Bucket dialog box, in the Bucket Name box, type a name for your bucket (nmust be unique)
  4. In the Region box, click the region where you want the bucket to reside.
  5. Optional - Enable logging.
  6. Click Create.


Sanity Check # 1
At this point, you should have:

  • At this point you should have several credentials:
    • An amazon account (your root account) that has all the rights to your AWS account - this account is your email account.
    • If you created an IAM user, you should have that credential too.
  • An AWS key-pair that allows you to SSH into Linux instances using the ec2-user or decrypt Windows Administrator passwords.
  • You have created a virtual private cloud (VPC)
  • You have configured a security group that allows you to access the AWS EC2 instances/services  and communications between them.  You'll be using this security group for all newly-created EC2 instances.
  • You have an S3 bucket that you can use later to host files.


Active Directory in AWS

Active Directory in AWS (or other clouds) can be deployed in different ways.  This all boils down to the connectivity between corporate and AWS.  If there's a dedicated VPN, provided that DNS and Security rules are well-designed, you an either extend or duplicate your AD infrastructure in AWS.

For more information:



This article is not concerned with that.  If you are doing a lab, most likely you'll be using the scenario where AD is run in AWS (hosted by you in EC2 instances) or hosted by AWS (SimpleAD or AWS Directory Service).


1. Setting-up Active Directory in AWS

Hosting your own Active Directory Domain Controller in an AWS EC2 Instance

There are many resources like the official recipe from Amazon here:, however for a small lab, I recommend that you have the following:

  • One VPC
  • One EC2 Instance running your domain controller and DNS (you could also leverage Route53)
  • One EC2 Instance running your member server (e.g. APP1 or MEMBER)

For setup, you can can reuse the instructions from the Microsoft Test Lab Guides to onboard a DC1 and APP1 servers.


2. Configuring Microsoft DNS with a  Forwarder

If you are managing your own DC running Microsoft DNS, as a measure, you may want to add the Amazon-provided DNS servers as forwarders.  This will ensure public name resolution to AD clients.

On your DC, in an administrative powershell, run this command:

Set-DnsServerForwarder -IPAddress "w.x.y.z" -PassThru

Where w.x.y.z is your Amazon-provided DNS server IP address.


Using an Amazon-hosted option

Simple AD:

Active Directory:


Note that whether you set up your own, or are using a hosted option, you should have the domain name,  IP address(es) for the domain controller(s) and an admin credential.  The addresses are needed for the next step, and the credential is needed to manage AD with tools like AD Users and Groups.


3. Modify DHCP Option Sets to align with your new DNS

 Without properly functioning DNS, there is no Active Directory functionality.  DHCP option sets in AWS make your life very easy and you don't need to add Route53 (AWS's DNS Service) complexity.


  1. Open the Amazon VPC console at

  2. In the navigation pane, choose DHCP Options Sets.

  3. Select Create DHCP Options Sets.

  4. Add the options for your domain name and DNS Servers (your DC and the Amazon-provided DNS).  In the name tag, provide a descriptive name, domain name servers, type the IP address of the DC(s) and an Amazon-provided DNS, and the AD domain name in the domain name.

  5. Press Yes, Create
  6. In the navigation pane, choose Your VPCs.

  7. Select the VPC(s) for your lab, and select Edit DHCP Options Set from the Actions list.

  8. In the DHCP Options Set list, select the set you created  from the list, and then choose Save


Sanity Check # 2
At this point, you should have:

  • A running your domain controller managed by you or hosted Active Directory and you should be able to connect to it as an administrative user.
  • Your domain controller should be running Microsoft DNS hosting the AD records.  Write down the IP address and domain name.
  • DNS resolution in your subnets, when you launch an EC2 instance and you ping your DC by name, it should be resolvable as well as public FQDNs.


Centrify Standard Edition Lab Setup - Member Server

The member server will be running the Active Directory and Centrify tools.  In addition, we can use the server as a Centrify Connector and DirectAudit Infrastructure.  This post will focus on AD and Centrify tools:

  • DirectManage Access Manager - GUI tool manipulate Centrify data in AD
  • DirectManage PowerShell - Use PowerShell commandlets to manage Centrify data in AD
  • GPMC Extensions - configure and enforce Group Policies in UNIX, Linux and Mac systems
  • Centrify PuTTY - Leverage Kerberos with PuTTY
  • Licensing Service - A required component for Centrify Standard Edition 2017 and above
  • Report Services - Generate and customize attestation reports

Add Windows Features

  1. Launch a Windows Server (2012R2 or 2016) and log in as the local administrator.
  2. Make sure the system can ping the domain controller by name.
  3. Run PowerShell as Administrator and join the domain
    Add-Computer -DomainName -Credential
    Provide the credentials and reboot.
  4. Sign-in to your member server as your domain administrator account, re-launch PowerShell as administrator and add the Group Policy Management, DNS and Active Directory management tools.
    Add-WindowsFeature GPMC, RSAT-DNS-Server, RSAT-ADDS


Install Centrify Standard Edition Tools

  1.  Download Centrify Standard Edition 2017 (or Enterprise to use later)
  2. Unzip the file, navigate to the DirectManage folder and run Setup.  These are the components you're adding
  3. Follow the prompts.  You may have to follow the instructions to set up Report Services.  For more information go here:

 Initialize Centrify Standard Edition

  1. Double-click the Access Manager icon, this will start the setup wizard
  2. Welcome page - press next
  3. User Credentials - press next (unless you're not using a privileged user)
  4. Deployment Structure - Check the box > generate default deployment structure
  5. Choose container - Browse - Select your domain and press OK.
  6. License Container - should be set to  [your domain]/Centrify/Licenses and press Next
    You'll be informed that the container will be set as read only for all users.  Press Yes.
  7. Install License Keys - Type your centrify license key and press add, then press next
  8. Default Zone Container - Should be set to [your domain]/Centrify/Zones, press next
  9. Delegate Permission - Uncheck the box (we aren't placing systems in the default computers container)
  10. Notification Handler - Should be unchcecked, press next
  11. Summary - press next
  12. Competing Page -  press Finish.  Access Manager will open.  Close it.

Initializing Access Manager, has deployed the Centrify recommended OU structure.  This is where the objects will reside for Centrify-related data.

For more information about this OU structure, check out @Fabrice's article here:


At this point you should have the base configuration to perform the Standard Edition labs.


Sanity Check # 3

At this point, you should:

  • Have a domain-joined Windows Server and you should be able to log in with domain users.
  • The system should have the GPMC and RSAT ADDS tools
  • The system should have Centrify DirectManage Access Manager, PowerShell, PuTTY and Centrify Report Services
  • In Active Directory, you have laid-out the Centrify-recommended OU structure.


Set-up a Cast of Characters and Implement a basic Access and Privilege Model

Users, Groups and Roles

  • ad-admin - your AD Domain Administrator
  • cps-admin (privilege service) - is your
  • Lisa  -  Linux Administrator (will be a member of AWS Windows Administrator)
  • Maggie  - Windows Administrator (will be an AWS Linux Administrators)
  • Bart  - Security Officer (will be an AWS Security Analyst)
  • Homer  - An auditor (will be a Mixed Auditor)
  • ad-joiner - Service account for automated joins
  • centrify.reports - Service account for Report Services


  • Unix-Users - Catch-all group for all UNIX users (unix-users);  maggie, bart and homer are members.

Sample User Creation Script

Write-Host "Creating Users..."  -ForegroundColor red -BackgroundColor white
$ou = New-ADOrganizationalUnit -Name AWSDemo -Path "dc=example,dc=com" -ProtectedFromAccidentalDeletion $false
$oupath = (Get-ADOrganizationalUnit -Filter 'Name -like "AWSDemo"').DistinguishedName 
$passwd = (ConvertTo-SecureString "AWSPlayGround2017!@" -AsPlainText -force)
New-ADUser -Name "Lisa" -SamAccountName lisa -AccountPassword $passwd  -Description "Linux Administrator" -ChangePasswordAtLogon $false -Path $oupath -Enabled $true 
New-ADUser -Name "Bart" -SamAccountName bart -AccountPassword $passwd  -Description "Security Officer" -ChangePasswordAtLogon $false -Path $oupath -Enabled $true 
New-ADUser -Name "Maggie" -SamAccountName maggie -AccountPassword $passwd  -Description "Windows Administrator" -ChangePasswordAtLogon $false -Path $oupath -Enabled $true 
New-ADUser -Name "Homer" -SamAccountName homer -AccountPassword $passwd  -Description "Auditor (Cross-platform)" -ChangePasswordAtLogon $false -Path $oupath -Enabled $true 
New-ADGroup -Name "unix-users" -GroupCategory Security -GroupScope Global -Path $oupath
Get-ADGroup unix-users | Add-ADGroupMember -Members Lisa, Bart, Maggie, Homer
Write-Host "User creation completed."  -ForegroundColor red -BackgroundColor white

 This script creates our cast of AD users and a group inside the AWSDemo OU.  Make sure you change the text in red to fit your environment.


Create and Configure a Centrify Zone

Our zone name will be AWS, and it will have a very simple set up.  All users will be UNIX-enabled and there will be three roles:  A UNIX Sysadmin role, a Windows Sysadmin role and a regular UNIX user role.


Zone Creation and User UNIX-enablement

$zone = New-CdmZone -Name AWS -Container "CN=Zones,OU=UNIX,DC=centrify,DC=vms"
Write-Host "Unix-Enabling Users..."  -ForegroundColor red -BackgroundColor white
New-CdmUserProfile -Zone $zone –User -login lisa -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmUserProfile -Zone $zone –User -login bart -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmUserProfile -Zone $zone –User -login maggie -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmUserProfile -Zone $zone –User -login homer -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
Write-Host "Unix-enabling complete." -ForegroundColor red -BackgroundColor white

 This script creates the AWS zone and enables our users 

UNIX and Windows Admin Roles + Assignments

$cmd1 = New-CdmCommandRight -Zone $zone -Name "Run any command as root" -Pattern "*" -MatchPath "*" -Authentication user 
$cmd2 = Get-CdmPamRight -Zone $zone -Name "login-all" 
$role1 = New-CdmRole -Zone $zone -Name "UNIX Sysadmin" -UnixSysRights login, ssologin, nondzsh, visible -HasRescueRight $true -AuditLevel possible

Add-CdmCommandRight -Right $cmd1  -Role $role1 
Add-CdmPamRight  -Right $cmd2 -Role $role1 

New-CdmRoleAssignment -Zone $zone -Role $role1 -TrusteeType ADUser  -ADTrustee (Get-ADUser -Filter 'Name -like "lisa"')

$desktop1 = New-CdmDesktopRight -Zone $zone -Name "Admin Desktop" -RunasSelfGroups "Builtin\Administrators" -RequirePassword $true
$role2 = New-CdmRole -Zone $zone -Name "Windows Admin" -WinSysRights console, remote -AuditLevel possible

Add-CdmDesktopRight -Role $role2 -Right $desktop1
New-CdmRoleAssignment -Zone $zone -Role $role2 -TrusteeType ADUser  -ADTrustee (Get-ADUser -Filter 'Name -like "maggie"')

New-CdmRoleAssignment -Zone $zone -Role (Get-CdmRole -Zone $zone -Name "UNIX Login") TrusteeType ADGroup  -ADTrustee (Get-ADGroup -Filter 'Name -like "unix-users"')

This script creates the roles and assigns them to the proper users/groups




Install Centrify DirectControl and run adcheck

  1. Launch a new EC2 Linux instance (e.g. Amazon Linux)
  2. Log in as ec2-user
  3. Run sudo vi /etc/yum.repos.d/centrify.repo and populate it with:
    make sure you substitute the user/password with your own (this is in the repo page of the Download Center)
  4. Install CentrifyDC
    sudo yum install CentrifyDC
    answer any prompts that come up.
  5. Run adcheck and correct any errors
    $ adcheck
    OSCHK    : Verify that this is a supported OS                          : Pass
    PATCH    : Linux patch check                                           : Pass
    PERL     : Verify perl is present and is a good version                : Pass
    SAMBA    : Inspecting Samba installation                               : Pass
    SPACECHK : Check if there is enough disk space in /var /usr /tmp       : Pass
    HOSTNAME : Verify hostname setting                                     : Warning
             : Computer name should not be localhost or
             : localhost.localdomain. You may edit /etc/hosts or your
             : DNS server to set your hostname correctly or you must
             : use the --name option when running adjoin.
    NSHOSTS  : Check hosts line in /etc/nsswitch.conf                      : Pass
    DNSPROBE : Probe DNS server                               : Pass
    DNSPROBE : Probe DNS server                              : Warning
             : This DNS server does not respond to requests. This is a serious problem
    DNSCHECK : Analyze basic health of DNS servers                         : Warning
             : One or more DNS servers are dead or marginal.
             : Check the following IP addresses in /etc/resolv.conf.
             : The following table lists the state of all configured
             : DNS servers.
             : ( OK
             : (unknown): dead
             : Only one good DNS server was found
             : You might be able to continue but it is likely that you
             : will have problems.
             : Add more good DNS servers into /etc/resolv.conf.
    WHATSSH  : Is this an SSH that DirectControl works well with           : Pass
    SSH      : SSHD version and configuration                              : Pass
    DOMNAME  : Check that the domain name is reasonable                    : Pass
    ADDC     : Find domain controllers in DNS                              : Pass
    ADDNS    : DNS lookup of DC               : Pass
    ADPORT   : Port scan of DC   : Pass
    ADDC     : Check Domain Controllers                                    : Pass
    ADDNS    : DNS lookup of DC               : Pass
    GCPORT   : Port scan of GC   : Pass
    ADGC     : Check Global Catalog servers                                : Pass
    DCUP     : Check for operational DCs in       : Pass
    SITEUP   : Check DCs for in our site          : Pass
    DNSSYM   : Check DNS server symmetry                                   : Pass
    ADSITE   : Check that this machine's subnet is in a site known by AD   : Pass
    GSITE    : See if we think this is the correct site                    : Pass
    TIME     : Check clock synchronization                                 : Pass
    ADSYNC   : Check domains all synchronized                              : Pass
    3 warnings were encountered during check. We recommend checking these before proceeding

Make sure you correct any major errors outlined by adcheck.  The key here will be name resolution and connectivity with your domain controllers; if you laid-out your security rules correctly and have DNS set to resolve AD records, you should be fine. 


Modify default AWS EC2 SSH Server Settings

By default, OpenSSH in AWS EC2 is not configured to allow password authentication.  Although with Centrify the underlying authentication uses Kerberos to talk to DCs, ultimately the user must be allowed to type their password in an SSH session.

  1. Sign-in to your EC2 instance with the ec2-user
  2. Modify the /etc/ssh/sshd_config file and set these directives (e.g. usin vi - sudo vi /etc/ssh/sshd_config)
    PasswordAuthentication yes
    # PasswordAuthentication no 
  3. Save the file.
  4. Restart the SSH server
    sudo service sshd restart

Join your EC2 Linux instance to Active Directory Manually

$ sudo adjoin -z AWS -c "ou=servers,ou=centrify" -n demo3 -u admin
Using domain controller: writable=true
Join to, zone:AWS successful

Centrify DirectControl started.
Initializing cache
You have successfully joined the Active Directory domain:
in the Centrify DirectControl zone: CN=AWS,CN=Zones,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net

You may need to restart other services that rely upon PAM and NSS or simply
reboot the computer for proper operation.  Failure to do so may result in
login problems for AD users.


Verify your UNIX Access and Privilege model

  1. Connect to your Linux system using SSH (e.g. PuTTY or ssh), log in as one of your AD users (e.g. lisa)
    login as: lisa
    Server refused our key
    lisa@'s password:
    Created home directory
           __|  __|_  )
           _|  (     /   Amazon Linux AMI
    2 package(s) needed for security, out of 2 available
    Run "sudo yum update" to apply all updates.
  2.  Verify lisa's role using Centrify-enhance sudo
    1. $ dzinfo --role
      User: lisa
      Forced into restricted environment: No
      Centrify MFA Service authentication: Supported
        Role Name        Avail Restricted Env
        ---------------  ----- --------------
        UNIX             Yes   None

     Now you can logout Lisa.

  3. Reconnect again, and try to log in with Homer, then verify his role
    login as: homer
    Created home directory
    $ dzinfo --roles
    User: homer
    Forced into restricted environment: No
    Centrify MFA Service authentication: Supported
      Role Name        Avail Restricted Env
      ---------------  ----- --------------
      UNIX Login/AWS   Yes   None
    Note the different role for Homer.
  4. Close the session.  You have now verified your Linux access model.

Join your EC2 Windows member to the Centrify Zone

Grant your test users remote desktop access

  1. In your member server, right-click the start menu and select Run
  2. Type compmgmt.msc and press enter
  3. Navigate to Local Users and Groups > Groups and double-click Remote Desktop Users
  4. Press Add.  Now add the test users (or a group) you want to have RDP access.  E.g. (maggie)
  5. Press OK.

Install the Centrify Agent for Windows

  1. Open Windows Explorer and navigate to the folder with the Centrify Server Suite bits.
  2. Browse to the > Agent and run Centrify Agent for Windows64.exe (press Yes to the UAC prompt)
    • Welcome Page > Press Next
    • EULA Page > check the box and press Next
    • Custom Setup Page > Select only the Access Components
      (This is unless you are planning or have added DirectAudit)
    • Components Page > Next
    • Confirmation Page > Install
    • Completed Page > Make sure the "Run Agent Configuration Wizard" is checked, press Finish
  3. Now you'll configure the Agent to join your zone.  
    • Configuration Page > Press Next
    • (Optional) Associate DirectAudit Installation > Select your Installation
    • Join to a Zone > Select the zone you created earlier (AWS) and Press Next
      Note, you may be asked to add the Domain Administrators to the Login role.  You must do this, otherwise the only user that will be able to sign-in will be maggie (in this example).
    • Configuration completed, Press Finish.
  4. If asked to restart, press Yes when you are ready.

Verify your Windows Access and Privilege model

  1. Sign-in to your Windows system as a member of the Domain Admins group
  2. Right click start and run mstsc -v member -w:800 -h:600 (this launches an RDP session)
  3. Attempt to log in with maggie  (she should be able to log in) 
  4. Open the Windows systray and right-click the Centrify icon > Authorization Center and click on the Effective roles tab
  5. Note Maggie's current roles in the AWS zone.  Logoff.
  6. Repeat step 2, and now try to log in with Bart.  The result should be:
    This is because Bart has not been assigned a role that allows for Windows access.

  7. Press OK and close.  At this point, you have tested the access model on Windows.



Sanity Check # 4 

At this point you should have

  • Centrify tools installed in your member server (e.g. DirectManage)
  • You have a domain-joined Amazon linux instance 
  • In the Centrify zone, you have a linux instance and your Windows member server
  • You have tested your access and privilege model in both Linux and Windows platforms.

MILESTONE:  Now you have a system that you can use for sanity checks and to generate some of the tools required for the Standard Edition AWS labs.  This is the state of your lab:




Privilege Service Lab Setup - Centrify Tenant and Connector 

Obtain a Privilege Service Tenant

  1. Get Centrify Privilege Service
    Once your tenant is approved, you'll receive an email with your URL, credential and one-time link.  When you click on it, you will be logged-in.  Make sure you change your password.
  2. Once your tenant is set up, open its URL from the browser in your EC2 Windows instance (member server)
    Note that you may have to relax the IE ESC settings on Windows or download an alternative browser like Chrome or Firefox.  E.g.
  3. Navigate to Settings > Network and click "Add Centrify Connector";  this will download the Connector bits.
  4. Double-click the Connector zip file, and run the included setup file, this will start the wizard
    - Welcome Page - press next
    - EULA Page - check the box and press next
    - Custom Setup - only install the Centrify Connector
    - Ready to install - press next.  When complete, press Finish.  This will launch the configuration Wizard.
  5. In the Configuration Wizard:
    - Welcome Page - press next
    - Centrify Connector Configuration - provide your admin account name and password
    - Connector Configuration - Optional: check the box in the domain (you may not be able to if you're using a managed AD.
    - Connection test - should be successful if your instance is allowed to go out to the Internet, press Next
    - Configuring connector - Next and then Finish.
  6. Once completed, the Settings > Network > Centrify Connectors should display your aws connector:

Configure Resource Subnet Mapping
This step is very important, especially if you're using the Privilege Service tenant in other environments like local VMs.

  1. Log in to privilege manager (
  2. Go to Settings click on Resource Subnet Mapping and Press Add
  3. Type the CDIR for your AWS Subnet (repeat if you have many - e.g.
  4. Select "Choose" and check the box next to your AWS Windows Server running the Centrify Connector.
  5. Press Save.


Sanity Check # 5
At this point, you should:

  • Have a Privilege Service tenant and you should know its URL, an admin user and password.
  • Have a privilege service should ready to authenticate your AD users (see below) and to provide password and session services for your AWS subnet.

MILESTONE: You should be ready to perform the AWS Privilege Service Labs, and this should be the state of your lab.



Related Articles
Creating a Kerberos Keytab for DirectControl joins/unjoins:

Using AWS OpsWorks (Chef 12) to deploy Centrify DirectControl on EC2 Linux instances:


In a previous article titled "How to Use DirectControl to Facilitate Kerberos-based Oracle SSO on Unix and Linux", we discussed how the Centrify DirectControl agent can be leveraged to allow Active Directory users to authenticate to an Oracle database seemlessly and securely without having to enter their username and password. Unfortunately, allowing AD-based Single Sign-On for end users is only half of the battle for Oracle-related accounts.


By default, there are over 28 predefined accounts (administrative & non-administrative) and several, additional schema accounts created during an Oracle database installation. Only a few of these accounts are addressed during the Oracle installer and let you update the password; most of the others are automatically expired and locked. This leaves the Oracle DBA to manage those accounts and come up with a strategy for properly securing the passwords.


The Centrify Privilege Service (CPS) is an Enterprise access management and password service that can group databases and secure internal database accounts for both Oracle and SQL Server databases. In this article, we'll see how we can add an Oracle database to CPS, add accounts (managed & non-managed), and then create sets of databases in order to implement additional access control over these accounts.



  • Oracle 11g or 12c Database software installed and functioning properly on a Centrify-supported Linux server (The Centrify Server Suite agent, DirectControl, doesn't need to be installed)
  • The latest instance of Centrify Privilege Service, deployed either as a cloud-integrated component to the Centrify Identity Service (CIS) or as a standalone service deployed on-premises. This article uses the CIS cloud-integrated deployment option.
  • The accounts you manage must be configured to include the CREATE SESSION privilege
  • Management of the password for the SYS account is not supported by the Centrify Privilege Service because it requires a physical password file.
  • You must install the ODP.NET client library on the same machine where the Centrify Connector is installed. You can download the Oracle ODP.NET managed driver ( from the Oracle downloads website or here. If you download and install the library after you install the Centrify Connector, you should restart the Connector before adding the database to CPS. If a newer version of the client library is available, keep in mind that only the baseline version ( and the latest version available are supported.
  • Centrify Privilege Service can manage the account password for standalone Oracle server. However, the Centrify Privilege Service does not synchronize managed passwords across computers in a cluster at this time.


Step 1 - Decide which Oracle Accounts to Add to CPS

Typically, the SYSTEM administrative account is the first account that DBA's like to protect the password for; this is because it is used the most often. However, there are many additional accounts, both administrative and non-administrative, that may be in scope for your requirements.


A simple question that you can ask is, "what type of functionality will I need to enable as part of my Oracle database installation?". You can then select the associated administrative accounts and use those and the intiial accounts to add into CPS for management.


You will then need to decide which of those accounts that you would like CPS to manage. Having a "managed" account means that CPS will securely vault the password, set it to a random, secure string, and then rotate it whenever the password is checked back in or whenever it is forced to rotate.


Step 2 - Add an Oracle Database(s) to CPS

  • Authenticate to your CPS tenant as a user with the sysadmin administrative right
  • Select the Databases tab; then click Add Database to open the Add Database Wizard
  • Type a unique name to identify the database, select the type of database service you are adding, and specify the fully-qualified DNS host name or IP address, and click Next.




NOTE: If the database type is Oracle, you must also specify a database service name and the accounts you add must be Oracle database accounts. Optionally, you can also type a longer description for the database. For example, you might want to make note of the applications the database supports or the physical location of the server, then click Next to continue.


  • Add a user name and password for an account used to access the database and specify whether the password for the account is managed by the privilege service, then click Next.
  • Select Verify Database Settings to test access to the database using the account information provided, then click Finish. If the database and account settings are successfully verified, click Close.


NOTE: If there’s an error, test network connectivity and verify that the user name and password you provided are valid for the database you are attempting to add. If verification fails, close the error message, deselect the Verify Database Settings option, then click Finish to add the database and close the Add Database Wizard. You can only deselect the Verify Database Settings option if the password for the account is unmanaged. If the password for an account is managed, the database account must be verified to ensure the correct password is stored by the privilege service.


Step 3 - Add the Database(s) to a CPS Set (optional)

If you would like to group databases together by environment or application, for example, then you might choose to create a CPS Set for the database(s). This would then allow you to apply specific policies to the CPS Set. For example, you might want to have your internal DBA's to have access to the Oracle accounts on Production databases while external consultants might only have access to the same accounts on non-Production databases. You could then decide to implement strong authentication controls for the external DBA consultants.


To create a new static Set, simply select the Sets tab next to Databases, name the Set, and then add the Database members to the Set. Once the Set is created and membership defined, you then select the Users or Groups of Users that you want to add Set and Member Permissions for.


Step 4 - Set the Permissions (& Additional Options) for Database Resources & Accounts

Once your database(s) and associated accounts are added to CPS, you will need to set permissions on both. You can also choose to enable Access Request/Workflow and set Password Checkout policies for the particular user accounts.


In the screenshot below, user dwirth has full access to the SYSTEM account for this database resource:




Step 5 - Test the Password Checkout for an Oracle Account

Once you have verified that CPS can properly communicate to the Oracle database(s), the final step is to simply confirm that you can checkout the password for one of the Oracle accounts that you have added.


From the Resources tab, rt-click on the database resource, select Account Actions, and then choose to Checkout the password. If you have enabled Workflow for this database resource, then the "Request Checkout" option should be listed for users who initiate a password checkout session:




NOTE: You can also initiate an account password checkout from the Accounts tab. Just choose Database Accounts as the seach criteria, rt-click on the account, and choose Checkout. If you have been given the proper account permission, you can also rotate the password.


NOTE: If you don't want CPS to manage a particular account when adding accounts to a database resource, then simply leave that box unchecked in the Add Database Wizard. While the password will stay statically defined to whatever you set it to, you can still use the Workflow and Policy controls to further secure the access to that account password.



As you've seen from this article, there are many pre-defined Oracle accounts that also need to be properly addressed in order to secure identities across your Oracle installations. Leaving these types of shared access account passwords unprotected will increase the chances that someone will eventually hijack the account password and use it for malicious intent.


Using your existing CPS tenant, whether it be deployed on-premises or integrated into CIS, you can quickly and efficiently secure the passwords for these accounts.


So you're already managing user accounts in Active Directory - but what about those pesky system accounts you're still managing in /etc/passwd?  Wouldn't it be great to manage them with Centrify too?  In this article we'll demonstrate how to securely manage local accounts using a comination of Centrify Server Suite and Centrify Privilege Service.  



Here's a quick report that can give you a list of resources in the Privilege Service. This is handy if you've run the Discovery tool and now want to print out your list of discovered resources. 



The Centrify Privileged Identity Management solution provides a set of controls for Google Compute Engine Linux VM Instances to support Enterprise integrated identity and access management functions. This solution enables organizations to consolidate identities, enforce cross-platform least privilege access and control shared accounts, while securing remote access and auditing all privileged sessions.


This guide will show how to setup and configure Active Directory based identity and access controls as well as privilege management for Linux VM Instances running on Google Cloud Platform. It will also show how to take over password management for local root accounts as well as to provide secure remote access to these Linux VM Instances.


Showing results for 
Search instead for 
Do you mean 

Community Control Panel