Centrify recently commissioned a study with Forrester Research that yielded some important information about the state of Security.  Bottom-line, we have decided to throw money and resources to the problems around information security rather than rethinking our approach, the results are more breaches and exposures.

You can access the study results here:


A key conclusion on over 200 organizations surveyed is that those with higher Identity and Access Management (IAM) maturity were breached 50% less while maintaining operational efficiency. 


As you read the previous paragraph, you may ask yourself: what is the first step the journey to the continuous improvement required for IAM maturity?  As illustrated in the model below,

a the key component is to establish identity assurance with technologies like MFA or PKI, however this is challenging enough because many organizations have not achieved this on-premises, much less in IaaS/PaaS platforms like Amazon AWS.


This is where Centrify can help.  This article is about guiding you on how to use the Centrify platform to establish identity assurance in several use cases:  

  • Accessing the AWS Consoles with shared accounts (like Amazon root) or Federated identities
  • Accessing EC2 instances locally (Linux or Windows)
  • Accessing AWS commands via the CLI (E.g. PowerShell or Python)

Please note that identity assurance concepts apply to both users and systems (due to API access);  in this use case we'll focus on interactive (user) use cases.  For system/system or app/app, other mechanisms like PKI or Kerberos can be used and we can cover in another entry.


The Centrify Advantage

The biggest advantage for Centrify lies in it's platform and integrations, as a company that covers both Identity as a Service (IDaaS) as well as Privileged Identity Management (PIM) we understand that everything starts with Identity Consolidation.   This is not the "legacy" (metadirectory/connector-based mid-2000s) identity consolidation, this is the "straight-to-the-source" standards based approach using Federation in the IDaaS side, plus direct-integration (with Kerberos) in the case of heterogeneous OS platforms.  We add to this a series of services:

  • A policy service
  • A multi-factor authentication engine (that includes modern and legacy-based support)
  • A risk-based engine (analytics) 

Our native integrations with Active Directory make us a prime vendor to consolidate capabilities;  here's an example, if an organization wants to secure access to a web app, integrate a non-windows platform to a central directory like AD and get MFA, they may engage 3 distinct vendors, however Centrify can help with world-class solutions on the three areas.  Let's look at a the examples.


Securing Shared or Federated Access to the AWS Console

Centrify Identity Service provides several turn-key templates to help with shared or federated (via SAML or using the AWS API) SSO for Amazon Web Services.  We have covered these integrations here:


However, the powerful policy engine and the support for multiple authentication profiles makes this integration simple and flexible.  


Here's a quick demo on how this integration is enabled and the user experience:

Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.


Securing Access to Linux and Windows AWS EC2 Instances

Centrify Server Suite provides native integration with Active Directory, regardless of your deployment model. 


By leveraging AD (hosted by you or in AWS), you are eliminating the duplication of identity sources caused by SSH keys with the addition of DirectAuthorize technology that provides role-based access control and privilege elevation and is fully-integrated with the policy and authentication profiles provided by Identity Service or Privilege Service.  We have discussed these integrations here:

Provided the Identity Service/Privilege Service setup is correct and the proper PKI trust is in place, for Access and Privilege elevation, all we need to do is set up the proper checkbox at the role, UNIX command or Windows desktop or application.


Here's the user experience that meets the requirements for identity assurance via MFA for both Linux and Windows in the context of access and privilege elevation.


Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.


Securing Access to AWS CLI (e.g. PowerShell)

Administration of AWS Services is often performed via the AWS CLI (implemented via Windows PowerShell or UNIX CLI).

If you're using Centrify Identity Service with SAML federation into AWS, you can implement the SSO plugin provided with the template.



Here's the user experience in PowerShell.  Note that the experience will be based on the authentication profile that applies to the user by policy.


If you have multiple roles, you get to select them:


Finally, the authentication token is stored in the $me variable and the user can move-on to use AWS PowerShell commandlets.   See the pattern here?  Identity assurance with MFA and role-based access without compromising usability and achieving this with with a single solution set.



A cliché of business schools is the statement "you can't manage what you can't measure"; but since we're dealing with IT security, you may want to track how we are performing towards our goal of consistent identity assurance, in these AWS examples, we can use AWS CloudWatch metrics to measure the percentage of access in the proper context (e.g. Console, EC2, etc) is performed with assurance.  Therefore a good metric to track would be:



MFA events are tracked for Linux, Windows and Identity Platform, this allows you to be creative and get information from CloudWatch or from Identity Service.


