Role-based access to the Centrify Identity Platform can be applied to help meet regulatory compliance and improve security by:

  • Customizing which web applications are displayed in the Centrify User Portal
  • Limiting access to privileged account passwords
  • And granting different levels of administrative rights to the Centrify Identity Platform

Roles in Centrify can be composed of users, groups and other Centrify roles from

To create and configure a Role in Centrify

1. Log into the Centrify Admin Portal, go to the left column and navigate to Core Services > Roles. 


2. Click on the Add Role button.

3. Enter a name for the Role.

4. Select Members, then click the Add button.

5. Enter keywords in the search field to display the desired user or group.

Adding users.png 

6. Select the desired user or group and click Add.

7. Select Administrative Rights to add Admin Portal rights to the role.

8. Select Assigned Applications to assign web applications to the role. 




In the last post I mentioned naming conventions, which is a great way to organize your work and ensure you are doing the right thing. Another item you can do to make your administrative tasks easier is to use Application Categories, as well as to teach end users how to use tags to organize their own views.


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.






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 /tmp/secure.pwd


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.


When Centrify built its Infrastructure Services product, implementation engineers came across many things that made it far easier to get the job done in the field. Through this field tested experience, Centrify built a script for that solution to automatically build sample OU's, groups, and content in Active Directory to make it far easier to manage the Centrify solution.


In our App Management solution however, there is a lot of flexibility on how you might build things, and sample data doesn't exist in this area. Because of this fact, this article will offer a few suggestions on sample data and practices which may make your experience with the Centrify solutions easier.


Sample Roles

In order to set up roles, it is good to understand the components of a role in the system. Within each role you have four key elements where you can specify data, or select options. Those elements are:


  1. Description - This is where you name your role, and describe it's function.
  2. Members - This is where you add users or groups to your role for whom the role has an effect.
  3. Administrative Rights - This is an optional selection, but where you can define what rights the role grants in the system.
  4. Assigned Applications - This is the Core of App management, where you assign apps to the role for users to use.


Here are some suggestions for each of these elements to help you make the system easier to use, as well as to better document your system for new users.



In the description section, there are a few things you should know. In the current version of the Centrify solution at the time this article was written, version 17.8.169 is the current version of the cloud solution. In this version and older, you cannot rename roles. In future yet to be released versions, you CAN rename a role. This is an important feature for a few reasons.


The first reason why this is important is simply for your ongoing maintenance. You may change a role periodically and not want to change all the elements of a role. As systems evolve, this is only natural. But there is another reason which is confirmed in one service, and possible in others.


The second reason is that when you federate systems, such as Centrify with your AWS environment, you will discover that you may need to select a role from within the external solution and add OUR role to their role. AWS actually has a system limitation (again, at the time of this writing), where the Centrify Role cannot have any spaces in the name. So in the event that you walk through the step by step procedure for creating the integration into another system, and you do all the member, admin rights, and assigned apps, only to find out later that the name doesn't fit the naming convention, you can at least change that in the upcoming version.


Naming Roles

Now, on to a documentation point regarding the Description Element. Naming your roles effectively will make your life a LOT easier when you implement the Centrify Solution. It is pretty clear that you can pick descriptive names, but an enhancement to this is to actually categorize your roles ahead of time. This can be a department, capability, or right the role grants to users. Now getting to how to name a role based on apps is not too hard, but let's put that off to later. The first way to identify the categories for your roles has to do with the Administrative Rights you may use with each role.


When you first build your roles, I would suggest you consider creating one role for each administrative right, just so you can put a user in that role and test out exactly how each one functions. Many are obvious, so this may become redundant. However, if you look at all the administrative rights, they actually group into a set of categories Naturally. Here are those categories starting from the top of the list when you open the dialog box to select:


  1. Device Management - There are 3 Administrative rights associated with Device Management, and define how users can interact with the Device Management features of the product.
    1. All
    2. Enroll on Behalf of Others
    3. Limited
  2. Privilege Service - There are four Administrative Rights related to Privilege Services, and these actually describe the levels of access and views into the Privilege Service.
    1. Administrator
    2. Power User
    3. User
    4. User Portal Access
  3. System Management - There are 8 Administrative Rights that focus on Systems Management. These Administrative rights are intended to control how users can administer the system and it's capabilities.
    1. Applications
    2. Federation
    3. Linux System Enrollment
    4. RADIUS
    5. Register Connector
    6. Reports
    7. Roles
    8. Users


Description Field

Now you will note, I didn't explain any of these features. This is because it is already very well documented in our help system. My recommendation to you is to have you actually leverage that help system when filling in the Description field in the Description element of the role.


Description Field Populated.png 


Administrative Rights

To get this description, you would have to click on the Administrative Rights item on the left, and hit the Learn More, as you can see below:

Description Field Image.png

That will launch you into the help system, where you will find all of the descriptions for each Administrative Right:

Administrative Rights.png

Just copy the text from under the "Associated permissions" column, and paste it into the description field of the Description Element. This will create a tool tip float as well that will allow you to float over the role in the "Roles" menu, where you see all your created roles, and you can then read the complete description when it pops up for each documented role.

Sample Roles.png


In the next article, I will complete the discussion on Roles, and then move on to other naming elements, and also using Categories and Tags.


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?

