As Amazon AWS's popularity increases as an IaaS platform, many organizations are looking to extend current capabilities like consolidated identities and privilege management out to those environments.


AWS provides a framework for DevOps called AWS OpsWorks.  This framework allows the use of solutions like Chef or Puppet to manage the lifecycle of Linux or Windows instances.


Centrify customers and prospects have requested sample configurations to control the lifecycle of the deployment of Centrify DirectControl out in AWS.  The typical goals are:

  • Windows or Linux instances are launched in AWS
  • Centrify DirectControl is installed
  • The system is joined to Active Directory (Linux) and the Centrify Zone, Child Zone and/or Computer Role (Windows, Linux)
  • On termination, the system(s) leave the domain and Centrify zone (freeing-up the Centrify license)

This way, while the system is running:

  • Administration is Centralized and not duplicated (like with SSH keys)
  • Assurance is achieved, for example, with MFA
  • Privileged User Management is based on roles
  • There are reporting and attestation mechanisms.

Pre-flight Checklist

  • You have AWS account set up with a VPC set up correctly for DNS and Active Directory communication
  • Your account has AWSOpsWorksFullAccess and permission to create, modify, read, list and delete IAM Policies and Roles
  • You have Active Directory (managed by you or with Amazon) and a Centrify Zone
  • You have tested joining a Linux system to your AD and Centrify zone successfully.  Your users can authenticate and perform privilege management duties.
  • You have an AWS S3 Bucket and permission to create and upload files to it.
  • You have a Kerberos key table for a service account authorized to join systems to Active Directory and Centrify Zones
    For an article on this topic, click here:
  • You know the  DN for your Computers container (e.g. "ou=servers,ou=centrify"), this is where the service account can create (or delete) computer objects.
  • You have a Centrify Repo credential, zone information (E.g. Name) or an alternate repo with the Centrify packages for your platform type (yum, apt, zypper)
  • Optional:  A domain-joined Windows server with Centrify tools (for verification purposes)
  • Optional:  You have an AWS key-pair to deploy our EC2 instances to connect for troubleshooting purposes

A Centrify-AWS Lab article has been written for the pre-requisites

You need to be at the Standard Edition set up to follow this lab.



Note:  for abbreviated instructions and the source code for the methods use here, go to


Supported Platforms

  • Amazon Linux
  • Centos 7
  • Red Hat Enterprise 7
  • Ubuntu 16.04 LTS
  • Ubuntu 14.04 LTS
  • Chef 12

Configuration Overview

  1. Copy your Kerberos keytab to your S3 bucket
  2. Create an IAM policy for use by the IAM role for the instances created by OpsWorks
  3. Create an IAM role to grant EC2 instances to access AWS resources
  4. Create and configure Chef 12 OpsWorks custom stack
  5. Add a layer to your stack
  6. Add instances and troubleshooting
  7. Verifying success for provisioning and deprovisioning


Copy your Kerberos keytab to your S3 bucket

  1. Sign-in to the system that has the keytab (if the keytab file is in Linux, copy it to your Windows system)
  2. Open Go to the S3 console:
  3. Click your S3 bucket and then click upload
  4. Press Upload, click on the uploaded file and note the link.  E.g.