Note the CloudWatch widgets above.  In my Linux space, I have a ratio of close to 60% identity assurance (4 out of 7 successful logins were with MFA), however my track record on the sample data I created on Windows is much better (100%).  You use the same approach for privilege elevation via Centrify-enhanced sudo or Centrify Agent for Windows.


In the case of Identity Service or Privilege Service, the platform provide dashboards and reports like the Security Overview - User Logins


These dashboards allow for reviewing information within 7 days or 24 hours and to look at specific date-time ranges. 



Identity assurance is closer than what you think, with the "barriers of entry" for MFA solutions going down, it's all about working with the right partner and Centrify excels at securing apps, endpoints, infrastructure and secrets; finally, the obvious challenge is organizational dynamics;   If you still have groups opposed to centralizing directories or maintaining legacy infrastructure, you can split the project in several phases and attack the platforms that are easier from a people/process standpoint.  Once you can demonstrate identity assurance within those applications or infrastructure, it's going to be hard for those "holding on to the past" to ignore that the best practices are here to stay. The model applies to all aspects of any risk-sensitive information technology area and like every other framework it's not a silver bullet; new threats, attack vectors, compliance requirements and tools are introduced, therefore this has to evolve as well.


Related Articles

Using Centrify Audit Trail for UNIX/Linux with AWS CloudWatch

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

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

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. 


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. 


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. 


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. 


If you want to use the Centrify Mobile Authenticator without enabling the Mobile Device Management, you can configure this in the Policy section of your tenant.

Users will be able to use the Centrify application on their mobile device for application access and two factor authentication. 




Many federal IT departments are being told to provide 2-factor authentication not only for all logins, but also for all privilege elevations, including the launching of critical applications. Here’s how Centrify can help.



Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.


This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  


About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS servides like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 In this article we'll focus on how to use Centrify Privilege Service to secure access to Windows AMIs.


How is access to Amazon Windows AMIs secured today?


The AWS Security Best Practices document specifies the following information:


At a basic level, this just means that beyond providing the ability to decrypt the administrator password based on your private key, it's up to the customer to deploy additional controls (including x.509 authentication, Active Directory or local accounts).


For large organizations, both x.509 or local accounts may create an additional identity silo; this means that Active Directory (either an extension of the on-prem directory or an instance running in AWS is the main option).


Centrify Privilege Service and Centrify Server Suite provide the flexibility to implement these controls and we'll cover more in subsequent posts, now let's explore the benefits of combining Privilege Service with the Centrify Agent for Windows for Centralized Sessions and Windows MFA


Privilege Session Brokering facilitated by CPS provides these benefits:

  • Centralized Identity Source:  You can leverage your existing on-premises Active Directory to authenticate users accessing EC2 Windows AMIs.
  • Centralized Session Initiation:  This control centralizes all RDP sessions from a central management perspective.  With CPS, this capability is enhanced by providing watch and terminate options  (session proctoring) and session recording (capture and replay).
  • Limited Exposure:  by not using public IP addresses for your Windows systems, you are limiting exposure to attacks.
  • Additional controls:  CPS's ability to implement RBAC, Geo/time fencing can meet or exceed policy requirements.
  • Password Services:  Shared account password management for local Windows and UNIX accounts;  AD accounts, Oracle and SQL databases, Windows services and scheduled tasks.

