As more and more organizations run infrastructure in IaaS platforms like Amazon AWS, there's an increased need to enhance security operations and prove effective implementation of security controls.  AWS provides a solution set that includes CloudWatch.  


About CloudWatch

As defined by Amazon "CloudWatch monitors your Amazon Web Services (AWS) resources and the applications you run on AWS in real time. You can use CloudWatch to collect and track metrics, which are variables you can measure for your resources and applications." 

For more information, check out the Getting Started guide for CloudWatch:


The goal of this article, is to provide some initial guidance to leverage AWS CloudWatch to collect, track and measure Centrify Audit Trail events in UNIX, Linux systems running in AWS.

For a companion article that describes the process for Windows instances, go here:


About Centrify Audit Events

Centrify Audit Events (CentrifyAuditTrail) is the cross-platform framework used by Centrify Server Suite to document and provide access, privilege and audit trail event data. When a Centrify-enabled service is invoked, an audit trail event is written to UNIX syslog or Windows event log.  These events are documented in the  Audit Events Administrator's Guide for the current version of Server Suite.  The types or content of the events vary depending on the edition (Standard or Enterprise).


For more information, check out the current guide for Server Suite 2017:



For this lab, you'll need:

  • An AWS Account with the proper VPC setup, privileges in CloudWatch and IAM
  • Active Directory (run by you or managed by Amazon) and the proper VPC name resolution and communications
  • A Centrify zone, sample users and access/privilege setup
  • At least one Linux system joined to Active Directory and the Centrify zone
  • The Linux system should have some Centrify data (e.g. logins, privilege elevations) present in syslog.

Centrify AWS Lab:  You'll need to be at Standard Edition level to follow this lab, more info here:


Implementation Overview

  1. Set-up your AWS Linux Instances for CloudWatch Logs (use AWS's docs)
  2. Verify Centrify Audit Trail events in the CloudWatch log group
  3. Identify Access and Privilege-related Metrics provided by Centrify
  4. Create the Filters and Assign a Metric
  5. Create a Dashboard
  6. Create an Alarm.


Set-up your AWS Linux Instances for CloudWatch Logs

For information on this topic, please review AWS's documentation:

Once you have the /var/log/messages logs for your instances, please proceed to the next section.


Verify Centrify Audit Trail events in the CloudWatch log group

  1. Go to your CloudWatch console:
  2. Click on Logs > Click on the log group for your Linux instances (e.g. "/var/log/messages"  or the group you are using for your Linux syslog)
  3. Click on Search log group and in filter events, type "AUDIT_TRAIL"
  4. Verify the results
    If you have a system that was joined to the domain via Centrify, there will be event data about access, privileges and other activities.

Now you have verified that your systems are streaming syslog data with Centrify Audit Trail information.


Identify Access and Privilege-related Metrics provided by Centrify

Centrify DirectControl provides access control and role-based privileged elevation; this component is called DirectAuthorize.  DirectAuthorize controls how users access the system and what commands they can run. The implementation of privilege elevation leverages Centrify-enhanced sudo.



The metrics that you'll track will depend in your objectives and in your maturity level.  For illustration purposes, let's track successful and unsuccessful access and privilege elevation in my Linux EC2 instances. After reviewing the Centrify Audit events guide, I identify the following events:


Access Control

PAM Authentication Granted:  These events are related to the UNIX framework;  the PAM Auth module is used by any PAM-enabled application.  This can be a catch-all for any app using it (e.g. OpenSSH server, Switch User (su), etc);  the Centrify Event Id is 24100.


Centrify SSHD Denied:  My EC2 instances are running Centrify-enhanced OpenSSH.  I'm interested in looking at this metric, especially on instances with public IPs because it may denote attempts to break-in or move laterally. The Event Id is 27101.


Privilege Elevation

Centrify dzdo Granted:  Indicates successful privilege elevation using Centrify-enhanced sudo.  Event id: 30000.

Centrify dzdo Denied :  Indicates denied privilege elevation using Centrify-enhanced sudo.  It may allow to identiy attempts for privilege abuse.  Event id: 30001.


Create the Filters and Assign a Metric

  1. Go to your CloudWatch console:
  2. Click on Logs and select the radio buttion next to your log group (e.g. /var/log/messages)
  3. Click Create Metric Filter
    • In filter pattern, type: centrifyEventID=24100
    • Press "Assign Metric" 
  4. In Filter Name, type a unique name for the filter
  5. In Metric details, create a new namespace (e.g. CentrifyAuditTrail) or browse for it if you already have it.
  6. In Metric name, give it a descriptive metric.
  7. Press Assign Metric.
  8. Repeat the process for all the metrics you've identified.

Create a Dashboard

Before creating a dashboard, you may want to plan how to visualize the data.  In some instances it's useful to see the aggregate data (# of events), in others it's useful to see a trend (graphs overlapped with time).

Once you have thought of how to visualize the data, it's time to get started with your dashboard. 


  1. Go to your CloudWatch console:
  2. Click on Dashboards > Create Dashboard and give it a name, then press Create Dashboard
  3. To add aggregated information, select the Number widget
  4. Select your Namespace, Dimension and check the metric(s) to be measured
  5. Go to the graphed metrics tab, and select the proper statistic and period  (e.g. sum and 1 day) and press Update Widget.
  6. Once you have the Widget in the dashboard, adjust the size and label.

Repeat the process with the trend using with a line or stacked area.


Below is a simple dashboard that includes the metrics above.



Create an Alarm

A meaningful alarm could be based on a pattern outside expected behavior, an availability issue or another event (or aggregation of events) based on the risk that wants to be corrected.  This example is for illustration purposes only.

Example:  The threshold for attempted abuse of Centrify-enhanced sudo is 3 or more attempts within a 5 minute period, when this happens, an email should be triggered to the members of the secops distribution list.

  1. Go to your CloudWatch console:
  2. Click Browse Metrics and next to Centrify-dzdo-Denied, click the alarm icon.
  3. In create alarm:
    Name:  Alarm-Abuse-dzdo
    Whenever: is equal or greater than 3 for 1 consecutive period
    Period: 5 minutes
    Statistic: Sum
  4. Actions
    Whenever this alarm state is Alarm
    Create a new list (

Trigger the alarm

  1. Sign-in to your Linux instance with homer
  2. Type 'dzdo su - root' and press enter
  3. You should get this message:
    [homer@cdctest2 ~]$ dzdo su -
    Sorry, user homer is not allowed to execute '/bin/su -' as root on cdctest2.\
  4. Repeat 3 more times.  This should trigger the alarm.
  5. Review the Dashboard.  After a few minutes, the alarm will return to normal and you'll be notified


We have only scratched the surface of the capabilities provided by AWS CloudWatch, however in the context of Identity and Access Management, the enrichment of security operations via logs, alerts and dashboards should be done via standard tools; otherwise if each tool duplicates these capabilties, then security operations won't know where to go first.  Centrify provides native plugins for Splunk, IBM QRadar and HP ArcSight.  These tools provide both operational data as well as like the following privilege command pie chart.


Related Articles

[Labs] Using Centrify Audit Trail for Windows with AWS CloudWatch:

[Security Corner] Reviewing your Access and Privilege Management Model with Centrify tools:  

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

Centrify Audit Trail Administrator's guide (2017): 


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:

Announcing a new series!!!


I recently got some YubiKeys from HQ (thanks @Peter) and since they provide all-in-one smart card (PIV) and OTP (OATH) capabilities plus they work great with Centrify products. 


Here are the series links:

Part 1: Securing Windows Server Access and Privilege Escalation with Centrify, Active Directory and ...

Part 2: Securing local and remote access to UNIX/Linux with Centrify, Active Directory and YubiKey

Part 3: Using SmartCard (or YubiKey) to secure Apps, Shared Secrets an Sessions with CIS and CPS



About the Series

This new series showcases our  MFA Everywhere initiative and we'll be posting a series of HOWTO labs to cover several scenarios:


Strong Authentication (PKI) Smart Card / Yubikey

  • Leverage what you have:  Active Directory, Microsoft CA, Group Policies
  • Enforcing Smart Card access to UNIX/Linux/Mac systems  (Windows systems support this natively)
  • Use DirectAuthorize roles to limit access to strongly authenticated sessions

Strong Authentication for Windows Privilege Elevation

  • Applications
  • Desktops

We already covered Access and Privilege Elevation For UNIX/Linux using Centrify MFA here:



Strong Authentication (Smartcard/Yubikey) & OATH OTP access

  • IdP Portal Access
  • OnPrem or SaaS Application Access
  • Privilege Portal Access
  • Privilege Password Manager  (Shared Account Password Manager)
  • Privilege Session Manager (Jump Box)

 Here's a quick overview/demo


Lab - Base Setup

The base setup is the pre-requisite for all the Yubikey/SmartCard related labs.


What you'll need

  • Active Directory with Certificate Services
  • A domain joined member server with Centrify Server Suite 2016
    • .NET 3.x features enabled
    • Feature RSAT:  Active Directory, Group Policy Management and Certificate Services tools
  • One or two UNIX/Linux systems with Centrify Standard Edition 2016  (5.3+)  (if testing UNIX/Linux)
  • Access to Centrify Standard Edition installation files (evaluation or licensed)
  • Yubikey PIV Manager  (download link)
  • Yubikey 4, NANO or NEO
  • You need working knowledge of Active Directory and Centrify Zones

 Tip:  To set up a base configuration, you can build on the Microsoft Test Lab Guide.


Create Test Users and AD Group

On the member server

  1. Open Active Directory Users and Computers and navigate to your desired OU
  2. Right click and select New > User  and follow the wizard until the user is created.
  3. Right click the newly-created user and select properties.  In the general tab, update the Email to match the user principal name.
    e.g. and press OK.
  4. Right click the OU and select New > Group and make it a Global/Security group.  Call it "Smart Card Users"
  5. Right click the Group, select properties, go to the Members tab, press Add and add the user created in step 2.
  6. On the member server, grant the group or user the ability to log on remotely. 
    Computer > Properties > Remote Settings > Remote Desktop > Select Users  > Add > [select user or group] press OK twice.

Certificate Services

Modify the Smart Card User template

  1. Open the Certification Authority console  (Start > Search > Certification Authority)
    If you get an error, retarget the console to the appropriate server (e.g. DC1)
  2. On the left pane, right click "Certificate Templates" and select Manage.  This will open the Certificate Templates console.
  3. In the template list, right-click the SmartCard User template and select "Duplicate Template"
  4. In the General tab, give the template a descriptive name.  I used "Smart card User V2"  (this is the display name, the actual template name is SmartcardUserV2)
  5. Click on the Security tab, press Add, select the newly-created Smart Card Users group, check the Enroll and Autoenroll boxes, then press OK and close the Certificate Templates console.

Publish the Newly-Created Template

  1. In the Certification Authorities console, on the left pane, right click "Certificate Templates" and select New > Certificate Template to Issue
  2. Select the newly-created version of the Smart Card User template  (e.g. Smart Card User v2) and press OK.

Provision the Smart Card User Certificate into your Yubikey

  1. Log on to your member system with the test user.
  2. Open the Yubikey PIV manager tool with the Test User  (shift+right click > run as different user)
  3. If you're using a VM, connect the Yubikey to your virtual machine.
    Note:  If you're using VMWare, you need to add the parameter below for the Yubikey to be available to your VM.
    usb.generic.allowHID = "TRUE"
    This step is performed by editing the .vmx file and editing it with your current text editor while the VM is off.
  4. Initialize the Yubikey if brand new.  Do not forget the PIN.
  5. In Yubikey PIV manager, press Certificates > Generate New Key and make sure you type the Certificate Template name (not the display name) and press OK.
  6. Type the PIN when challenged, and select your existing CA.  In my case I use the non HTTP link and press OK
  7. To test the smart card authentication, either lock your screen or logoff.  If you can unlock or login successfully, you should be ready for the next steps.


Lab Verification Video


Step-up authentication can provide additional security controls to prevent unauthorized access to systems or controlled privileged elevation.  Server Suite 2016 uses the established step-up authentication methods of Centrify Identity Service (Token via Centrify Mobile Authenticator, SMS, Phone factor, E-Mail and User-defined security question); the key differentiators are the combination of Role-Based Access Control (RBAC) with step-up authentication and context awareness (time/access/privilege).


To complete this lab you need:

  • Familiarity with Centrify Server Suite consoles:  Access Manager
  • Familiarity with Centrify RBAC concepts:  hierarchical zones, role definitions, role assignments
  • Familiarity with Active Directory and tools:  AD users, security groups, Active Directory Users and Comuters
  • Familiarity with TCP/IP:  ports, protocols

You don't need to be familiar with Centrify Identity Service.  We will outline the set-up steps for this configuration.



Potential Stakeholders

  • Centrify SME:  These users are entitled to perform management of zone operations inside Active Directory.
  • Security Lead:  The security lead can answer questions like these:
    a) What servers require step-up authentication for login?
    b) What privileged actions require step-up authentication?
    c) What servers require step-up authentication based on day/time?
  • IT/AD Infrastructure lead:   This SME will help setting up a Windows Server to act as the cloud connector