By default, Centrify automatically populates the username field with the User Principal Name for SAML web logins. However some web logins use first name space last name (eg. John Smith) instead of the full UPN format (eg. 


To configure your web app in Centrify to autopopulate with the user's first name (space) last name:

1. Edit your web app and go to Account Mapping.

2. Select Use Account Mapping Script and enter the following into the script field:


LoginUser.Username = LoginUser.FirstName + " " + LoginUser.LastName;



3. Press Save.


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?

Configuring Centrify SSO with MuleSoft (OpenID Connect)

By Centrify 4 weeks ago - last edited 4 weeks ago

Custom Web App template for OpenID Connect allows you to easily connect to MuleSoft...


mulesoft banner.png


Screenshot 2017-09-28 16.47.36.png


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?

Custom Web App template for SAML allows you to easilly connect to Pivotal Cloud Foundry...


Screenshot 2017-09-27 19.04.54.png


Often times we get asked by our customers how to get a list of SNC enabled users in SAP ABAP for licensing purposes. Here is a command that can be used to retrieve such list.




Here is the use case .

  1. Users are coming from CompanyA ( Federated Users ). IDP
  2. CompanyB is hosting  ApplicationB (SAML application or it can be any application )
  3. Technically For Company A (IDP ) ApplicationB (is the SP) , because users are coming from IDP and needs to logon to the ApplicationB.
  4. In a typical B2B setup as outlined below
  6. Once the federation is complete CompanyA users once they click on the CentrifyB2B application
  7. 1.png
  8. They are redirected to the CompanyB portal page where they see the ApplicationB that the user was given access to ( FaceBook in this example)
  9. 2.png
  10. Here is the trick scenario , CompanyA does not want the users to the CompanyB portal as shown above , they just want users to loginto  ApplicationB directly without ever seeing the Portal page of Company A.
  11. Here is how we can achieve this .
  12. On the Portal page of CompanyB where the ApplicationB ( Facebook in this example ) is published to the user portal
  13. Right click on the Name of the Application ( Facebook-B2B) and click on Copy link Address , below is a sample of the URL on how lt looks like.
  14. 4 (2).png
  16. Now Take this URL and replace the “Assertion Consumer Service URL” in the CompanyA B2B application
  17. 3.png
  18. Now at this point when the user click on the B2B application he logs into the ApplicationB directly without ever seeing the user portal of ComapnyB.
  19. Mission Accomplished per IDP customers use case.

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


Upgrading Centrify Server Suite, Std Edition 2017.1 to 2017.2 in Lab


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\




Understanding DAINFO Output

By Centrify on ‎09-14-2017 06:04 AM

Running dainfo at command line


Understanding ADINFO Output

By Centrify on ‎09-14-2017 05:48 AM


Running ADINFO what does it mean


Signed and Sealed - "Why port 389?"

By Centrify Contributor II ‎09-11-2017 09:56 AM

"Why port 389?"


A customer recently emailed me asking a few questions about the Unix agent communication security with Active Directory


  1.  "Why does the Centrify Unix agent (adclient) communicate with Active Directory over port 389?
  2. How is this communucation secured?
  3. What are the implications to Active Directory? Specifically, how do we protect Active Directory against unsigned/unencrypted LDAP requests?"


Typically, this question tends to come from Security/Compliance and Unix teams. From their vantage, interacting with LDAP over 389 raises a flag, where traditionally communications over this port tend to be unencrypted.  If the question comes from the Active Directory team, they are usually looking for confirmation and assurance that our interactions with Active Directory align with best practices and their secrity expecations.


1) Why port 389: The short answer is that the Centrify Unix agent's approach/design is consistent with how Windows computers and services securely communicate with AD and other kerberos principals. Explained below…
2) Secure Active Directory communication: The Centrify Unix agent authenticates and encrypts all communications with Active Directory using Kerberos (GSSAPI). This is referred to as a "signed and sealed" connection. The agent encrypts its payload using a kerberos session-key before sending over the wire to Active Directory. We do not use LDAP over SSL/TLS. This approach depends on certificates (along with the certificate management headaches that come with).  
3) Rejecting unsigned/unencrypted LDAP requests: Microsoft advises we configure servers to reject Simple Authentication and Security Layer (SASL) binds that do not request signing or reject LDAP simple binds that are performed in the clear. This AD group policy configuration ensures that “non-kerberized” LDAP client requests communicate with AD over SSL/TLS (e.g. Port 636). The following Microsoft article explains further. 

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.

We've had the request from some customers to be able to monitor the connection between the Centrify Connector and the Identity Platform in the cloud. Sometimes, due to Internet connectivity issues, the Connectors might stay "Inactive" as you can see below, even if the service is up and running.


Screen Shot 2017-09-05 at 17.37.39.png



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.



To capture configuration changes in Centrify Access Manager to your SIEM, you will need two things on the operating system running Access Manager 

1. Your SIEM reflector to read and send the Application event viewer to your SIEM.

2. Configure the following registry setting:


- HKLM\Software\Centrify\AuditTrail\Centrify Suite.Centrify Configuration\AuditTrailTargets (Set the value to 3.)

- OR HKLM\Software\Centrify\AuditTrail\AuditTrailTargets  (Set the value to 3.) Then delete the three child keys for HKLM\Software\Centrify\AuditTrail.


This value will write events both to the local Application event log and Direct Audit database. Events such as assigning a user to a role, creating a child zone or modifying a user's POSIX information will be logged to your SIEM.


For reference, here is the guide for all events written to the Application event log as well the syslog on Linux by the DirectAudit Agent.

Add a custom SAML script to configure where the request should be redirected base on the platform that is originating the request on SugarCRM


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.

Showing results for 
Search instead for 
Do you mean 

Community Control Panel