Multi-Factor Authentication with the Centrify Agent for Windows provides these benefits:

  • You can enforce MFA using different factors like:  Mobile Authenticator, OATH OTP, Legacy (e.g. SecurID), Phone factor, SMS, e-mail or security question.
  • Contexts:  You can limit this to login or privilege elevation (if you're using Centrify Server Suite zones technology - will be covered later).
  • Enhanced controls:  If you're allowing direct connectivity, users must provide MFA and authenticate with their AD credentials.
  • Offline Access and Rescue Rights:  Leverate OATH OTP codes for MFA in case there's no access to Centrify services



With Centrify Privilege Service + the Windows MFA capabilities enabled by the Centrify Agent for Windows we can secure Windows AMIs by providing ways to leverage your existing AD infrastructure to centralize sessions, provide SAPM services and provide MFA enforced at the local level. 


Demo Video

In this demo we show how we can centralize session origination using Centrify Privilege Service, how we can use a shared account or log in manually.   We'll configure Windows MFA for a demo user and we'll demonstrate how the control is enforced via the jumpbox or if the user chooses to connect to the Windows AMI directly.


Related Articles

AWS Shared Responsibility - Securing the Amazon Account

AWS Shared Responsibility - Securing Amazon RDS Instances

AWS Shared Responsibility - Securing Linux Systems using Centrify's new Identity Broker


Many organizations have invested in multi-factor authentication solutions that work with the Remote Authentication Dial In User Service (RADIUS) protocol and they would like to re-use their investments with Centrify Identity Service and Centrify Privilege Service.

Earlier this year, as part of the MFA Everywhere initiative, Centrify added RADIUS server capabilities to the Identity Platform to provide MFA services to services that could act as RADIUS clients (e.g. VPN Gateways, etc.).


With the 16.8 monthly release, Centrify is adding the ability for the Identity  Platform to act as a RADIUS client.  This will open the opportunity for CIS and CPS users to have authentication profiles for MFA products that support RADIUS (e.g. RSA, Symantec, CA, Vasco, etc).


This lab will allow you to set up a Linux server to act as your AD-integrated OTP+RADIUS server.  Then we'll configure CIS/CPS to act as a RADIUS client and support it as an additional MFA option.



  • This is a lab entry.  Production designs require planning for people, process and technology.
  • RSA SecurID, Symantec VIP, Vasco, YubiKey, Google Authenticator, FreeRADIUS and CentOS are registered trademarks of their respective owners.


Lab Design

 The proposed lab looks as follows:radius-lab.png


As you can see, we're using the following components:

  • Identity Service or Privilege Service (can be the on-premises version of CPS too)
  • Cloud connector:  enabled for AD Bridging and RADIUS client
  • Centos 6.x System:  this system acts as
    • RADIUS Server > FreeRADIUS configured for PAM
    • Google Authenticator PAM Module > will provide OTP codes for enrolled users
    • Centrify DirectControl > Provides AD integration and NSS/PAM based identification/authentication
  • Active Directory:  Provides infrastructure identity services (directory, authentication, policy)


In this lab we will not cover the setup of an identity service instance and cloud connector.  Some resources:

 What you'll need:

  • A CentOS 6.x system configured in the same subnet as the Cloud Connector or with TCP 1812 connectivity.
  • Working knowledge of Identity Service or Privilege Service
  • Familiarity with Pluggable Authentication Modules (PAM)
  • Basic DirectControl knowledge (install, join AD)
  • An OATH OTP client (Google authenticator, Yubico authenticator, etc)

This lab starts assuming that you can log in to your Identity Service or Privilege Service instance with a user with the System Administrator right.



RADIUS+OTP Server Setup

Configuration Overview

  1. Adding the EPEL repo to be able to install Google Authenticator
  2. Install Google Authenticator
  3. Install FreeRADIUS and related tools
  4. Configure FreeRADIUS for PAM
  5. Install Centrify DirectControl and join Active Directory
  6. Enroll users for Google Authenticator OTP
  7. Test your configuration with the command line
  8. Configure Identity Service/Privilege Service as a RADIUS client


Adding the EPEL repo for Centos 6.x 

$ wget
$ sudo yum install epel-release-latest-6.noarch.rpm -y
  epel-release.noarch 0:6-8

 Installing Google Authenticator

$ sudo yum install google-authenticator -y
  google-authenticator.x86_64 0:0-0.3.20110830.hgd525a9bab875.el6

 Install FreeRADIUS and Tools

$ sudo yum install freeradius freeradius-utils -y
  freeradius.x86_64 0:2.2.6-6.el6_7   freeradius-utils.x86_64 0:2.2.6-6.el6_7

Dependency Installed:
  perl-DBI.x86_64 0:1.609-4.el6

Configuring FreeRADIUS for PAM

a) User and Group for the Radius Daemon

To  allow the radiusd daemon to traverse the filesystem to read the Google Authenticator config files on each user's home directory, you have to change the user/group in the configuration file.  This may be undesirable in a production environment.

Edit the  /etc/raddb/radiusd.conf file and find:

user = radiusd
group = radiusd

Change to

user = root
group = root

and save the file.


b) Enable PAM for the Default Site

Edit the  /etc/raddb/sites-enabled/default  file and find:

        #  Pluggable Authentication Modules.
#       pam

uncomment the PAM module and save.


c) Configure Users for PAM

Edit the /etc/raddb/users file and find

#DEFAULT        Group == "disabled", Auth-Type := Reject
#               Reply-Message = "Your account has been disabled."

uncomment and add the line as follows:

DEFAULT Group == "disabled", Auth-Type := Reject
                Reply-Message = "Your account has been disabled."