Create an IAM policy for use by the IAM role for the instances created by OpsWorks

  1. Go to the IAM home: and click on Policies, then Create Policy
  2. Select "Create your own Policy"
  3. In the review policy page, give it a name (e.g. Centrify-Keytab-S3-Access-Policy and a description)
  4. The policy should contain the following
    	"Version": "2012-10-17",
    	"Statement": [ 
    		"Resource":[ "arn:aws:s3:::your_s3_bucket/login.keytab" ]
    		"Action": ["ec2:*",
    		"Effect": "Allow",
    		"Resource": ["*"] 
    Substitute "your_s3_bucket" for the name of the S3 bucket you have from the AWS Centrify lab or from your environment.
  5. Press Validate Policy and then Press Create Policy.

Now you have a Policy.


Create an IAM role to grant EC2 instances to access AWS resources

  1. Go to the IAM home: and click on Policies, then Create New Role
  2. In Select Role Type  under Amazon Role Service Amazon EC2, click Select
  3. In attach policy, find the previously-created policy  (e.g. Centrify-Keytab-S3-Access-Policy) and check the box next to it, then press Next Step.
  4. In set role name and review, give the role a name and optionally a description.
  5. Click on the newly-created role and go to the Trust Relationship tab and press edit and substitute with this:
        "Version": "2012-10-17", 
        "Statement": [ 
            { "Effect": "Allow", 
            "Principal": { 
                "Service": [ "", "" ]
            }, "Action": "sts:AssumeRole" 
  6. Press Update Trust History

Now you have a role associated to your policy

Create and configure Chef 12 OpsWorks custom stack

In this step, we'll configure the stack to be used for deploying DirectControl, here we'll add custom JSON with information about your environment.


Create a Stack 

  1. Go to the AWS OpsWorks home: and Press Add Stack
  2. Select Chef 12 stack and complete the following info:
    • Name, Region and Subnet > based on your AWS Settings
    • Operating System > Linux and select your OS/version based on the supported platforms above
    • Default SSH Key > select yours if needed (do this at first to troubleshoot)
    • Use Custom Chef cookbok > Yes
    • Repository type: Git
    • Repository URL:
  3. Select Advanced Options and in Custom JSON add:
    	"CENTRIFYDC_JOIN_TO_AD": "yes",
    	"CENTRIFYDC_KEYTAB_S3_BUCKET": "centri-bucket",
    	"CENTRIFYDC_ADDITIONAL_PACKAGES": "centrifydc-openssh",
    	"CENTRIFYDC_ADJOIN_ADDITIONAL_OPTIONS": "--ldap --verbose --container ou=servers,ou=centrify"
    The information (in red) in this JSON file is based on my example configuration:
    CENTRIFY_REPO_CREDENTIAL is the cyphered username/password combination assigned to you in the Centrify Download repo page.
    CENTRIFY_ZONE_NAME is the name of the Centrify Zone in AD that I want my Linux systems to be joined to
    CENTRIFY_KEYTAB_S3_BUCKET is the name of the S3 bucket that contains the login.keytab file for the service account.
    CENTRIFY_ADJOIN_ADDITIONAL_OPTIONS:  has been set with the --container option that points to the DN of where my service account can add computer objects (e.g. ou=servers,ou=centrify)
  4. Press Add Stack

Add a Layer

The desired state is that when the system is launched, the Centrified system is joined to AD and to the Zone.  Once the system is shutdown, the system leaves AD, the Centrify license is freed and the access/privilege reports reflect the proper information.

  1. In your newly-created stack, click on layers and press Add Layer
  2. Give it a name and a short name and press Add Layer
  3. In the layers, click on Recipes tab, this will display the Custom Recipes lifecycle
    • Setup box:  centrify_agents::deploy_centrifydc
    • Shutdown box:  centrify_agents::undeploy_centrifydc
      Press Save
  4. On the Network tab, select the option based on your AWS VPC setup (e.g. Public IP addresses yes)
  5. On the Security tab, press Edit and in
    Security Groups select your Security group
    EC2 Instance Profile select the IAM Role created in the previous step (e.g. Centrify-IAM-Role-4EC2)
  6. Press Save.

Adding instances to your stack  

Adding instances is the opportunity to debug your newly-created stack recipes.

  1. In your stack, click Instances and click Add an Instance
    • Hostname:  give it a name (e.g. test1)
    • Size: select a size (e.g. t2-micro)
    • Subnet: select a subnet from your VPC (must have AD connectivity and DNS resolution)
  2. Press Add Instance
  3. Press Start


Troubleshooting and Debugging

Your troubleshooting can happen from the OpsWorks console.  If there's an issue with your setup, the console will provide you with an error and a log with the actions yielded by Chef.  For example, while debugging, I saw this issue:


Note that the erros will be quite explicit.  The category of errors that you'll see may be dependent on the sanity checks that you perform along the way.


Known Errors

  • Invalid CENTRIFYDC_ADDITIONAL_PACKAGES attribute:   the JSON value contains an invalid value.  Valid entries include:  centrifydc-openssh, centrifydc-ldapproxy, etc.  Modify the value of the custom JSON attributes in the stack.
  • Either user your-user@YOURDOMAINNAME. does not have sufficient permissions to update
    the YOUR_ZONE zone computer information: this means that the service account can't create the computer object in the target container.  Note that if you did not modify the JSON parameter for the stack called CENTRIFY_ADJOIN_ADDITIONAL_OPTIONS to have the --container switch with the proper DN, adjoin will try to add the system to the default computers container in AD.  This is atypical.


Verifying Success - Provisioning

The layman's test is to be able to sign-in to the system and perform privilege elevation

The OpsWorks console shows the system online.


In Active Directory, there should be a computer object in the target OU:


 Attestation reports can be generated with who has access to which system(s), what type of access they have, what privileged commands they can run, and where the privileges came from.



Verifying Success - Deprovisioning

 The best test here is to stop the system and verify that the objects don't exist in AD and the system no longer is present in the Access/Privilege reports.




You can leverage Centrify's Github for different private and public cloud configurations.  This scenario is only the first of many to come.   


Related Articles

Setting a Centrify AWS Test Lab:

Creating a Kerberos Keytab for DirectControl joins/unjoins:


In order to automate Active Directory instance joins and unjoins, we need a keytab file corresponding to an AD user that has the proper rights in AD and in the Centrify zone.

Because a keytab is pretty much a credential, we are going to adhere to the following principles:

  • The credential for the keytab shall have least minimum access
  • The password for the credential shall be unknown
  • The keytab file shall always be deleted once it's used.


What you'll need:

  • You may need assistance from your Active Directory lead
    • Why? First and foremost separation of duties.  Also, in practicality, the UNIX/Linux/Mac teams in enterprises are different from the AD teams.
    • What do they need to do for me?  They need to create an AD account, provide delegation (see below) and they may have to type their credential when running the adkeytab command.
    • How many times do we need to do this?  Only once. 

Create an AD User

When you create an AD service account, you have to align with the security policy governing these accounts.  The overhead can come depending on the frequency of password changes.  Since adkeytab scrambles the password and it's effectively unknown, the account can be set with a Password Never Expires/User cannot change password flag, however for due-diligence you may rotate it once a year.  Each time the password is rotated, the key table file has to be generated again.


  1. Open Active Directory Users and Computers
  2. Navigate to the container or OU for this service account
  3. Select New > User
  4. In the New Object form, set the information based on your naming convention
    Note:  the "common name" of the user is typically the same as the display name.  If this contain spaces, you have to make note of this for when you use the adkeytab command (samaccountname vs cn).
  5. In the New Object - User form, type a password and set the options according to your service account policy
    Remember, if you do the right thing, adkeytab will randomize the password and this can be a compensating control.  If you are required to change this password, you must re-generate the keytab and redistribute, otherwise your scripts or recipes will fail.

If you prefer PowerShell instead, you can use the New-ADUser commandlet.

Now you should have a service account.  Make note of the username (e.g. ad-joiner) vs. the cn (AD Joiner Service Account).


Delegate Permissions

There are 2 delegations needed to make sure the automation of joins/removals works.  The service account should be able to create/remove  computer objects in your designated AD container for UNIX/Linux or Mac systems, plus if you're using Centrify zones, the system has to have the ability to join, remove and modify computer profiles.

Optionally, there's a third delegation related to Computer Roles (contained in AD groups); for this you need to provide the "manage group membership" delegation to the target groups (or OU that contains the groups).


Let's illustrate the steps using this OU structure


 In this scenario, I plan to add the UNIX/Linux computers to the Servers SubOU under Centrify; this means that I have to delegate at that level to preserve the least privilege principle.  In a real-world deployment, you may have a different layout (perhaps based on sites), in that case you have to delegate in multiple places.


To delegate the computer object in the target OU 

  1. In ADUC (as a privileged AD user), right click the Servers SubOU and select "Delegate Control"
  2. Welcome Page > Next
  3. Users or Groups > press Add, find the service account, select and press OK, then Next
  4. Task to Delegate > Select "Create custom task to delegate" and press Next
  5. Object Type > Select "Only the following objects in the folder"; check the Computer Objects box and check  Create and Delete.
  6. Permissions tab > Check "Full Control" under permissions and press Next.
    You can dial this down, however we have this scoped down to the OU and type of object.
  7. Completing page > Finish

 Now the service account can create/remove computer objects in the Servers container.


To delegate at the Centrify Zone level

You must know all the Centrify zones that the service account will be leveraged for automation.  In my example I have one zone (AWS). Centrify provides PowerShell to perform bulk delegations (see Set-CdmDelegation, in this link)

  1. Open Centrify DirectManage Access Manager
  2. If needed, open your target zone(s)
  3. Right-click the zone and select "Delegate Zone Control"
  4. Selected Objects > Press Add and find and select  your service account, press OK and Next
  5. Tasks to Delegate > check join and modify computer operations to the zone (3 check boxes)
    Access Manager - delegation of computer ops.jpg
  6. Completing Page > Press Finish.

At this point, if you're not using DirectAuthorize Computer Roles you are done.

Note:  You can always verify delegations by running the "Zone Delegation Report"


Optional:  To delegate for Computer Roles 

Computer Roles allow the grouping of systems as "teams of servers" this gives administrators the flexibility granting access/privileges to systems to  multiple user populations, the only operation required is the the system is a "Member" of the Computer role, and this can be accomplished any time or during system setup by automating add/removal of the computer account into the AD security groups that make-up the computer role.


In my example, I'm leveraging the Centrify recommended OU structure and all my AD Security groups for the purposes of Computer Roles are stored in the Computer Roles SubOU under the Centrify OU.  This means that I only need to make one delegation.  Based on your design, this may vary and you may have to perform multiple delegations.


  1. In ADUC (as a privileged AD user), right click the Computer Roles" SubOU and select "Delegate Control"
  2. Welcome Page > Next
  3. Users or Groups > press Add, find the service account, select and press OK, then Next
  4. Task to Delegate > Select "Modify Membership of a Group" and press Next
    ADUC - delegation membership group.jpg
  5. Completing > Press Finish

From this point on, the service account will be able perform add/removals of objects into any existing or new AD group in that container.


Create the Keytab File

Creating the keytab may require two individuals.  One individual can run privileged commands on UNIX/Linux/Windows, the other is an authorized AD user that can perform certain operations on the AD user (like changing it's password).

You need to know the account's samaccounname vs the common name.  You can quickly see this using the Attribute Editor in ADUC or PowerShell

This is important because the last parameter of the adkeytab command is the common name.  If you assume they are the same, you may hit this error:


AD Object found: CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net
Error: The account name does not match the SAM account name. You must supply both on the command line.
Adkeytab return code: 23
Failed: Adopt Account: ad-joiner


Here's a simple way of constructing an adkeytab command

  • Elevation required:  root or credential for sudo or dzdo required:  sudo adkeytab
  • Operation:  adopt  (needs the sammacount name, an authorized account and the common name):  --adopt
  • Authorized user (e.g. AD administrator): --user admin
  • AD user: --samname ad-joiner
  • Keytab File name (e.g. login.keytab):  --keytab login.keytab  (the file will be owned by root)
  • Common Name (if the CN is different from samaccount name):  "AD Joiner"  (since there are spaces, it has to be double-quoted)
  • Verbose output recommended (-V)

Here's the command

dzdo adkeytab --samname ad-joiner --adopt --user admin --keytab login.keytab -V "AD Joiner"

Here's a sample output:

dzdo adkeytab --samname ad-joiner --adopt --user admin --keytab login.keytab -V "AD Joiner"
[dzdo] password for lisa:
ADKeyTab version: CentrifyDC 5.4.0-286
use machine ccache: no
server: null
user: admin
container: null
account: AD Joiner
trust: no
des: no
Attempting bind to site:Default-First-Site-Name ccache:MEMORY:0x644640
Bind successful to server
Searching for AD Object: filter = (samAccountName=ad-joiner), root = DC=awsrealm,DC=centrifying,DC=net
AD Object found: CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net
Key Version = 4
Activating AD account: CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net. Clearing existing SPNs: No
Account 'CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net' All SPNs already present
Adding managed account keys to configuration file: AD Joiner
Changing account 'AD Joiner' password with user 'rpimentel@AWSREALM.CENTRIFYING.NET' credentials.
Searching for AD Object: filter = (samAccountName=ad-joiner), root = DC=awsrealm,DC=centrifying,DC=net
AD Object found: CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net
Key Version = 5
Updated properties to config file /etc/centrifydc/centrifydc.conf.
Success: Adopt Account: AD Joiner

Verify the keytab is correct.  List the principals

 dzdo /usr/share/centrifydc/kerberos/bin/klist -kt login.keytab
Keytab name: FILE:login.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET
   5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET
   5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET
   5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET
   5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET

 Testing your Keytab for Join/Removal Operations

 You can test the keytab by removing and rejoining Active Directory.  You'll need to use kinit to authenticate with the key table file, then leverage adjoin or adleave to check the results.  Optionally, you can use the --computerrole switch of adjoin to check for those operations.


Authenticating using the key table file

  1. Sign-in to your system with a privileged user (remember, the key table file is owned by root)
  2. Change directories to the location of the key table file.
  3. Run the kdestroy command
  4. Run kinit with the kt option to get a TGT for the service account and klist to verify the TGT
    sudo /usr/share/centrifydc/kerberos/bin/kinit -kt login.keytab ad-joiner
    [dzdo] password for lisa:
    $ /usr/share/centrifydc/kerberos/bin/klist
    $ dzdo /usr/share/centrifydc/kerberos/bin/klist
    Ticket cache: FILE:/tmp/krb5cc_cdc1702888528_Hw29E6
    Default principal: ad-joiner@AWSREALM.CENTRIFYING.NET
    Valid starting       Expires              Service principal
    04/20/2017 17:59:19  04/21/2017 03:59:19  krbtgt/AWSREALM.CENTRIFYING.NET@AWSREALM.CENTRIFYING.NET
            renew until 04/21/2017 17:59:20


Testing adjoin and adleave operations

Depending on the state of your system, you may test removal or joining first.  Since my system is already joined, I'm testing removal first (note that I switched to ec2-user since I was logged in as an AD user).  Note that I'm copying the centrify-populated krb5.conf file, since this file will be rolled-back once the system left the domain.

$ dzdo su ec2-user
$ sudo cp /etc/krb5.conf .
$ sudo adleave --remove Using domain controller: writable=true Left domain. Centrify DirectControl stopped.

Attempting adjoin to the Zone an the "Utility-Servers" computer role.

$ sudo env KRB5_CONFIG=krb5.conf  /usr/share/centrifydc/kerberos/bin/kinit -kt login.keytab ad-joiner
$  sudo adjoin --zone AWS --container ou=servers,ou=centrify --computerrole Utility-Servers
Using domain controller: writable=true
Join to, zone:AWS successful

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

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


What next?

At this point you have to distribute your keytable file to your distribution points web server, repository, file share, etc. Note that this file needs to be deleted after it's used for added security.  For example, you can upload this file to an AWS S3 bucket to use it with your AWS OpsWorks or CloudFormation scripts.

Related Articles


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


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

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



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


Basic AWS Setup

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

  1. Sign Up for AWS

  2. Create an IAM User (optional)

  3. Create a Key Pair

  4. Create a Virtual Private Cloud (VPC)

  5. Create a Security Group

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


Planning to modify your Security Rules

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

Create an S3 Bucket

Official instructions here:

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


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

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


Active Directory in AWS

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

For more information:



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


1. Setting-up Active Directory in AWS

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

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

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

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


2. Configuring Microsoft DNS with a  Forwarder

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

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

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

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


Using an Amazon-hosted option

Simple AD:

Active Directory:


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


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

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


  1. Open the Amazon VPC console at

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

  3. Select Create DHCP Options Sets.

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

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

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

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


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

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


Centrify Standard Edition Lab Setup - Member Server

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

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

Add Windows Features

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


Install Centrify Standard Edition Tools

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

 Initialize Centrify Standard Edition

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

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

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


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


Sanity Check # 3

At this point, you should:

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


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

Users, Groups and Roles

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


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

Sample User Creation Script

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

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


Create and Configure a Centrify Zone

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


Zone Creation and User UNIX-enablement

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

 This script creates the AWS zone and enables our users 

UNIX and Windows Admin Roles + Assignments

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

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

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

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

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

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

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




Install Centrify DirectControl and run adcheck

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

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


Modify default AWS EC2 SSH Server Settings

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

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

Join your EC2 Linux instance to Active Directory Manually

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

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

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


Verify your UNIX Access and Privilege model

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

     Now you can logout Lisa.

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

Join your EC2 Windows member to the Centrify Zone

Grant your test users remote desktop access

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

Install the Centrify Agent for Windows

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

Verify your Windows Access and Privilege model

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

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



Sanity Check # 4 

At this point you should have

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

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




Privilege Service Lab Setup - Centrify Tenant and Connector 

Obtain a Privilege Service Tenant

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

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

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


Sanity Check # 5
At this point, you should:

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

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



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

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

[How To] - Integration Concur with Centrify Identity Service

By Centrify Contributor III on ‎04-16-2017 04:41 PM - last edited 3 weeks ago

Thank you for choosing Centrify!


The following is a step-by-step guide designed to help walk you through an integration of Concur to Centrify Identity Service. 


Install time ~ 1-3 hours



  • Concur account
  • Centrify Identity Service account
  • Active Directory
  • Windows Server for Centrify Connector (requirements below)


Let's get started


1) Log into your Centrify Identity Service tenant. 


5 - login page.png


2) Once logged on, you will be presented with Centrify’s configuration wizard. You can choose to use the wizard for general setup, however, for purposes of this guide, you can check the ‘Don’t show this to me again’ box and close the window. This will stop the wizard from appearing during the configuration process.


6 - wizard.png


3) Install the Centrify Connector following this guide:



4) Next, we must create roles in Centrify to contain the users of the Concur application. Concur has two roles a user can be assigned: (1) administrator or (2) end user. For the purposes of this guide, we will create an administrator role for all the Concur administrators and an end users role for all non-administrator users (e.g. employees of a company). To create a role, navigate to 'Roles' -> 'Add Role'. Name the role 'Concur Administrators'. 


Screenshot 2017-04-16 16.08.21.png


5) In the 'Members' tab, add the administrator users from your active directory. Members can be individual users or security groups with one or more users within the group. In this example, I've added the 'Domain Admins' group as the users who will have administrator access to Concur. 