Technical Requirements

Active Directory and Centrify

  • A licensed or evaluation copy of Centrify Suite 2016
  • An Active Directory test or production environment with Centrify a Centrify Hierarchical zone
  • A UNIX/Linux system with Centrify DirectControl 5.3+
  • A Centrify Identity Service tenant with at least one Cloud Connector acting as an Active Directory bridge
  • For step-up methods (user-defined security question can be used if none below are available):
    a) an iOS or Android device for token testing (optional)
    b) a mobile phone to test SMS
    c) an e-mail account
    d) a phone line for phone factor

Software as a Service (Cloud) - Quick Security/Assurance FAQ

  1. What is Centrify Identity Service (CIS)?
    CIS is an Identity as a Service (IDaaS) that provides Identity, Single Sign-On, Mobility Management, Policy and Multifactor Authentication among other capabilities. The service is "connector-based";  this means that there's a server running on premises that communicates with the service.  This is a very common architecture used by solutions like ServiceNOW or Office365.
  2. Why is a SaaS solution required to provide multi-factor authentication?
    The answer boils down to time-to-production, cost and efficiencies of a software as a service solution versus the overhead of an on-premises alternative.  Centrify is re-using their existing Identity Platform and extending it to Server Suite.
  3. What are the mechanisms that Centrify implements to provide assurance for confidentiality?
    Each tenant gets their own key and PKI Certificate Authority, this provides the assurance that:
    a) only the tenant owner can decrypt traffic that has been encrypted at rest or in transit
    b) the cloud connector will repudiate connections from any other source
    c) an additional layer of encryption is provided in addition to SSL
    The cloud service and the cloud connector must be authorized by two parties:  the tenant admin and an AD admin.
  4. What are the mechanisms that Centrify implements to provide high-availability?
    a) CIS runs on top of Microsoft Azure.  Azure provides hardware, datacenter, nearby datacenter and geographical datacenter redundancies.
    b) Centrify implements mechanisms that guarantee that upgrades don't cause downtime
    c) Cloud Connectors are constantly monitored for health and failover is automatic
    d) In the context of Server MFA, the tokens and SMS contain a code that can be used asynchronously
    e) In the context of Server MFA, roles with rescue rights are available;  this allows the bypassing of MFA in case of a disaster.
  5. Are the Cloud Connector public facing or in the DMZ?
    No.  Cloud connectors aren't required to be public facing or in your DMZ; they can be inside your private network and even can work behind a proxy server.  The cloud connectors will establish an outbound HTTPS connection.  The documentation explains target sources and destinations.
  6. Is outbound Internet access required for systems that use the MFA for servers feature?
    No.  The systems only need to talk to the on-premise cloud connector in a mutually authenticated, encrypted and configurable port, in turn the cloud connector validates if the systems are authorized for MFA and acts as a broker with our Identity Platform.
  7. What other assurance mechanisms are provided by Centrify for their Cloud Solutions?
    Certifications:  SOCII, SafeHarbor, TrustE.  Centrify is working on FedRAMP certification attainment.
  8. Where can I find more information?
    For more information:


How MFA for Servers Works


Active Directory

  • Centrify Zones contain:
    - Identity data in the form of UNIX RFC2307 fields for provisioned users and groups
    - Authorization (DirectAuthorize) information:  definitions of roles and attributes, rights (commands) and role assignments.
    - Information about the Centrify Identity Service tenant if there's a registered cloud connector in AD
  • Roles can have two MFA-relevant attributes:  "require multifactor authentication" and "rescue rights";  if the first one is checked, users will be prompted to provide step-up authentication to access the system;  if the second one is checked (just like with DirectAudit) all the additional security controls will be bypassed.
  • UNIX commands that have the "require multifactor authentication"  this will prompt the user to provide their password and a step-up authentication method on privilege elevation.
  • Test AD users:  The test AD users need to be UNIX-enabled and have populated attributes like email, telephone or mobile number if email, phone factor or SMS will be requested.

Centrify Server Suite

  • These are DirectControl agents 5.3+ joined to a hierarchical zone.  These systems don't need outbound connectivity to the internet.
  • The AD computer objects need to be authorized to talk to the cloud service (via role) and they should be allowed to communicate to the cloud connector using HTTPS in the web service port (8080 is the default). 

Centrify Identity Service

  • MFA Computers Role:  This role contains the systems authorized to request MFA.  This can be individual computers or AD groups that contain the AD computer objects.  They must have the Server Login and Privilege elevation right.
  • Server Authentication and Privilege Elevation Authentication Profiles:  You can define what step-up methods are available and even if there's additional mechanisms to be used.
  • Policy:  A policy that applies to the MFA Computers role needs to be implemented.  This method should allow for Integrated Windows Authentication via Kerberos for machine-to-machine authentication