DEFAULT Auth-Type := PAM

 Tip:  To check your work so far

  1. In one session window, run the radius daemon in verbose mode
    $ sudo radiusd -X
    Ready to process requests.
    If there are any issues with the current configuration, you can verify it with the output.
  2. Open another session and create a new user
    $ sudo useradd testing
    $ sudo passwd testing
    New password:
    BAD PASSWORD: it is based on a dictionary word
    Retype new password:
    passwd: all authentication tokens updated successfully.
    Now you have a user to test your RADIUS server via PAM.
  3. In that same session, use the radtest utility with the client set for the localhost client.
     radtest testing Mysecret123! localhost 0  testing123       Sending Access-Request of id 204 to port 1812
            User-Name = "testing"
            User-Password = "Secret123!"
            NAS-IP-Address =
            NAS-Port = 0
            Message-Authenticator = 0x00000000000000000000000000000000
    rad_recv: Access-Accept packet from host port 1812, id=204, length=20
    On the first window, you'll see the verbose output somewhat like this:
    rad_recv: Access-Request packet from host port 53367, id=204, length=77
            User-Name = "testing"
            User-Password = "Mysecret123!"
            NAS-IP-Address =
            NAS-Port = 0
            Message-Authenticator = 0x8c11ad4b5c1dbd597764716d95d3d9e3
    # Executing section authorize from file /etc/raddb/sites-enabled/default
    Sending Access-Accept of id 204 to port 53367
    This verifies that things are set up correctly so far.  Cancel radiusd debug (CTRL+C)


Install Centrify DirectControl and Join AD

We'll use the Centrify Repo and join AD in Workstation mode.

$ sudo yum install CentrifyDC -y
  CentrifyDC.x86_64 0:5.3.1-398
$ sudo adjoin -w -u []'s password:
Using domain controller: dc.centrify.vms writable=true
Join to domain:centrify.vms, zone:Auto Zone successful

Centrify DirectControl started.

At this point, if you want another sanity check, you can repeat the same debugging but with an AD user credential.


Configure the Radius PAM directives for Google Authenticator

Edit the /etc/pam.d/radiusd perform two modifications. 

Add  this line on the top of the file auth required and comment the auth module.
Here what we'll achieve is to provide the Google Authenticator code as our one-time password via RADIUS.  Other combinations of PAM modules can achieve a Password+Code. 
The final result should look like this:

auth       required

#auth       include     password-auth
account    required
account    include      password-auth
password   include      password-auth
session    include      password-auth

This configuration challenges for the OTP code only and ignores the password.


Enroll an AD user with Google Authenticator

  1. Log in with a test AD user to your Linux system
  2. Run the google authenticator setup (google-authenticator)
    Last login: Thu Aug  4 06:22:50 2016 from
    $ google-authenticator[truncated]  <= copy this URL and paste it on your browser
    Your new secret key is: ETIQLTKPBQV4TVLH
    Your verification code is 2647620
    Your emergency scratch codes are:
    Follow the prompts until you complete setup.
  3. Paste the URL in a web browser and use your Authenticator QR Capture function to capture the code.
    Alternatively you can add the code manually.
  4. Repeat this process for all your test users.

Verify RADIUS functionality with OTP

  1. In a session, open Radiusd in verbose mode.  [sudo radiusd -X]
  2. In another browser, test the authentication with the code from the OATH OTP authenticator.
    radtest [username] [oath otp code] localhost 0 [pharaphrase]
    In my environment it looks like this:

You have verified functionality. 


Set up the Cloud Connector as a RADIUS Client