Screenshot 2017-04-16 16.08.55.png



 6) Add another role for Concur end users. Add the appropriate users from active directory as members to the role. 


Screenshot 2017-04-16 16.09.18.pngScreenshot 2017-04-16 16.12.02.png


 7) Next, navigate to the 'Apps' menu, click 'Add Web Apps', then search for the 'Concur' application. Choose the 'Concur SAML + Provisioning' template by clicking 'Add'. 


Screenshot 2017-04-16 16.17.05.png


8) Within the 'Application Settings' page, you will see the 'Identity Provider Logout URL' and 'Download Signing Certificate'. To enable single sign-on for Concur, you must contact your Concur customer success manager and provide them the following two configurations from your Centrify Identity Service console. Download the Centrify certificate and provide the file and the logout Identity Provider Logout URL to Concur. Concur will enable single sign-on and apply the settings to your Concur tenant. 


Screenshot 2017-04-16 16.17.27.png


9) Next, open the 'User Access' tab. Select the Centrify roles you've created for Concur and click 'Save'. 


Screenshot 2017-04-16 16.17.38.png


10) When Concur has completed enabling your Concur tenant for single sign-on, log into your Centrify Identity Service user portal. Click on the Concur application tile to confirm you are able to log into Concur. 


Screenshot 2017-04-16 16.18.56.png



We hope this guide was helpful. If you have any questions, please use this forum thread as a resource or contact Centrify -


Thank you!

Thank you for choosing Centrify!


The following is a step-by-step guide designed to help walk you through an integration of Zendesk with Centrify Identity Service. 


Install time ~ 1-3 hours



  • Zendesk account
  • Centrify Identity Service account
  • Active Directory
  • Windows Server for Centrify Connector (requirements below)


Let's get started


1) Log into your Centrify Identity Service tenant. 


5 - login page.png


2) Once logged on, you will be presented with Centrify’s configuration wizard. You can choose to use the wizard for general setup, however, for purposes of this guide, you can check the ‘Don’t show this to me again’ box and close the window. This will stop the wizard from appearing during the configuration process.


6 - wizard.png


3) Install the Centrify Connector following this guide: 


4) Next, we must create roles in Centrify to contain the users of the Zendesk application. Zendesk has 3 roles (Admin, Agent and End-User) that can be leveraged. A minimum of one Centrify role must be created and mapped to a Zendesk role (See Step 32 below). For the purposes of this guide, we will create an administrators role for all the Zendesk administrators. Additional roles can be created in Centrify similarly to the administrator role done in this guide. To create a role, navigate to 'Roles' -> 'Add Role'. Name the role 'Zendesk Administrators'. 


Screenshot 2017-04-16 14.01.46.png


5) Next, navigate to the 'Members' tab and select the users that you want to grant 'Administrator' access in Zendesk. This can be individual users in active directory or a security group that contains multiple users. Search for the users or security groups and click 'Add'


Screenshot 2017-04-16 14.02.17.png


6) Next, navigate to 'Apps' menu from the navigation bar, then 'Add Web Apps'. Search for the Zendesk application and choose the 'Zendesk SAML + Provisioning' template. Click 'Add' to continue. 


Screenshot 2017-04-16 14.03.17.png


7) Click 'Yes' to continue. 


Screenshot 2017-04-16 14.03.24.png


8) Next, open a new browser tab login to Zendesk with your administrator account. Under 'Security', enable the 'Single Sign-on (SSO)' configuration, then enable 'SAML' as the protocol. 


Screenshot 2017-04-16 14.05.46.png


9) With both the Centrify 'Application Settings' page and the Zendesk 'Single sign-on (SSO)' tabs open, exchange the following configurations as illustrated below. The 'Zendesk Account Name' is your Zendesk account name which can be taken from your login URL (i.e. The '' Zendesk tenant URL will have the account name 'centrifydemo236'). Click 'Save' in both Centrify and Zendesk once complete.  


Screenshot 2017-04-16 14.07.24.png


10) Next, navigate to the 'User Access' tab in Centrify. Select the Centrify roles you created for Zendesk in Step 24. 


Screenshot 2017-04-16 14.08.39.png


11) Next, navigate to the 'Provisioning' tab. Click 'Enable provisioning for this application' and provide an administrator (1) Username, (2) Password and (3) Redirect URL in the form fields. Click 'Verify' to complete this step. 


** Provisioning allows administrators to manage Zendesk users from active directory. For example, in step 15, we added the 'Domain Admins' security group as a member to the 'Zendesk Administrators' Centrify role. Adding a new hire to the 'Domain Admins' group will prompt Centrify to auto provision a Zendesk account with administrator level access. 


Screenshot 2017-04-16 14.11.30.png


12) Once verified, scroll down to the 'Role Mappings' section and click 'Add'. As the first option, choose the 'Zendesk Administrator' role created in Step 24 and map to the 'Destination Role' 'Admin' in the Zendesk application. Click 'Done' to complete. 


Screenshot 2017-04-16 14.11.51.png


13) If you have created other roles for Zendesk, repeat the step as shown for the 'Zendesk End Users' role. 


Screenshot 2017-04-16 14.12.06.png


14) Once you've mapped all roles you've created for your Zendesk users, click 'Save' to complete the provisioning configurations. 


Screenshot 2017-04-16 14.12.20.png


15) To complete the integration, navigate to 'Settings' -> 'Users' -> 'Outbound Provisioning'. Under the 'Provisioning Enabled Applications', choose the 'Zendesk' application then click on the 'Start Sync' button. 


Screenshot 2017-04-16 14.37.44.png


16) Click the 'bypass caching and re-sync all objects' then 'Yes' to initialize the first integration and sync between Centrify and Zendesk. This step may take a few minutes depending on the number of users Centrify is provisioning into Zendesk. 


Screenshot 2017-04-16 14.12.50.png


17) Once complete, navigate to your 'User Portal' and verify that you can log into the Zendesk application by clicking on the application tile. 


Screenshot 2017-04-16 14.14.11.png


We hope this guide was helpful. If you have any questions, please use this forum thread as a resource or contact Centrify -