Cloud Connector

  • This is a Windows system that runs the adproxy service.  The cloud connector only requires an outbound HTTPS connection to talk to the Centrify Identity Service tenant. 
  • Web Service: The cloud connector authenticates authorized agents using Integrated Windows Authentication (SPNEGO)

 The illustration below provides an oversimplified set of steps:

MFA - concept.PNG

Note that in case of AD connectivity failure, the centrify agent will use the AD methods (sites/services, offline cache) and it also caches the authorization data.


A Basic Lab Design

In my test environment I have:

MFA - my lab.png


  1. A Centrify Identity Service tenant App Edition (or 30-day trial)
  2. An Active Directory domain (centrify.vms) with a single domain controller (dc.centrify.vms)
  3. A domain-joined server called "member" that has Access Manager installed (Suite 2016 commercial or evaluation)
    Member will also be running the Centrify Cloud Connectors
  4. A Centrify zone called global with 2 computer roles:  App Servers and Web Servers
  5. Two Linux servers.  The names may be slightly different given that I have labs in different stages.
  6. A mobile device with a phone line running iOS or Android.


Test Cases

Test Name

What you need


Step-up on Privilege Elevation

You need a UNIX command with the “Require MFA authentication” flag set.


Start with this test


Step-up on Server Access Elevation

You need a role with the “Require MFA Authentication” flag set.

If using SSH for testing, be mindful of SSH timeouts

Context-aware privilege elevation

You’ll need two roles:
No MFA bus hours
MFA bus hours

Variation No MFA on QA/Dev and MFA on Prod.

Privilege Elevation w/o AD

This test relies in the agent’s caching capabilities.

This is a disaster recovery use case.

Privilege Elevation with out-of-band method

You need an enrolled mobile or SMS

In cases in which you can't receive other factors

Disaster Scenario

You’ll need a role with the “Rescue Rights” checkbox set.

This should be familiar to DirectAudit testers



Download and Install the Centrify Suite 2016 bits

  1. Download the Standard Edition 2016 Consoles
  2. Download the Centrify client bits for your platform
  3. Install Access Manager
  4. Install or upgrade your agents  (e.g., rpm or yum, apt or dpkg, etc)
  5. Join a zone (use adjoin)

I will recycle the pre-requisites video for the local account management since the steps are identical:


Obtain and Configure a Centrify Identity Service Tenant

  1. To obtain your Tenant
    Follow the steps here:
    Follow the steps until you activate your tenant and log in with the cloud admin account for the tenant.  You have to secure those credentials.
  2. Set up a Cloud Connector (Settings > Cloud Connectors)
    You can see steps here (download-install-configure-authorize).  Other than the "next-next" steps here what needs to be understood is what is the Cloud Connector doing.  The Centrify cloud connector service runs on Windows and provides AD bridging.
    a) The CC talks to the cloud service on behalf of your servers; uses PKI for trust and non-repudiation.
    b) The CC makes outbound connections  over HTTPS that are double-encrypted (SSL + tenant key)
    c) it has to be authorized to read objects from the AD domain by a privileged AD administrator
    d) The CC needs to authenticate the systems (or group of systems) that will use step-up using SPNEGO over 8080 (default)
    Note that if your're working in an isolated lab, this port has to be open between your Linux systems and the CC.
    e) The CC will provide information to the cloud service about email, phone numbers, etc so the user can get the step-up challenge
    f) For MFA testing, you can disable all other capabilities of the CC (like LDAP bridging and App gateway) to keep configuration to a minimum.
    cloud - cc service properties.PNGcloud - cc service dis.PNG
  3. Configure Authentication Profiles (Cloud Manager > Settings > Authentication Profiles)
    You need to set up authentication profiles for both Server Access and Privilege elevation.  For this go to .  Here's what I set up for Server Access:
    cloud - authprof.PNG
    What to use for Step-up:  You'll need to use your security savvy here.  The goal is to provide an additional control in case of password compromise.  You would not use email in this case because in an Exchange scenario, the password is the same for the AD user so if a threat agent compromised the user's password, they likely have access to his email.  The best course of action is something the user has like a token or his phone.  That's why I only checked those options.
  4. Set the Server Suite Authentication Profiles (Cloud Manager > Settings > Server Suite Authentication)
    Set the APs for Server Access and Privilege Elevation
    cloud - CSS authpro.PNG
  5. Create a Role that Contains your Linux Systems (Cloud Manager > Roles)
    In my case, I created an "MFA Computers" cloud role and as members I added an "MFA Computers" AD group that in turn contains my Linux systems.  This simplifies administration because if I want more Linux systems enforcing MFA, all I need to do is upgrade them to 5.3 and add them to that AD group.
    cloud - role mfa computers.png
  6. Policy Applied to MFA Computer with IWA  (Cloud Manager > Policies)
    We need to verify that Integrated Windows Authentication is allowed for the User Policy that applies to this role.  This will allow the servers to use Kerberos to authenticate to the web service on the cloud connector.  This is under Policy (e.g. Default Policy) > User Security Policies > Login Authentication
    cloud - policy iwa fma.PNG
    Ideally, to isolate MFA testing, you will create a new Policy that applies just to the MFA computers role and you stack it higher than your deny-all policy.
    cloud - policy iwa applied.PNG

Configure Access Manager for Centrify Identity Service Tenant

  1. Open Access Manager and open your Zone. 
  2. Right-click the zone and select properties, click on the Cloud tab and click Browse
    There is now a selectable cloud instance.  This is because of the cloud connector registration.
  3. Select and press OK twice.  Now you can test end-to-end connectivity using the Test Cloud Connection tool
    access manager - cloud testing.PNG
    You have to right-click the "DirectManage Access Manager" node to expose the tool.

Verify that your Centrified Linux system is Cloud Connector-aware

You need to refresh the cache and restart the agent to reflect the AD group membership that will allow the system to interact with the cloud connector.

  1. Sign in to your system (with a user that can elevate)
  2. Run adflush --force
  3. Restart the CentrifyDC service (service centrifydc restart)
  4. Run the 'adinfo --sysinfo' cloud command to verify cloud connector awareness.
    You're all set.


Video Playlist

This article describes the steps to install, configure and test the local UNIX user and group management feature included with Centrify Suite 2016.  You will find this article useful if you're looking to accomplish the following goals:

  • Control local UNIX user accounts (provision, disable, visibility or removal from /etc/passwd)
  • Control local UNIX primary or secondary groups (provision, control membership, or removal from /etc/group)
  • Use a single management framework (DirectManage GUI, PowerShell, UNIX adedit)
  • Leverage Centrify Zones, Child Zones or Computer Roles stored in Active Directory
  • Perform actions upon user creation/deletion, e.g. home directories, environment variables, password management/lifecycle.

Disclaimer:  This post is not a best practice, it's simply to aid you to study and test the feature before your consider it for production scenarios.


In the original article about orchestration basics, we set up a basic implementation of YellowDog Updater Modified (YUM) for RHEL and derivatives (CentOS, Scientific, Oracle Linux, etc) in different architectures

(Intel, Power, zLinux).


In this second article of the series we discuss how we can use a simple (non-idempotent) Chef recipe to deploy, and join a node to Active Directory with Centrify DirectControl.


Showing results for 
Search instead for 
Do you mean 

Community Control Panel