On the FreeRADIUS Server you have to set up the connector as a client.

  1. If you haven't done so, close the radiusd debugger.
  2. Edit the following file  /etc/raddb/clients.conf go to the end and add:
    client [your-client-name] {
            secret          = [Insert Complex String Here]
            shortname       = [Friendly Name]
    - You can use the IP address or FQDN of your RADIUS-enabled connector
    - You must choose a decent complex string as your secret and save it for the next section.
  3. Save the file.

Note:  In some Linux systems/versions you may need to set SELinux to permissive.  This is to allow radiusd to interact with PAM.


Centrify Identity Service or Privilege Service Setup


  1. Configure the RADIUS Server
  2. Configure Connector for RADIUS
  3. Enable RADIUS in your Policy
  4. Enable 3rd Party RADIUS in your Authentication Profile(s)
  5. Verify Functionality
  6. Modify RADIUS service startup


To configure the RADIUS Server

Go to Cloud Manager > Settings > Authentication > Radius Connections > Servers Tab and press Add

Name: A descriptive name (e.g. SecurID PIN+Code)

Description: Optional

Server IP Address:  The IP address of your server

Port:  Change if not default (1812)

Server Secret:  Must match the secret you set up in the previous step.



Configuring a Connector for RADIUS

You need at least one connector enabled for RADIUS that can reach the RADIUS server.

Go to Cloud Manager > Settings > Network > Cloud Connectors > [connector] > RADIUS > and Check
"Enable connections to external RADIUS servers" 


Also make sure that the RADIUS Client service is enabled.


Enable RADIUS in your User Authentication Policy

Go to Cloud Manager > Policies > [click on the policy that applies to the user(s)] > Expand User Security Policies and Click RADIUS.  Set "Allow 3rd Party RADIUS" to Yes and Save.


Enable 3rd Party RADIUS in any corresponding Authentication Profiles

Cloud Manager > Settings> Authentication Profiles > [click profile that you want to enable] and check

"3rd Party RADIUS Authentication" and press OK.  Repeat with other profiles if needed.



Verify Functionality

  1. Launch radiusd in debug mode (sudo radiusd -X) on your Linux system.
  2. Trigger a Step-up protected event in CIS/CPS  (private login, secure access, password checkout)
    Monitor the debug log for any errors.  If everything goes as expected, keep testing with other users.


Tidy-up:  Set up the Radius Service for Automatic Startup

$ sudo chkconfig radiusd on
$ sudo service radiusd start


CIS/CPS Setup Video


Last month, with the release of Server Suite 2016.1, Centrify expanded on the MFA Everywhere strategy adding support for UNIX systems (AIX, HP-UX, Solaris) for Server Login and Privilege Elevation, on Microsoft Windows, MFA was added for Privilege Elevation and finally, MFA  at login for Auto Zone and Classic Zones.  This means that Centrify Express for UNIX/Linux customers can use the industry-recognized Centrify Identity Service tenants can implement MFA or step-up authentication when accessing systems. 


This article covers the steps to implement MFA as an additional control to access systems integrated to AD with Centrify Express for UNIX/Linux.  The information in this article can also be applied to Classic zones and Auto Zone (workstation mode).

For an in depth discussion on Centrify Server Suite MFA, you can read this lab entry.

For information on how to get started with Centrify Identity Service, visit the Getting Started page.



Potential Stakeholders

  • Centrify SMEs:  UNIX/Linux admins familiar with Centrify DirectControl (CLI tools and configuration)
  • Security Lead:  The security lead can answer questions like these:
    a) What servers require step-up authentication for login?
    b) What users will be challenged for Multifactor at login?
    c) What users will have the rights to log in without multifactor or for troubleshooting purposes?
  • IT/AD Infrastructure lead:   This SME will help setting up a Windows Server to act as the Centrify connector
  • PKI Lead (optional):  If using enterprise trust to issue certificate to be used for Integrated Windows Authentication (IWA/SPNEGO) over HTTPS.