Thank you!

For customers that already use Symantec VIP for MFA and want to layer on the Symantec VIP MFA solution to the features that Centrify Server Suite provides, you can use this guide to add Symantec VIP MFA through PAM chaining. This allows you to leverage your existing investment in Symantec VIP until a time when you are ready to explore Centrify's fully integrated MFA Everywhere capability. 


There are many occasions where a Centrify administrator needs to change UNIX Data on a specific Centrify Zone, specially when the Zone Provisioning Agent is not enabled. For example, a Centrify admin might need to change the shell for many users at the same time. If you have a lot of users in your UNIX Data / Users folder, this could be time consuming.


You can use adedit to achieve this. Continue reading...


How Centrify Extends Audit Trail Events

By Centrify on ‎03-28-2017 09:52 PM



Audit Events have been part of DirectAudit for many major releases of Centrify Server Suite, Enterprise Edition, and the Audit Analyzer console allows auditors a convenient, central location to view audited sessions that contain audited events (or elevated privileged events). Not only can they utilize the predefined queries to quickly and efficiently find audit events, but they can create their own queries by defining search filters such as users, computers, event time, event type, and the session result.



Group Policy - Adjust Audit Trail Targets


In addition to the Audit Event framework in Audit Analyzer, there is also an obscure group policy that is available to customers called "Set Global Audit Trail Targets". This policy allows Centrify administrators to specify the target location for audit trail information, and from the Group Policy Management Editor, it is located at:


Computer Configuration > Policies > Administrative Templates > Centrify Audit Trail Settings





If you set this group policy to Not configured or Disabled, the destination of audit trail information depends on which version of DirectAudit is installed. If DirectAudit 3.2 or later is installed, audit trail information is sent to the local logging facility and DirectAudit. If a DirectAudit version earlier than 3.2 is installed, audit trail information is only sent to the local logging facility.
If you set this group policy to Enabled, you can specify the target for audit trail information. Possible settings are:
0 - Audit information is not sent.
1 - Audit information is sent to DirectAudit. This capability is supported by DirectAudit version 3.2 and later.
2 - Audit information is sent to the local logging facility (syslog on UNIX systems, Windows event log on Windows systems).
3 - Audit information is sent to both DirectAudit and the local logging facility.
NOTE: This group policy modifies the audittrail.targets setting in the centrifydc.conf agent configuration file.
Catalogued Events
When Centrify Server Suite 2015 was released, it included a new, convenient feature that documented all audit trail events into a single XML file called "AuditTrailEvents.xml", and it's located in the Centrify DirectManage installation directory on Windows. Not only were all of the events documented, they were catalogued, with each event having its own unique Event ID. Here is a short snippet of the current v2 file:


On Windows clients, the audit trail event is written in Windows Application Event Logs with the unique event ID as Event ID and a Windows Event Source called "Centrify AuditTrail V2". On Unix/Linux clients, the Event IDs are written to local syslog in the centrifyEventID field.


NOTE: Please refer to the Centrify Audit Trail Events XML documentation for a complete list of Audit Trail events and their corresponding unique Centrify Event IDs.



SIEM Integration

With the catalogued audit event file comes additional capabilities, allowing customers to use these audit events as input to their existing SIEM tools. And you can then provide alerting and notification from your monitoring tool-of-choice based on the specific event ID's that you want to query.
In a previous 4-part article, Centrify Product Manager, Satish Veerapuneni, wrote extensively about how Centrify integrates indirectly with SIEM tools (as mentioned previously) or directly with the following 3 SIEM tools:
  • Splunk
  • HP ArcSight
  • IBM QRadar
Taking the Splunk integration as one example, in order to view administrative events in the Splunk Enterprise console, you need to first install the following two Centrify apps:


Once you install these two apps, you can then begin receiving audit events from within the Splunk console. For example, when a Centrify administrator creates a new Child Zone inside of Access Manager, we can follow the lifecycle and see the end reporting result below:










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


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


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



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


Step 1 - Decide which Oracle Accounts to Add to CPS

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


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


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


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

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




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


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


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


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

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


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


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

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


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




Step 5 - Test the Password Checkout for an Oracle Account

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


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




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


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



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


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


CIS Version 17.3 adds a new feature to specify which user name format is sent to a RADIUS server during MFA.

Works with DUO, SecurID, SecureAuth, etc. 


One of the more anticipated features of the Centrify Identity Service 17.3 release is the ability to manage Windows 10 devices. This feature is currently in preview mode, but is available once enabled on your tenant. This post details the steps to enroll such a device into CIS. If you are interested in what administrators need to configure for Windows 10 mobile device management, please click here.


1. Under Settings, choose Connect to work or school.



2. Choose Connect


3. Enter your email address



4. This should locate your tenant in Centrify Identity Service. Enter your user name.



5. Enter your password



6. Choose an authentication method for multi-factor authentication



7. Respond to the challenge



8. You should see a success message, as below.



9. On the settings screen, you should see your work account similar to what is shown below



10. If you select the work account, you should see additional details similar to what is shown below



11. Log into your CIS tenant and select device tab. Your Windows 10 device is enrolled and should show here.



12. The Wipe Device and Unenroll Device actions should now be available.



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



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



Centrify Server Suite 2017's new Advanced Monitoring functionality preserves "identity context" even after the user "sudo's to root".


The new “advanced monitoring” feature adds three new functionalities:

  • Generate audit trail events when specific programs are executed by any user.
  • Generate audit trail events when any file in the directories /etc, /var/centrifyda and /var/centrifydc is modified by a non-root user.
  • Get history of programs executed in an audited session, including programs that are executed by scripts.

Analytics- How to use Centrify Analytics Engine

By Centrify on ‎03-25-2017 07:25 PM - last edited ‎05-02-2017 11:26 AM


Prerequisites   :           

 1.   Need to have Analytics Entitlement.

  1. If you do not see one please request one from your account representative.


Centrify Analytics engine uses machine learning ( User behavior and pattern discovery )to detect user anomalies/activities and generate alerts. The Administrator can then use the “Insights” Tool” to have a dashboard view , if you need to drill into a particular data set from the dashboard that information opens in the “Explorer” view.


Let’s get started .


  1. Once you open the “Analytics Portal” you will be presented with “Default Dashboards”
  2. There are 7 out of the box dashboards as we write this document
  3.  Apps ,Endpoints,MFA,Resources,Risk,User,User Experience
  4. pic-1b.png
  5. You can also create “Custom Dashboards” of your own or Import a Dashboard of particular interest shared by your colleagues from the menu shown.
  6. pic-2.png
  7. Let us take the “Apps” insights Dashboard : This dashboard Shows applications related data for users who accessed the Centrify Identity Platform. This dashboard is pre-populated using specified filters and queries
  8. pic-3.png
  9. For each data point within a dashboard, you can perform more tasks, such as    
    1. Events configurator - Shows the filters and other data used to generate the widget
    2. Expand/collapse the query window
    3. Delete the widget from the dashboard
    4. Drill into the data by clicking the widget. Opens in the Explorer view.
  10. You can add new “Widget” as shown
  11. pic-4.png
  12. Click on “Apply” once you have added the new Widget to your “Insights DashBoard”
  13. This now will give you the “Geo Location” of the App users .
  14. pic-5.png
  15. pic-6.png
  16. Once you want to drill into a query from the “Insights Dashboard” this will open in the “Explorer View”
  17. Below is a sample query for O365 application launch on 3-16-2017
  18. pic-6b.png
  19. pic-7.png
  20. You can always drill into more details of a specific data point you are interested in by
    1. Manually editing the SQL query string
    2. Manage and view default and customized queries
    3. Add more filters and data points to your query based on the existing criteria
  21. While analyzing a query on the Explorer page, you can also filter data by specific event types as shown
  22. pic-8.png
  23. This is how you can start analyzing and exploring data using Centrify Identity Analytics for endless possibilities.
  24. Please also take a look at How to Configure Risk Based Access Control - Using Analytics


How to Configure Risk Based Access Control - Using Analytics

By Centrify on ‎03-25-2017 08:55 AM - last edited ‎05-02-2017 11:27 AM

Prerequisites   :              

1.    Need to have Analytics Entitlement.

  1. If you do not see one please request one from your account representative.



  1. Creating Authentication Profiles
  2. Log in to Admin Portal , Click Settings > Authentication
  3. Click Add Profile on the Authentication Profiles page
  4. Pic-2.png
  5. Select the authentication mechanism per your requirement and save the profile.
  6. Creating Authentication Rules
  7. Log in to the Admin Portal
  8. Click Policies and select the policy you want to edit or click "Add Policy Set" to create a new one
  9. Pic-3.png
  10. Under Security Policies > Login Authentication Select “Yes” in the “Enable authentication policy controls drop-down”.
  11. Pic-4.png
  12. Click on Add Rule, under “authentication Rule” define the conditions based on “Risk Level” filter and condition using the drop-down boxes as shown.
  13. Pick the “Authentication Profile” from the drop down you have created in Step-1 you want to apply if all filters and conditions are met in the “Authentication Rule”
  14. Pic-5.png
  15. You can define the authentication challenge requirements based on user risk levels “Low”, Medium” and “High” , For example, a user attempting to log in to a Centrify Identity Platform service (i.e. an application, user portal, etc.) from an unfamiliar location , the user can be prompted for an “authentication challenge” because the “Authentication Rules/ condition correlates with a medium risk level. When this same user attempts to log in from a familiar location, he is only prompted to enter a password. You can configure these requirements using authentication rules and authentication profiles in Admin Portal as shown above.


