Centrify Privileged Services can be used to managed systems in the enterprise, but first these systems need to get added to the Centrify Privileged Services portal. Centrify Privileged Services gives you four different ways to add your enterprise systems to the Centrify Privileged Services Portal, these are;


  • Adding systems Manually: In this format, you can add one system at a time.
  • Running a discovery Job: In this format, you can create a discovery profile to identify the types of systems in which you are interested-such as Windows or UNIX computers then proceed to run the Discovery job to scan the network for the systems that match the criteria you have specified.
  • Bulk Import method: This format will let you download a CSV file template that you can populate with the systems that you want to add to your Centrify Privileged Services Portal. 
  • The Windows PowerShell import script: For this method, you will run an interactive Windows PowerShell script and use it to import systems to your Centrify Privileged Services portal. To read more about this, please see this TechBlog


In this article, we will focus on Option 3-adding systems to the Centrify Privileged Services portal using the Bulk Import method.


The steps in this article assume that you already have an existing Centrify Privileged Services portal set up :



Navigate to the Infrastructure> Systems section of the portal and click the Import button at the top of the page:






Upon clicking the import button, a new "Import" window opens, please click the "Bulk System Import Template" and download the file






Proceed to open the CSV template file, notice that it has template fields already populated, please edit the file with the systems you want to import. For my case, I want to import 6 systems, 3 Unix and 3 Windows systems along with the local accounts on the systems.







After saving the file, please upload the CSV file to your Centrify Portal, the import process runs in the background and depending on the number of systems and accounts you are importing, the process might take some time to complete. When the process completes, you will receive an email notification of the results when the import process is complete.


The notification email looks something like this:





As you can tell from the email above, only 5 of the 6 systems got imported successfully, the email is helpful enough to tell which system did not get imported by looking at the row referenced in the email. In my case it is row 7 which is the windows machine, please see the image below to see why it failed to get imported







Notice that the import job process could not find a Computer class type "Wlndows" so, proper spelling matters in this csv file, in order to fix this, I corrected the spelling error and re-imported the system. For the systems that successfully got imported you should be able to see them listed under the systems tab







If you also imported local accounts in addition to the systems, you should see the successful accounts listed under the Accounts tab, in the image below, the imported accounts have been marked, please see:








Once the import is done, we now focus on the really visible Red exclamation signs that are listed along the systems, and if you notice we see that the systems that have this Red exclamation sign have the "Unreachable" status in the "Last Test Result" column.  We want our systems to be reachable, otherwise whats the point of adding them to the Centrify Privileged Services portal? 







For the systems that are showing unreachable status, please click into the system itself, select "Test Connection" If the test connection test fails, the first thing I check is the status of the connectors, to make sure they are all up and running.


For my case, the Connector was in connected mode but the "Test connection" test was still failing.


- I clicked into the machine, clicked "Settings" tab and replaced the DNS Name with the IP Address of the machine under the DNS Name/IP Address field. After saving the changes and re-running the Test Connection test, the test connection was successful.










Since I also added accounts along with the systems to my Centrify Portal, I want to make sure that the accounts I added along with the systems can be used to log into the machines via the Centrify Privileged Services Portal. 


This can be done by either navigating to the Infrastructure>Accounts tab and then locating the accounts you imported here OR we could navigate to Infrastructure> Systems tab and click into the system itself then click "accounts", in the accounts section we see the account that was imported with the system.


Click into the account and select "Verify credential" option, this "Verify credential" test verifies whether the user account and password of the machine imported is the correct one. 


For my case the "verify credential" test failed for my "discovery" user account, The other test I tried is to; click the user account> click actions> select "Login" 


The user account "discovery" is able to login to the machine successfully, so we know that the credential is fine and the "Verify credential" test should have passed successfully.  



In my case, the Domain network settings firewall was turned on, I turned off the windows firewall for the Domain network settings and was able to pass the "Verify Credential" test successfully.






To learn more about Centrify Privileged Services, please see the Centrify Privileged Services administrator's guide




Download Postmanhttps://www.getpostman.com/


Authenticate before calling other API


1. StartAuthentication https://developer.centrify.com/docs/starting-the-authentication-process

POST https://aap0825.my.centrify.com/Security/StartAuthentication
             Content-Type: application/json



This article walks you through the basic configuration of setting up B2B federation from Azure AD to the Centrify Privilege Service. The benefit is that users can authenticate with Azure AD and then be granted access to Centrify Privilege Service where their authorizations can be controlled separately. 


This article walks through the configurations for controlling which privileged accounts users can see in the Centrify Admin Portal. A common use case would be to grant developers or third party vendors access to the privileged accounts they are only allowed to use.