Technical Requirements

  • Active Directory
  • A supported Centrify Express OS with Centrify DirectControl 5.3.1 (2016.1) and up
  • A Centrify Identity Service tenant  (you can sign-up for a trial here) with a Centrify Connector
    Centrify Connectors run on 64-bit Windows Servers and require outbound HTTPS connectivity (can be behind a proxy)
  • A user with a supported MFA or step-up method (Phone Number, Mobile Number (for SMS), Centrify Mobile Authenticator for Push MFA, OATH OTP (Google Authenticator, FreeOTP, YubiKey, DUO, etc).
  • If using Centrify Mobile Authenticator or Google Authenticator  you'll need an iOS or Android device


Centrify Parameters for MFA on Auto Zone

Centrify Express joins Active Directory in workstation mode.  This allows for quick integration with AD for all users without worrying about UNIX identity.  UNIX login, UID, primary group, GECOS, home and Shell are generated by the Centrify client.  Configuration can be managed via parameters.   The parameters introduced for MFA are the following:

  • adclient.legacyzone.mfa.enabled: This parameter turns on MFA and it is set to false by default.
  • adclient.legacyzone.mfa.cloudurl: This is the Centrify Identity Service tenant URL that is configured to grant MFA to the system.
  • adclient.legacyzone.mfa.required.groups (or users):  These parameters specify which users (or members of the AD group) that will be challenged for multi-factor on login.
  • adclient.legacyzone.mfa.rescue.users: These are the users that can access the system in case no tunnel can be established with the MFA service.

Other relevant parameters:

  •  This parameter can be used to specify a proxy server if in use.




We will get started with a Centrify Identity Service that has the Centrify Connector set up with the AD Bridge enabled.

To learn how to set up a Centrify connector you can always review the Getting Started guide.

First, we will enable MFA using information from a user in AD (e-mail, SMS, phone factor), then we will walk the user through the process of enrolling a mobile device (to enable Centrify Mobile Authenticator for push MFA) and we'll also use Google Authenticator for OATH OTP.


Configuring a Centrify Connector

Centrify connector configuration steps are outlined here. However, the steps are as follows:

  1. In Admin Portal, navigate to Settings > Network > Centrify Connectors
  2. Click the "Add Centrify Connector"
    register cc.png
  3. Download the bits and run setup.  All you need is the Centrify connector component.
  4. You have to authorize the Centrify Connector following the steps on the wizard.  Refer to the link below for a video detailed steps.


Retrieve the IWA Cert

Since Centrify Identity Platform 16.10, IWA happens over HTTPS.  This means that you must deploy a public, enterprise or tenant certificate.  The steps below explain how to use the IWA certificate provided with the connector.

  1. In Admin Portal > Settings > Network > Centrify Connectors > click the connector > IWA Service and click "Download your IWA root CA certificate"
  2. Locate the file and try to open it with a text editor. If the text reads "--- begin certificate" you are dealing with a usable certificate.
    Save the file and transfer it to your target system (e.g. IWACert.crt)


Configuring your Centrify Identity Service tenant for Server MFA

There are 4 tasks to configure MFA for Servers in the Admin Portal side:

  1. Role Creation
    Create a role that has the "Server Login and Privilege Elevation" right and contains the computer accounts that will be requiring multi-factor authentication.
    Admin Portal > Roles > New Role > [Rights and Members]

    mfa role.png
  2. Authentication Profile
    Create an authentication profile that specifies the MFA methods to be used.
    Admin Portal > Settings > Authentication > Authentication Profiles
    Notes:  It is important to make the distinction between step-up authentication and multi-factor authentication (sometimes used interchangeably).  In addition to the login password challenge, an e-mail link delivered to your inbox qualifies as step-up, but push MFA from a registered mobile device (something you have) is MFA.
    Note that I've left out password and user-defined security question.  Checking password will re-prompt the user for their AD password and the answer to a security question is just another secret that can be obtained by social-engineering.

  3. Set up an Authentication profile for Server Suite Authentication
    Admin Portal  > Settings > Authentication Profiles > Server Suite Authentication
    For Centrify Express, only the Access Profile applies.
  4. Verification of Methods
    Make sure your users have the step-up methods populated in AD:
    If looking to provide Step-up via email, the user has to have a valid e-mail address.  For phone call, phone/mobile are required, for SMS mobile is required.

Configuring the UNIX/Linux System's PKI to use the tenant certificate

You need to make sure the ca-certificates package is installed in your system and that you append the certificate retrieved from the connector in the previous steps (IWACert.crt) to the ca-bundle file.

To check if the CA certificates bundle is installed

# On RHEL and derivatives 
$ sudo yum info ca-certificates
# If not installed
$ sudo yum install ca-certificates

To append the Centrify Connector IWA certificate to your existing CA bundle

$ sudo cat /home/user/IWACert.crt >> /etc/pki/tls/certs/ca-bundle.crt

Note:  This approach is recommended for a lab. Ideally you would have a public certificate or an Enterprise CA certificate deployed.  More info in this post.


Configure Centrify Express for MFA at login


This is a parameter-based configuration.  As defined above, you need at least 4 parameters in the /etc/centrifydc/centrifydc.conf file:


# set this one to true
adclient.legacyzone.mfa.enabled: true

# to require MFA, you can either use individual users or groups.
# groups are more efficient

adclient.legacyzone.mfa.required.groups: mfa-required
# all members of mfa-required AD group will be prompted
# rescue rights can be assigned for HA in case all CCs are down # or there's no redundant connectivity to the cloud service adclient.legacyzone.mfa.rescue.users: vip.user1, vip.user2 # vip users can access systems in case of comm failure
# The cloud URL is the key parameter to specify your tenant # note that no direct internet connectivity is required, the CC # will broker this. adclient.legacyzone.mfa.cloudurl: # Use the unique URL instead of the vanity URL if you expect
# any changes.
# There are other parameters (e.g. for a Proxy server)

Save your changes and run an adreload or simply restart the centrifydc service.


Use adcdiag to check your work:

$  sudo /usr/share/centrifydc/bin/adcdiag

In my case, I just need to make sure that ChallengeResponse is set, since I'm using stock SSH.

 $ grep Challenge /etc/ssh/sshd_config
ChallengeResponseAuthentication yes 



login as: lisa.simpson
Using keyboard-interactive authentication.
Using keyboard-interactive authentication.
[Available mechanisms]
 1 - Mobile Authenticator
 2 - Yubikey or OATH Token
 3 - Email...
 4 - SMS... XXX-2980
 5 - Phone Call... XXX-2980
 6 - Phone Call... XXX-4210
Please select a mechanism [1]:       





Device enrollment for Push MFA with Centrify's Mobile Authenticator

Push MFA enhances the experience and provides more meaningful information.  This requires that the current policy allows the user to enroll an Android or iOS device. 


OATH OTP (Google Authenticator, FreeOTP, Yubico Authenticator, Duo and more)

OATH OTP opens more possibilities with this open standard.  Users are easy to onboard, and there are a variety of Authenticators that can be used.



For those using Centrify Standard Edition with classic zones or workstation mode, you can use GPOs to manage the settings (or DevOps tools)
gpo- mfa.png

Centrify has also enhanced the documentation available for solutions like SecurID.  Check out the Documentation Center.


Video Playlist


This is the the third lab in the series around Strong Authentication.  In the previous lab we focused on StrongAuth for UNIX/Linux using PKI Smart Card or YubiKey.

We will be focusing on securing access to Internal web or SaaS apps, shared credentials and privileged sessions using Centrify Identity Service and Privilege Service.


If you're familiar with Identity Service and Privilege Service, they provide built-in MFA and step-up authentication like:

  • Centrify Mobile Authenticator
  • RADIUS Client (SecurID, Vasco, Symantec, etc)
  • SMS
  • Phonefactor
  • E-mail
  • Security Question

We are going to cover

  • YubiKey (Smart Card) for PKI-based auth to Apps secured by CIS and secrets and sessions secured by CPS
  • OATH OTP (TOTP/HOTP) using YubiKey or other OATH compatible Authenticator (e.g. Google Authenticator)

Centrify uses Authentication Profiles to control what authentication mechanisms are used in different contexts:

a) Securing access to applications or the Centrify Portal (IDP initiated)