Configuring Centrify to use the Google Authenticator to satisfy MFA challenges is a good way to give users another authentication factor. The set up is easy for end users once all of the policies are configured from an Centrify Identity Platform Administrator.


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


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


If you are already using the Centrify Identity Service for single sign-on, then your users can easily configure automatic login for the websites that they frequent. This is very beneficial for users that are accustomed to saving credentials into their browsers, since they do not have to store the credential in the Credentials Manager or Keychain.


For customers that already use Symantec VIP for MFA and want to layer on the Symantec VIP MFA solution to the features that Centrify Server Suite provides, you can use this guide to add Symantec VIP MFA through PAM chaining. This allows you to leverage your existing investment in Symantec VIP until a time when you are ready to explore Centrify's fully integrated MFA Everywhere capability. 


Protecting Azure Infrastructure

In this series we discuss how the Centrify platform can secure infrastructure running in Microsoft Azure. For those who are not familiar with Centrify, here’s an overview of the Centrify Platform and capabilities:


In this first part, we’ll focus on securing access to the Azure Portal using Identity Service. 

There are two strategies that can be used:

  • Protecting shared credentials (like the original o365 or Azure subscription account)
  • Federated SSO and just-in-time provisioning (no need to deploy an ADFS infrastructure)

Both strategies can be enhanced with:

  • Workflow and Approvals
  • Policy and Multi-factor authentication (including risk-based)


Protecting Azure Portal Shared Credentials

Shared Credentials in Azure may be sourced from different directories, but the most common use case is the subscription account.  This is typically the e-mail address of the user started the account.  This account has all the access (typically a Subscription Manager).  If your organization is already using Office365, then this is the “” account. 

In this cases, you can use the Password Wallet capabilities of Identity Service to provide fast deployment, least access management, policy controls, strong authentication, accountability and documented approvals.  Here the features that enable all these benefits:


  1. Turnkey App template
  2. Role-based Access Control (leveraging Identity Service roles and Active Directory groups)
  3. Account Mapping flexibility
  4. Policy Engine and Multi-factor Authentication
    Centrify also provides Risk-based Access Control.
  5. Workflow and Approvals (Natively or via ServiceNow™)
    Centrify can do native or ServiceNow™ approvals.  For more informationa about ServiceNow integrations, visit the ServiceNow TechCenter.


Providing Federated Access and Just-in-time Provisioning for  Azure

Just like any other SaaS application, Azure provides federated access.  In this particular case, the same functionality used for Office365 federation, provisioning and license management.  The benefits of leveraging Identity Service is that there's no need for the additional complexities and overhead of native solutions like ADFS, plus, there's added capability like we've seen above.



Benefits of using Federation and Provisioning in Azure

Users come from AD as the identity source.  This means that any add/moves or changes will reflect in the user's ability to access the service or any entitlements.

AD Security groups provide 2 great benefits around entitlements and provisioning:

  • This is because direct assignment paths are not the recommended practice.
  • You can allow the provisioning of access and roles from a single AD group membership.  



Just-in-time Provisioning

Traditionally, Microsoft has positioned DirSync as the tool for O365 provisioning; along with ADFS these are mature and effective solutions, however, they promote fragmentation.  With Centrify, both federation, policy, workflow and provisioning settings can be managed with a single administrative experience.


License Management

This is another component of O365 and Azure.  Centrify allows the centralization of these efforts and the allocation based on different provisioning rules.


For more information about how to leverage Identity Service for Azure or O365 federation, provisioning or license management, visit the O365 TechCenter.



Centrify provides several dimensions to measure application access or to determine assigned or provisioned apps.

This allows security operations to obtain timely information about events, plus the ability to attest application assignment or provisioning.







Centrify Identity Service will allow you to meet or exceed the controls required to secure Azure portal access and to provide granular access werther you are leveraging the Azure's cloud directory or are federating with your existing on-premises Active Directory.


5-Minute Video


Resources and Related Links

This week we've made available our new version of Centrify Server Suite 2017 and like any new release it's packed with new capabilities, features and bug fixes.  This post will allow you to explore what's new in this release and what are the some key planning considerations for successful deployment.


What's new on Server Suite 2017


  • Kerberos Library Upgrade: In this release, Kerberos libraries have been upgraded to MIT  5-1.14.1.
  • Flexible Authentication Secure Tunneling (FAST):  Also known as Kerberos armoring, secures pre-authentication traffic and protects KDCs from error spoofing.
  • This upgrade allows support for Smart Cards using AES-256 encryption.  Centrify has tested with Oberthur ID One 128 v5.5 Dual SHA256 and G&D FIPS 201 SCE 3.2 SHA256 Cards.

Flexible open-source packaging

  • cdc-dep.pngCentrify DirectControl has leveraged OSS packages (OpenLDAP, cURL and OpenSSL); in versions prior to 2017 updating these packages required a re-spin of the whole suite (in all supported platforms)
  • Starting with CSS 2017 (DirectControl 5.4) the packages for cURL, OpenSSL and OpenLDAP are independent and can be separately updated, this will allow for faster response to any CVEs that apply to those components.


  • Implemented transaction control for LRPC2, this provides security improvements over heavy load.  Requires that both DirectControl and DirectAudit are upgraded.
  • MFA: Since Centrify Identity Service version 16.10 the IWA negotiations happen over SSL. This means that either Enterprise CA, Public CA or IWA root certificate trust must be established for Centrify Multi-factor Authentication to be successful.

Centrify Report Services

  • New Operation Mode (zone mode):  The first release of report services works in "domain mode" this means that the "Replicating Directory Changes" delegation was required.  Now in this mode, only delegations at the zones container is needed, keeping the scope of the information sent to report services only to Centrify data.
    reports - modes.png
  • Report options:  include the ability not to generate charts as well as reports for local users.

Centrify-enhanced OpenSSH

  • SSHv1 is no longer supported.
  • AIX:  The LAM version of Centrify-enhanced OpenSSH is no longer shipped.  This is because supported versions of AIX ship with PAM enabled.

Introducing Centrify Licensing Service

  • Customers are asking to provide more efficient and proactive licence capacity and usage and many are asking for elastic licensing to support public cloud workloads.
  • Centrify Licensing Service (v1) targets perpetual licensing and provides mechanisms for streamlined capacity, inventory and notification.
    cls - main.png
  • CLS requires a highly-available Windows server that runs the licensing service (this does not have to be a dedicated server)

LDAP Proxy performance enhancements

  • The LDAP Proxy now implements new caching mechanisms (at the server auth and client) that can result in performance increases.

Centrify Agent for Windows

  • MFA:  Supported at login (console, RDP, screensaver unlock) in two modes:  zone mode and zoneless mode.  Zoneless mode requires a Centrify Identity Service device license.
  • Support for both MFA at login and with privilege elevation (desktop, applications) is exclusive to zone mode (requires Standard Edition license)
    mfa -zoned.png
  • Just like UNIX/Linux MFA, requires IWA over SSL, this means that Enterprise, Public or IWA root cert trust must be planned and implemented.
  • Application Manager:  This application can be assigned to a role to allow Add/remove of Windows programs
  • Feature Manager:  This application can be assigned to a role to allow for Windows feature management

DirectAudit Enhancements

  • Compiled with libaudit support (system call monitoring at the Kernel level) on RHEL and derivatives (more platforms coming in the next releases)
  • DirectAudit is now able to monitor file changes on /etc/, /var/centrifydc and /var/centrifyda
  • DirectAudit is now able to audit commands run inside scripts
  • DirectAudit is now able to monitor for specific command executions.


Platform Support

Platforms Added

  • Amazon Linux AMI
  • CentOS 6.8 (x86, x86_64)
  • CentOS 7.3 (x86_64)
  • Debian Linux 7.1, 8.5-8.7 (x86, x86_64)
  • Fedora 24, 25 (x86, x86_64)
  • Mac 10.12 (x86_64)
  • Oracle Linux 6.8 (x86, x86_64)
  • Oracle Linux 7.3 (x86_64)
  • Red Hat Enterprise Linux 6.8 (x86, x86_64)
  • Red Hat Enterprise Linux 7.1, 7.2, 7.3 (ppc64le)
  • Red Hat Enterprise Linux 7.2 (zLinux) on Standard Edition
  • Red Hat Enterprise Linux 7.3 (x86_64)
  • Red Hat Enterprise Linux 7.3 (ppc64)
  • SUSE 12 (ppc64le)
  • Ubuntu 16.10 (x86, x86_64)

 Platforms Removed

  • Fedora 21
  • Mac 10.9
  • OpenSUSE 13.1
  • SUSE Linux Enterprise 10.x
  • Ubuntu 15.04, 15.10

Component Version Upgrades

  • Centrify-enhanced OpenSSH is now based on OpenSSH 7.3p1
  • Centrify-enhanced sudo (dzdo) is now based on sudo 1.8.17p1
  • Centrify-curl is based on libcurl version  7.51.0
  • Centrify-openssl is upgraded to version  1.0.2j
  • Centrify PuTTY is upgraded to version  0.67