This article walks through the configurations for controlling which server(s) or network appliance(s) users can see in the Centrify Admin Portal's list of Systems. A common use case would be to grant developers or third party vendors access to only the system(s) they are allowed to see, and without exposing all the other system names in your environment.


This article introduces the concept of B2B federation from Azure AD to Centrify Privilege Service and why some businesses are choosing this form of federation. 


A Centrify Connector on an AWS private subnet allows you to:

  • Gain better accountability of who is accessing the private subnet,
  • Apply role-base access to the private subnet,
  • Password vault local and domain service accounts being used in the private subnet,
  • Provide MFA login for Windows or Linux servers
  • Integrate with an Active Directory domain that is associated with the private subnet, 
  • Provide MFA for other AWS services such as AWS Workspaces. 

This article will go over the AWS and Centrify configurations you will need to use a Centrify Connector on an AWS private subnet.


Centrify Infrastructure Services (Privilege Access Service) has the ability to store secrets. These secrets can be free-form text or files (currently up to 5mb in size). 


There will be use cases where the contents of these secrets need to be programmatically accessed EG from inside an application or as part of orchestration/DevOps processes. 


By leveraging Centrify's OAuth2 authorization framework, this article will describe how to configure OAuth2 to enable a PowerShell script to obtain the contents of a text-based secret from the Centrify platform.


However, it does not stop there. Using this methodology (Oauth2 apps & scopes) and the example script as a base, any programmatic call to the Centrify Identity Platform required for automation may be achieved. Including writing objects such as systems, shared accounts, secrets ETC. Pretty much everything that can be done via the portal can be automated/configured programmatically. 


Whilst this example is in PowerShell any compliant code can leverage this methodology (Java, C#, Go ETC). For example, I have Python code to run SQL queries against the Centrify Identity Platform from LINUX, but that's for another post Smiley Happy


For more detail on the Centrify Identity Platform API's see https://developer.centrify.com

Bed Time reading on OAuth2 : https://tools.ietf.org/html/rfc6749


Learn the basic of Microsoft Red Forest and how Centrify can be used to provide a more effective security strategy.


Centrify Infrastructure Services (Privilege Service) can securely store account and password combinations for local accounts.


 In a break glass scenario, an authorized user can checkout a password using the Centrify mobile app.

The password can subsequently be checked in manually or automatically after a set period of time and potentially rotated if it is a managed password.



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".


Source: https://www.xkcd.com/936/


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 https://yourcompany.my.centrify.com

custom name.png


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

Centrify User Portal: https://yourcompany.my.centrify.com

Centrify Admin Portal: https://yourcompany.my.centrify.com/manage



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:
# https://gallery.technet.microsoft.com/Reset-Local-Administrator-e3023c3a # 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 "example.com" -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:  safe.example.com;  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. safe.example.com).
  • 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. safe.example.com).


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. vault.example.com) 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. vault.example.com) 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:  https://technet.microsoft.com/en-us/library/jj612869(v=ws.11).aspx

  • 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. safe.example.com).
  • 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. vault.example.com).
  • 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: admin@example.com
Don't select a suffix that conflicts internally, and retain this name because
it's the default sysadmin.
2. Initial administrator email address? (default: opiedemo@centrify.com):
Sample answer: admin@example.com
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: node-1.example.com):
Sample answer: safe.example.com
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. https://vault.example.com).
    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. admin@example.com).
  3. Navigate between the user and admin portals.
  4. Optionally, you can upload the configuration file (clconf.zip) 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 clconfig.zip 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. https://vault.example.com/manage?iwa=false)
  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 - https://www.centrify.com/free-trial/


-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: https://docs.centrify.com/en/centrify/adminref/index.html?version=1504972139#page/cloudhelp%2Fsvr_mg...


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.


Developer Portal

The solutions above address the challenge from the point of view of an infrastructure lead specifically focusing on systems.  Although in this article we don't cover this in depth, it should be known that everything in the Centrify Identity Platform uses REST APIs.


The Developer Reference pages here:  https://developer.centrify.com  are another resource in your arsenal.


The resource management API, specifically the /Servermanage/CheckoutPassword API provides the capability of password checkouts.  This reference provides the folllowing code samples:

  • cURL
  • Node JS
  • Ruby
  • JavaScript
  • Python
  • PHP
  • Java
  • C# and 
  • Go




PowerShell Sample Pages in GitHub

Many of the CIP methods are already available in PowerShell using the samples posted in Github.




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.



Showing results for 
Search instead for 
Do you mean 

Community Control Panel