b) Securing access to UNIX & Linux systems

c) Step-up (privilege elevation) for UNIX, Linux and Windows systems

c) Provide RADIUS-based challenges for Cisco, Juniper and other VPN scenarios

d) Securing access to reverse-proxied on-prem applications made available via Privilege Service

e) Secure applications that implement Centrify APIs (e.g. Web, Mobile SDKs)


The different flavors of Centrify MFA.png



  • Web Apps (on Prem or SaaS) need to be protected with strong mechanisms
  • Systems that provide access to secrets (like password managers) and secure session brokers also require strong authentication.
  • The proliferation of "best of breed" solutions promotes IT fragmentation and limits organizational flexibility. There's no need to have multiple individual/non-cohesive solutions to secure servers, secure apps, provide multifactor and other services.  This promotes IT complexity.
  • Regulatory frameworks (like the upcoming PCI DSS 3.2) stress the use of Multifactor Authentication in sensitive systems.
  • Organizations may have already standardized on OATH or PKI authentication and it may be undesirable for them to adopt new mechanisms or train users.


  • Both CIS and CPS support Certificate-based authentication (Smart card) and OATH OTP
  • YubiKey simplifies the adoption of both mechanisms in a single form factor.

Lab Goals

  • Limit application users (on-prem web or SaaS) to strong authentication via Smart Card (YubiKey) or OATH OTP
  • Limit privileged users (of shared passwords and secure sessions) to strong authentication via Smart Card or OATH OTP

What you'll need

For All

  • Centrify Identity Service or Privilege Service Tenant  (start a trial here) with basic knowledge an account with system administrator's rights

For the Contractor Scenario

  • A test user (can be from any source:  AD, LDAP, Cloud Directory, Federated or Social Identity)
  • A YubiKey4, NANO or NEO and Yubico Authenticator
    (alternatively, any OATH-compatible authenticator like Google Authenticator will do fine)

For the Employee Scenario

  • Active Directory with Certificate Services
  • A Certificate provisioned for the user's smart card or YubiKey
    To see instructions on how to set this up, check out the Announcement Post that contains the base lab instructions.
  • For SSO to work, the system browser needs to be configured accordingly.
    See this link to configure your browser

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


Scenario Description: 
Contractor Access

  • Define an authentication profile for login that requires Smart Card or OATH OTP for login to the Centrify Portal
    This will cover any portal-based access (IDP initiated) or unauthenticated service-provider initiated connections
  • Request OATH OTP multifactor authentication to access to an application.