Planning tips for Server Suite 2017

  1. As recommended, read the release notes and upgrade guide.
  2. Even if you don't plan to update your clients right away, you can upgrade your consoles and group policy templates. 
  3. This is a major release and all components must be upgraded: DirectControl, DirectAudit (agents/collectors/database), this is because:
    • Kerberos upgrade
    • New LRPC2 transaction protocol
    • New Open-source packaging
    • OpenSSL upgrade
  4. Plan for Centrify Licensing Service - have the service installed on one or two highly-available windows servers.  Have your technical and procurement leads in the notification lists and designate a thresold to get proactively sent deployment reports.
  5. Due to the new DirectControl packaging, plan to update your DevOps recipes/cookbooks (Chef, Puppet, Ansible, etc)
    Tip:  adjoin has a new option “-F/--forceDeleteObj” to clean up the existing computer object and extension object in Active Directory before performing the adjoin operation.
  6. If you're using Centrify-enhanced OpenSSH on AIX platforms, plan phase out unsupported versions or to migrate and test existing PAM support; this is because we no longer ship a LAM version.
  7. SmartCard: RC4 and DES are no longer supported;  this means you have to plan to upgrade to AES-128 or AES-256 to ensure compatibility.
  8. Leverage the Centrify Repo for quick updates on RPM, APT or Zypper-compatible distributions.
  9. The new capabilities of DirectAudit (config file monitoring, monitored execution, etc) are not turned on by default.  You have to turn on the event.execution.monitor and event.monitor.commands parameters in the /etc/centrifyda/centrifyda.conf file.  Make sure you do a baseline analysis first.
  10. Hybrid-cloud support:  remember that you can use Server Suite in your AWS, Azure or GCP deployments and that Centrify provides unique support for complex AD scenarior like one-way trusts, RODC and now Kerberos Armoring.


Conclusion - It's all about value

  • With each release of Server Suite, Centrify adds more new capabilities that ensure alighment with security practices and regulations and operational efficiency.
  • You have to learn to spot issues with your current deployment like:
    • Challenging management due to a large number of zones:   this may mean that your implementation is following outdated practices.  Back in 2010 Centrify introduced Hierarchical zones, this allows for better administration, privilege management and a reduced number of zones.
    • Not leveraging privilege management:  Authentication was the problem 10 years ago. Now you're faced with multi-platform attestation, conformance with MFA requirements, etc.  These are all parts of the product that you own.
    • Not getting the proper "insight":  Centrify Report Services and the integrations with Splunk, ARCSight and QRadar are the best ways to understand what's happenning in your Centrify deployment today.
      Check out this article series to see the insights you should be getting:
    • Cognitive gaps:  If you or your team feel that have inherited a Centrify deployment and don't have the proper training, let your reps know and they'll take care of that.
  • For an article discussing what do if you inherited a Centrify infrastructure, go here:

Expect some in-depth articles on some of the newest features of this release.



For customers that already use Symantec VIP for MFA and want to layer on the Symantec VIP MFA solution to the features that Centrify Server Suite provides, you can use this guide to add Symantec VIP MFA through PAM chaining. This allows you to leverage your existing investment in Symantec VIP until a time when you are ready to explore Centrify's fully integrated MFA Everywhere capability. 


Security Kaizen - Part III: Web Apps, Mobile/Mac and MFA

Part I | Part II | Part III | Part IV

In the first two articles of this series we have discussed some metrics that can help security analysts in the evaluation of their access and privilege management models in a Centrify deployment using Server Suite.


The whole premise is to treat the process of limiting access/privileges as a subject of a continuous improvement cycle where we apply root-cause analysis and implement improvements to the security posture of the organization. 


In this third iterationid-service.PNG we're going to shift gears to other areas of the Centrify world and we'll focus on web applications.  In this entry we'll focus on Centrify Identity Service.  CIS  is a best-of-breed Identity as a Service solution that provides simple federated SSO, self-service, mobile device/application/container management and much more. What you'll see below is included with the product in the form of reports and dashboards;  in addition to these capabilities, we have released an analytics engine that is a companion to CIS.  Read all about it here.


With CIS, we're going to discuss these dimensions:  Apps, Users (including admin users), Roles, MFA and Mobile.


Application Dimension

When dealing with Applications, one of the most common goals in the context of access management is to consolidate application authentication patterns.  The principle is to move away from local user/password repositories because this is one less point of risk and compliance enforcement.  For each user/password app, security analysts must worry about alignment with policy, roles/rights, mitigation for advanced threats, attestation, etc.  

If an application is using a modern approach (like federation) is easier to provide the assurance of compliance and this also makes the application much more portable.


Total Deployed Apps

The first place to start is to identify your application real-estate.  Understanding how many applications are deployed in your environment is the first place.

select count (*) from application; 

Apps not in use

Another great piece of information is to find out what applications are not in use.  If an app is published and has no audience, perhaps this needs to be reconsidered.  This can be found under Reports > Applications > Unused Web Apps

usused apps.png 

% of Apps using Federation

As stated above, the goal is to eliminate user/password applications.  You can create a ratio of total apps that support federation / total apps; this will give you a good target percentage; since some apps are kept due to legacy and political reasons, each app move to modern patters may be a project or a program in itself.

As an example, you can modify one of the built-in reports to obtain the SAML-capable apps from the existing installation:

select ID AS _ID, DisplayName, WebAppType, Category, Description 
from Application
where WebAppType='Saml'
order by AppTypeDisplayName, Category, DisplayName


Unique application launches and App launch events


Although these are operational metrics, they are correlated with user activity and roles (see below);  For example in the pics above I've drilled on App launches related to the Amazon root account and the IAM federated app.  This is because those apps are use by very high-privileged users.


Most Commonly Used Apps

This can be generated as a report;  commonly used apps may indicate heavy line-of-business apps and is an indicator of potentially-sensitive information.

Look at the Top apps in this example:  Salesforce (sales/customer data); Office 365 (all kinds of data), Workday (employee data).


There are multiple areas to focus on apps (including mobile) but let's focus on the CIS user view.


User Dimension

Users in Identity Service can have assigned applications, provisioned applications and roles.  Roles may be used for application access (RBAC) and for privileges in the platform.   


Assigned Apps (user)


The goal continues to be the least access principle and we want to make sure that users only have access to the apps that they need. 


Provisioned Apps (user)


Provisioned apps allow for just-in-time provisioning (or de-provisioning) of users and if supported, role assignments.

Notice how you can also identify anomalies.


Roles Assigned (and Entitlements)


Note how a role also provides the user with privileges in the platform.


User Logins vs. User Failed Logins



It's always important to review this type of activity, however Identity Service provides an additional dimension - geo-location;  this provides better intelligence for security operation decision.


Any failure attempts in geographies that the enterprise does not have a presence should be flagged or subject to additional scrutiny.


Administrative User


Application Changes

Administrative users may change apps, roles and settings in the overall platform.  Typically, when apps are being deployed, there are many changes being logged, but once an application is stable, it should be "locked"  and the changes should only be under approval by change control committee unless there's emergency changes needed.


app changes.png


Role Changes

Activities in this area depend on the RBAC model implemented.  If administrators make membership changes directly on the Identity Service roles, then activity will reflect natural business operations;however, if using the target groups (e.g. AD security groups), then the changes to roles should be minimal.



Challenges and  Multi-factor Authentication


MFA is a key part of Identity service and the metrics around this capability can be very useful to understand user behavior and potential threats.  Identity Service supports different types of authentication profiles that may include Smart Card/YubiKey/OATH as MFA methods and SMS, phone factor, and e-mail as step-up methods; it can also support RADIUS challenges to accommodate for legacy tokens like RSA SecurID, Vasco or Symantec.


Successful and Failed Challenges


A challenge happens when MfA is invoked, therefore a failed challenge is a causal factor behind failed logins.


Challenges and Authentication Events


Pay special attention to failed challenges;  these are instances in which an MFA  (or step-up) mechanism has been invoked but it hasn't been satisfied.  Repeated attempts are subject to security alarms.


Authentication Events - Pattern


Authentication patterns are relatively predictable in some organizations (this depends on their timezone footprint), this means that you should understand a normal ratio (e.g. failed challenges/total challenges) over certain periods of time (after all, users miss challenges), but any spike, especially outside normal hours should be a subject of additional investigation.  Notice the change on the wave pattern once we hit Saturday (18).




Stats around mobile could be geared towards maintaining device conformance to a standard (e.g. minimum version for iOS shall be v10), understanding the make-up of the devices and making sure that capabilities that are compensating controls for data protection or leakage are deployed.


Enrolled Device Compliance


In this metric it's important to understand what are the key components of device alignment with policy.   As new mobile devices and OSs are deployed, capabilities may evolve or can be superseded for better ones.  User intervention is also a challenge when it comes to mobile devices, however, organizations can have stronger policy in corporate-owned devices vs. devices brought by the end-user (BYOD).


Device Status



A large percentage of unreachable devices may mean that if you're using self-service enrollment, you may be allowing too many of them.   For example, a limit of 2 devices is preferable than 5 (default).


Device Real Estate


This pie chart provides the answer to a key question - how many devices are out there and what's the make-up. 


Identity service provides a set of policies that provide the assurance that users can't enroll older devices that may not be subject to manufacturer updates that are vulnerable to risks. 



Security Kaizen - Part II:  System, Roles and Groups + Anomalies

Part I | Part II | Part III | Part IV

In the previous article of this series, we discussed the application of continuous improvement process (CIP) to security practices in the context of access control and privilege management.


We defined that the  goal is to implement the least access and least privilege principles across the board and that we start by collecting metrics like the number of users with system access, privileges, etc.  The idea is to Identity-Plan-Implement and Review.  For example:  If after reviewing the roles assigned to a user, we realize that this was a one-time request that was implemented permanently, we can eliminate the role assignment and have a process to review (perhaps every 30 days);  an improvement over this could be an automatic email sent to the user to extend the access instead of removing it.


We also introduced the concept of dimensions.  In the past article we focused on the user view,  in this article we discuss other dimensions.


System View

Total Centrify-managed systems vs Domain-joined systems

To identify Centrify-managed systems, first you need to identify the existing zones in your environment.