Employees with SmartCards

  • Define an authentication profile that considers users authenticated with Smart Card as strongly authenticated


Yubikey - SaaS&SAPM.png


Centrify Identity Service (or Privilege Service) Setup for Contractors

  1. Sign-in to Centrify Identity Service (or privilege Service) and go to Cloud Manager > Policies.
    At this point you can either create a new policy or work with a new one tied to an specific role.  I am using a Contractors role and tying it to that role.
  2. Navigate to Policies > Your Policy > User Security Policies > OATH OTP
    Allow OATH OTP Integration:  YES
    Show QR code for self service:  [Select your appropriate setting - see other considerations at the bottom]
    OATH OTP Name:  [type a descriptive name]; I used "Google Authenticator or YubiKey"
    CIS - OATH OTP.png
    OATH OTP has been enabled, now it's time to enable it for an authentication profile.
  3. Navigate to User Security Policies > Login Authentication
    - To configure the policy for login - capture the name of the effective rule (e.g. GlobalAuth High)
    - To configure the profile for secure app access - capture the name of the effective policy.
    Save the policy.
  4. Navigate to Settings > Authentication > Authentication Profiles and identify the profiles form Step 3.
    For each profile:
    Auth profile contractor.png
    In my example, I'm using a single profile that allows for phone call and OATH OTP client, then Password.

Onboarding OATH OTP tokens for Contractors

This step can be performed in two ways:

  • Self-service from  User Portal > Account > Actions > Set up "[OATH OTP name]"
    CIS- yubikey-onboard.jpg
  • Bulk (this is for larger deployments); from Cloud Manager > Settings > Authentication > Other > OATH Tokens
    CIS - OATH bulk.png
    Use the provided Excel template to perform a bulk import of OATH tokens.

Centrify Identity Service (or Privilege Service) Setup for Smart Card Employees

  1. You can reuse the smart card certificate provisioned to YubiKey in the announcement + lab setup post.
  2. In Cloud Manager, go to Settings > Authentication > Certificate Authorities
    Give it a name, and select a method for extracting the username (SAN, RFC822 or Subject) and press Save.
  3. Enable the policy in  Policies > [policy that applies to employees] > User Security Polcies > Login Authentication
  4. Edit the "Other Settings" accordingly:
    CiS - policy pki.png
  5. Press Save
    When testing, use a browser that supports Cert-based auth and is configured correctly for your PKI infrastructure.


Test Matrix

  1. Contractor can self-service enroll their OATH OTP using the user portal
  2. Access the Centrify Identity Service (or Privilege Service portal) requires OATH OTP, then password (to protect the user's Password).
    Yubico - Auth.png
  3. Access a designated application (e.g. Amazon AWS) requires OATH OTP.

Testing for Employees

  1. Authenticate using your Smart Card or YubiKey
  2. Attempt to access Centrify Privilege Service or Identity service URL or SP-initiated connection.
  3. Select the Certificate in the picker.
  4. Type the PIN for your smart card or YubiKey
    Smart Card - CIS.PNG
  5. Depending on how you set up your policy, Smart Card sessions can be set up to bypass additional controls.


Video:  Contractor Setup


Other considerations:

  • When using self-service onboarding for OATH OTP tokens, allow for a secondary step-up (like phone call) so the user can enroll their OATH token.
  • When using self-service onboarding for OATH OTP tokens, be careful about allowing access to QR codes.  Users have to be educated that it is a sensitive operation.   Centrify provides a policy to allow this capability.
    CIS - OATH qr policy.png

Did you know that you can MFA into your Centrify User Portal and assigned SaaS apps by using an Apple Watch? As long as your paired iOS device is enrolled into the Centrify Cloud and you have the Centrify mobile app installed on both the iOS device and the Apple Watch, then you can use this right now!



This video is a companion to the demonstration video on our public YouTube channel. It shows how to configure CSS and CPS to enable MFA during Windows privilege elevation. There is a short demonstration of the resulting configuration at the end.

[Video] Server Suite 2016 MFA - Part 1 : Introduction and Demo

By TA on ‎01-15-2016 05:07 PM - last edited ‎01-15-2016 05:11 PM


Part one of a multi-part series covering Centrify's newest feature: Multi-factor Authentication (MFA). This video will provide a brief introduction, as well as a demonstration of MFA in a secure user environment running the 2016 edition of Centrify's Identity Platform.


Showing results for 
Search instead for 
Do you mean 

Community Control Panel