Get-CdmZone | Select Name, Domain, DistinguishedName, Schema 

Once you have identified the zones, you can enumerate the number of systems under all active zones.  An improvement point is to ask: "Why are these zones in existence if no systems are currently being managed?"

Another point of concern is if a large number of classic zones are encountered.  Centrify best practices since 2010 favor hierarchical zones over classic zones. 


The goal in this measurement is to understand which systems are under Centrify management and aren't.  For example, you can use these commandlets:

Get-CdmManagedComputer -Zone (Get-CdmZone -Name Global) | Measure
Get-ADComputer -Filter *  | Measure

to count the Centrified systems and all AD-joined systems.  This will give you a ratio of the % of systems that are managed by Centrify.  For example, in my test system I have 12 total systems with 5 managed by Centrify.


This is important because you need an alternative strategy for assessing who has access and privileges on those systems OR you can ask "Why haven't these systems been set up under Centrify management?"


Computers that grant more access and computers subject to more assignments


These metrics allow you to identify the systems that have the less stringent access controls; in addition, you can identify the systems that are subject to more role assignments.   Reviewing the data classification of the apps on these systems is advisable since the more access exists, the more possibilities of users saving privileged data.


Logins by System

This system view complements the "logins by user" metric discussed in the previous article.  This one has an interesting twist.  Note that I said I have 5 Centrified systems, however, I seem to be only getting data for 2 systems.  This is an indication that perhaps there is a misconfiguration; in my case I only have the Splunk forwarder installed in two of my demo VMs.  Note that in the case of hybrid cloud, because systems are treated as cattle, you may not notice users logging in at all.




Computers subject to more privileges


This is the privilege view of systems.  Notice that my Ubuntu system grants more privileges than the rest; if this was a PCI or SOx system, you want to dig deeper to find out why.


Privileged Access with most computers in scope


This metric allows you to identify what rights are more prevalent in the computer population.  The more common the right is, the more prevalent it will be; expect login rights (e.g. ssh, sshd or login-all) to be more prevalent.  If you see something like "run as root"  or  "Administrative Desktop" as a prevalent command, this may be part of a sysadmin role.


Privilege Activities by Type

Often you may need to look at a system and find out exactly what the privileges activities are most common.  This complements the user view (e.g. most used privileged commands)



Group and Role views

Before moving into groups and roles, let's add some context.  In Centrify DirectAuthorize, the best practice is to assign roles to AD security groups;  however AD security groups constitute what are called "Computer Roles" - these are nothing more than "Teams of Servers";  these constructs allow a system to belong to different types (e.g. a web server and a database server) which may be subject to roles assigned to different populations (e.g. web admins and DBAs respectively).


Roles with Most Access

These are the roles that have the broadest scope in a Centrify deployment.  Note that design principles suggest that Zone-level and computer-level role assignments should be used sparingly.



AD Groups with Most Members

Depending on the deployment mode of Report Services (domain or zone) you can get information about all or only the zone-relevant groups.  In this case, this graph indicates the membership numbers of groups that grant privileges in a Centrify deployment.


AD Group Attestation - Access


The picture above provides information about an AD group that is used in a Centrify deployment.  Note that it also highlights if the group has any nested groups and includes a detail of the systems it grants access to.


AD Groups with Most Privileged Access

 The common practice is to provide both access and privileges within the same group; therefore this report should be very familiar to the access report;  however there are exceptions, especially when using selective auditing.



AD Group/Role Attestation

This report shows the relationship between the AD group, the systems in scope and the rights defined in the system.


This is a great report to generate if you need to answer these questions:

  • What privileges does the "Apache Web Admin" group provides?
  • What role(s) are associated with it?
  • What is the scope of the role assignment?
  • What is the definition of the role (commands) that it provides?



Ideally anomalies are subject to security operation actions, however, as part of your overview of the access model, it's not uncommon to collect metrics of the kinds below, some of them are self-explanatory;  the others we'll provide some color.


Failed Logins by reason


Users with Multiple Login Failures


Failed Logins over Time


Any spike on failed logins could indicate attemps at lateral movement, or a service account with an outdated password.


 Denied Privileged Activities over Time


A spike on these could indicate a compromised account with attempts to perform privilege elevation.  MFA can help mitigate this risk.


Centrify Software Operations

Because a system that is not under management is easier to compromise, there are several operational activities that we should track:

Leave Activities


When a system is not in AD, you lose access control and the Centrify audit trail log.


DirectAudit Agent Service Stoppages


Privileged users can stop the session-capture client (DirectAudit), not without audit trail recording it.  Since most systems subject to this capability most likely are highly-sensitive, all anomalies should be investigated to make sure there's no collusion.



Security Kaizen - Part I:  Privileged User

Part I | Part II | Part III | Part IV

To be an effective security analyst, one must employ techniques like the continuous (or constant) improvement process (CIP);  this concept is commonly applied in manufacturing, but it has been extended to many disciplines.  The idea is to optimize the elements (people-process-technology) of a product, process or service to make it better.


In the security discipline, this requires partnership with stakeholders (infrastructure, application and business leads) to makes sure the process is not about "pointing out what's wrong" but about minimizing risk and working together to constantly align with the best security practices.  This means that your stakeholders need to be part of the optimization process.  This is not a top/down or policy-based approach;  the idea is that everyone understands the risk factors around databreaches and can volunteer information to optimize the current security posture of the organization.


In this article I discuss the metrics provided by Centrify and integrations with third parties to aid in this constant improvement process. 


We'll start with the information produced by our Centrify Server Suite (CSS).  For those who don't know, CSS provides:

  • Centralized administration for UNIX, Linux and OS X leveraging Active Directory
  • Streamlined authentication leveraging Microsoft Kerberos
  • Strong Authentication (smart card) and MFA for UNIX, Linux, OS X and Windows systems.
  • Privilege Management leveraging RBAC for UNIX, LInux, and Windows systems.
  • Session capture + replay and access/privilege tracking for UNIX, LInux, and Windows systems.


Centrify Zones - A powerful ally

Centrify Server Suite has been successful due to the introduction of Centrify Zones.  This exclusive capability is implemented as a set of AD objects that allow the following capabilities:

  • Cross-platform groupings of systems based on a governance model (zones, child-zones, computer roles)
  • Access Control enforcement (least access) - only users that are UNIX identified or authorized can access a system
  • UNIX identity management - consolidated AD and Local account (user/group) management
  • Role-based access control - enforcement of how (what protocol or method) and what (commands, apps, desktops) can be run with privilege: without exposing a password.

This means that we have in Active Directory the definitions for access and privileges, plus the corresponding clients always send the information to the correct place (event log, syslog); making CSS a rich source of information for any security professional.


The Goal:  Least Access & Least Privilege Management

Before you can embark in the journey to operational efficiency, you must understand what are the goals and establish baselines; each goal can be an independent program or project; after all, "you can't manage what you can't measure."

The universal goal of privilege identity management (PIM) is to implement least access and least privilege principles.  This means that users only can access the systems they require to perform their functions and their privileges don't exceed what's required for them to do their assigned duties.  Shared accounts or powerful roles must have limited use, only with approval in a temporary basis.

With that established we can look at access and privileges using 4 dimensions:  Users, Groups, Roles and Systems.  The reasoning behind this model is simple: in mature environments, access and privileges are not assigned to the individual, but to groups (e.g. AD security groups) and these may be applied in the context of a system. Let's review some user-based metrics that can be gathered using Centrify Report Services (a tool included with CSS Standard Edition) and our integration with Splunk.



User View Metrics


Who are the users with most access on systems?
This is a basic metric because it defines your universe.  It allows you to start a conversation about attestation and use the challenge "do you really need access to all these systems?"; another conversation starter is identifying non-IT or business users that have access to systems and why;  if the answer is "It takes too long for me to get access"  then the optimization is at the process-granting level.


Users with more access roles
This metric allows you to identify users with aggregated roles that grant access.  In organizations that have not embraced temporary access control, the reports associated with this metric allows us to identify instances of granting too many access rights.  This is also a great opportunity to identify redundancies and problems with the role/privilege design.
Example:  note the report above.  Diana is already a powerful user, but she has a role-assignment override in the Ubuntu system named engubu14.  This is unnecessary because she's already a zone-level cross-platform sysadmin.


Local UNIX Accounts Managed by Centrify


If you are leveraging Centrify Zones to manage local user accounts in your UNIX-like systems, understanding how these fit in the access model is important.  The question to be asked is how are the passwords for these local accounts being managed.  You can leverage Centrify Privilege Service or your existing SAPM solution.


Who are the users with most privileges?  Do they require those privileges?


This is another baseline metric.  Now the focus is on privileges and understanding the population of users that have privileges and its context is important.  If temporary access control is not being used, then attestation exercises should focus on why the privileges are needed.  If the answer is that "app X breaks all the time and I need to reboot from home" then target the root of the problem (the App).


Privileged vs. Access Users


Now we're using the information in Centrify Zones about access and privileges to understand the landscape and profiles of users.


Who are the most active privileged users?

This metric can be used to find out who are really using their privileges.  Watch out for users that haven't been active in a 30-day period.


How frequently are the privileged users changing their passwords?


This is a classic identity management metric.  Not only this allows to identify poor practices (like account without expiration) but also compliance to policy.   Frequent password changes (e.g. within a 2-3 minute threshold) if group policy allows, should also be subject to a security operations alarm.

The report above can be generated with this PowerShell one-liner:

Get-ADUser -Filter * -Properties passwordlastset, passwordneverexpires 
| sort-object name | select-object Name, passwordlastset,
passwordneverexpires | Export-csv -Path c:\reports\passwd.csv


User Overview - Attestation Report

Obtaining consolidated attestation reports is a challenge for all organzations.  With Server Suite report services, you can get reports that show the user's access across platforms like Windows and UNIX systems;  what granted access (role assignment) and the rights contained within those roles.


Logins by User - Organization View


Identifying our most active users (leveraging access rights) will allow us to correlate activity vs. our universe.  Make a habit of running this with a 30-day threshold to find out what users fall out of the access report - those are great candidates for temporary access.


User Overview - Most Privileged User Commands (cross-platform)



These types of reports can be generated using different criteria (time period, user, system, etc);  These could allow us to identify what are the user's biases and preferences. For example, looks like my sysadmin performs edits of files most of the time.


Making the most of your Centrify Investment

Most organizations have a journey that may or may not have been completed, perhaps it was all about authentication at one time, however Centrify has invested heavily to shift to the needs to control privileges the right way, by promoting  the least access and least privilege principles across client/server platforms.  Today we continue to innovate by providing multi-factor authentication;  as we go to hybrid clouds, you can rest assured that we'll continue to innovate and provide the valuable insight needed to make the right decisions.  In the next entry, we'll discuss the other dimensions.




ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more.  This is the fourth article in the series.  We have covered  ServiceNow federation using Multi-provider SSO, setting-up automatic provisioning with the Centrify Identity Service App and setting-up and configuring Centrify App Request;  in this post we'll discuss the steps to set up Centrify Privilege Access Request to leverage the Service Catalog to request login or password checkout of resource accounts in Centrify Privilege Service.


About Centrify Privilege Service (CPS)

CPS is a privileged identity management solution that focuses on shared secrets on UNIX, Linux, Windows, Network devices, AD domains, Oracle or SQL databases and more.  The approach is different than Server Suite that is focused on the principle of least privilege.  Privilege Service provides a built-in access request system with single and multi-level approvals.



Privilege Service's Workflow  vs.  ServiceNow Self-Service

We often get questions about what solution to use for self-service and approvals for application or privilege requests.  The answer is quite simple:  if you already have all your requests in ServiceNow, you should continue to do so, this helps standardization and a unified user experience.  The Centrify workflow engine is designed to meet the basic needs for Centrify products and ServiceNow is a full-fledged Service Management solution.


We'll continue to use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology and assumes you have working knowledge of Identity Service and ServiceNow.


What you'll need

  • A SaaS instance of Centrify Privilege Service with UNIX, Linux, Windows or Network Devices configured.
    Note:  You can use an on-premises instance as well, provided that the network (e.g. publicly-facing) and name resolution (publicly-resolvable) aspects of the design are taken care of.
  • A ServiceNow Instance that allows you to install apps  (non-developer) with federated access to your Privilege Service instance.  For details on how to set up SAML federation with the Multi-provider SSO, click here or review the links below.
  • Administrative accounts on both systems



During planning, discuss with your infrastructure, operations and security teams about these topics:

  • Will you have a single approval or multiple approval groups per resource?
    Depending on the resource(s) in question you may have a single group or multiple groups approve.  You may also use a default approval group. 
  • How will the workflow be designed?
    This topic is very organization-dependent.  Some organizations may chose to have automatic approvals for certain systems and human approvals when the systems host sensitive data or are subject to strong security policy or regulations like SOx, PCI, HIPAA and others.
  • Have you identified a Default Approval Group in ServiceNow?
    If you chose to have a single group approve all privileged requests.
  • Have you created a CIS role and policy set for the servicenow service account?
    The servicenow account in Identity Service requires at a minimum the "Privilege Management" right, in addition, a policy that allows for username/password is required since the REST calls used by the app can't answer multi-factor authentication requests.
  • Will you have SLAs tied to your application requests?
    Although not in the scope of this post, SN offers a lot of flexibility when designing workflows including expiring worfkow requests when they are not approved within a defined duration.




  • Create an Identity Service user (the service account that SN will use to authenticate and perform actions)
  • Create an Identity Service role with the minimum rights (the role that will be assigned to the service account)
  • Create an Identity Service Policy to allow user/password login
  • Download and Install Centrify Privilege Access Request app from the ServiceNow App Store
  • Configure the Centrify Privilege Access Request app

Create a Service Account

For this integration, you'll need a service account (you should know how to create users to follow this article).  To practice least privilege, this account needs to belong to a role with the Privilege Management right.   This is to be able grant login or password checkout rights on the accounts on each system.  Centrify Directory users are created under Admin Portal > Users


When creating the user, be mindful of options that can cause an outage (like password expiration), and practice proper rotation and complexity based on your internal policy.


Create a Role with the minimum rights

To create a role, you have to go to the Admin Portal > Roles and Press Add role.  In the  members tab, add the newly-created account and in the Administrative rights tab, select the privilege management right.



Once completed, press the save button.


Create Policy to allow user/password login

This step may require you to create an Authentication profile that only asks for password (Admin Portal > Settings > Authentication > Authentication profiles).   The reason being is that Identity Service will (by default) ask for a step-up method for any unknown connections. 


  1. Log on to the Admin Portal with an administrative account
  2. Go to Policies > New Policy
  3. In Policy Settings, scroll down and select the "Specified roles" radio button
  4. Press Add and browse for the role created in the previous step.
  5. On the left pane expand User Security Policies > Login Authentication and select Yes to enable.
  6. Under default profile (used if no conditions matched) select your Auth profile that only challenges for password.
  7. Press Save
  8. In an incognito window for your browser, try to log in to the service with the newly-created account.  You should only be prompted for username and then password.


Important:  Make sure that the policy only applies to the members of the role created for this integration.


Download and Install the Privilege Access Request App from the ServiceNow Store

  1. Go to the ServiceNow app store and search for Centrify.
  2. Click on the Centrify Privileged Request App
  3. Click "Get" to make the Centrify Privileged Request app available for your ServiceNow instances.
  4. Go to the ServiceNow instance, select System Applications > Applications > Downloads to locate the app then click Install to install it.

Configure the Centrify Privileged Access Request app

There are three configuration tasks required.  Properties, API Sync and Accounts.  The third category is only needed if you are using individual groups as approvers for each resource's account.
  1. In the application pane (left) navigate to Centrify Privilege Request > Properties.  Populate these three fields
    Centrify Cloud Tenant URL:  the URL for your identity service tenant.  (e.g.
    Centrify Cloud Service Account: the account you created in previous steps
    Centrify Cloud Service Account Password:  the strong password you created for the user
  2. Default Approval Group (Optional):  now you have a decision to make based on the planning above.  Populate the "Default Approval Group" if you decided to use a single ServiceNow group to approve all privilege requests.  You have to find the group in ServiceNow (System Security > Groups; find the group, right-click it and "Copy sys_id" and paste it on the Default Approval Group.  If you are planning to have approval groups per App, then you leave the field empty and press Save.

API Sync

  1. Go to Centrify Privilege Request > Customize API Sync
  2. Set the Active checkbox
  3. Select an appropriate interval based on your SLAs (e.g. 1 hour)
  4. Press Save and then Execute Now.
    This process will synchronize the Resources (systems) and accounts available in Privilege Service

If you set up a "Default Approval Group" you can skip this part.  At this point you have to have a list of all the apps and the corresponding approval groups.  For example, the root account in the CentOS system called engcen7 will be approved by the Team Development Code Reviewers group included with the sample data of the ServiceNow instance and the canned workflow for software.



To verify the functionality of the app, you'll have to run through the workflow of the apps (or independent apps) based on the approval group defined.  For example, in my scenario I chose to have independent approval groups.  My requester wants to checkout the "api-key" resource under the azure-rh1 resource and the self-service request is automatically approved based on existing ServiceNow rules.



Once the request is approved the app will provide the requester access to the type of request (login for SSH or RDP access) or checkout (for password reveal or clipboard copy).  In order to get access to the system or retrieve the password, the requester must switch over to privilege manager and find the system in the resources list or in their favorites.  For login they can use the PuTTY or web client and to check-out the password, they can use the system resource on privilege manager or the mobile app.


Documented Approvals

Security analysts and auditors may require reports of who has been requesting and approving apps, this is easily accessible using the service catalog requests or under the Centrify Privilege Request Access approvals or the Dashboard section.




Since this app focuses on ServiceNow approvals, the enhancements are around workflow design.  For example, you can have multi-approval groups, you can set timers for SLAs, etc.   However, there are other things that you can customize including the Dashboards and the appearance and location of the Centrify items in the Service Catalog.


Centrify & ServiceNow Resources

There are multiple resources available in the documentation and tech blogs:


We've had requests from many customers to document how Centrify can protect RDWeb access with MFA or two-factor authentication. It turns out it's a simple WS-Federation with Centirfy Identity Service, where you enable MFA for your users.


Please continue reading for instructions on how to set it up.


This article will show you how to deny or allow access to a web application, when certain conditions are met. The conditions include:

1. Log into the Centrify Admin Portal.

2. Edit your web application and select Policy from the left column.


Policy left.png 


3. In the right pane, click on the Add Rule button. A new window will appear.


add rule button.png


   a) Click on the Add Rule button.


add rule too.png


   b) Select the desired filter and condition


condition list.png 


   c) Click on the Add button.


selected condition.png


   d) Choose an Authentication Profile to allow, deny or require multi-factor authentication. Click OK.


selected condition action.png


4. Select a Default Profile to allow, deny or require multi-factor authentication. Click Save.

 default condition profile.png


If you want to restrict web application access to only devices that has been enrolled into Centrify's MDM:

See instructions.




Showing results for 
Search instead for 
Do you mean 

Community Control Panel