Ever want to generate a report for the status of particular local accounts?  Need to know  when a password is due back from a CheckOut.  Here is a quick report to have in your back pocket.  Plus you will learn how easy it is to customize reports as well.


Your Centrify Privilege Service (CPS) deployment could go a lot smoother with this checklist. This checklist is a high overview of the necesarry tasks to prepare, deploy, configure, and validate a CPS environment.


You may be familliar with storing shared account passwords and how to retreive them via password checkouts using Centrify Privilege Service (CPS).  But did you know that in addition to storing passwords, you can now also store secrets such as API keys/tokens and encryption keys within CPS?  This short article will describe how you can store these secrets and make them available for use, while ensuring their security using role-based access control and multifactor authentication.secret1.jpg






This technical blog post [with Videos] is intended to highlight the Centrify Identity Platform REST API Framework and its capabilities, specifically as it relates to automating the management of privileged accounts...


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: http://docs.aws.amazon.com/AmazonS3/latest/UG/CreatingaBucket.html

  1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.
  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:  http://docs.aws.amazon.com/quickstart/latest/active-directory-ds/architecture.html



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: http://docs.aws.amazon.com/quickstart/latest/active-directory-ds/step1.html, 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:  http://docs.aws.amazon.com/directoryservice/latest/admin-guide/cloud_setup_tutorial.html

Active Directory:  http://docs.aws.amazon.com/directoryservice/latest/admin-guide/create_directory.html


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 https://console.aws.amazon.com/vpc/.

  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 domain.name -Credential administrator@domain.name
    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 lisa@example.com -login lisa -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmUserProfile -Zone $zone –User bart@example.com -login bart -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmUserProfile -Zone $zone –User maggie@example.com -login maggie -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmUserProfile -Zone $zone –User homer@example.com -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 awsrealm.centrifying.net
    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.
             : (ip-172-31-26-75.us-west-2.compute.internal): 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 dc1.awsrealm.centrifying.net               : Pass
    ADPORT   : Port scan of DC dc1.awsrealm.centrifying.net   : Pass
    ADDC     : Check Domain Controllers                                    : Pass
    ADDNS    : DNS lookup of DC dc1.awsrealm.centrifying.net               : Pass
    GCPORT   : Port scan of GC dc1.awsrealm.centrifying.net   : Pass
    ADGC     : Check Global Catalog servers                                : Pass
    DCUP     : Check for operational DCs in awsrealm.centrifying.net       : Pass
    SITEUP   : Check DCs for awsrealm.centrifying.net 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 awsrealm.centrifying.net
Using domain controller: dc1.awsrealm.centrifying.net writable=true
Join to domain:awsrealm.centrifying.net, zone:AWS successful

Centrify DirectControl started.
Initializing cache
You have successfully joined the Active Directory domain: awsrealm.centrifying.net
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. https://your-tenant.my.centrify.com/manage
  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 (https://your-tenant.my.centrify.com/resources)
  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: http://community.centrify.com/t5/TechBlog/Labs-Using-AWS-OpsWorks-Chef-12-to-deploy-Centrify-DirectC...


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 (ODP.NET_Managed_ODAC12cR4.zip) 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.


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. 



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.


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. 




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. https://your-tenant.my.centrify.com)
    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:

[How to] create and publish a new username/password app for Cloudera Manager.


Here is a quick primer on the security risks associated stale Window Service Account Passwords and how Centrify’s new "multiplex account” feature helps…  Towards the end is an embedded YouTube video demo showing the feature in action. 







This article is an attempt to provide the background information, tools and mechanisms to spot and correct Public Key Infrastructure-related issues for those who are setting-up Centrify Multi-factor Authentication or trying to enroll Identity Broker clients.



Public Key Infrastructure is at the heart of how many Internet and corporate infrastructure services are secured today and Centrify has always provided ways to make PKI simpler for organizations.  A big example is adcert, this tool provides support for enterprise trust and auto-enrollment for Microsoft Certification Authority for UNIX, Linux and Mac. 


After the introduction of Identity Service and Privilege Service and the advent of high-profile data breaches and industry guidance like PCI 3.2 Data Security Standard (Requirement 8, Sections 3, 10, 11 & 12), many organizations are rushing to implement Multi-factor Authentication.   Another big milestone is the popularity of hybrid clouds;  Centrify has introduced a new capability called Identity Broker, this new Linux Agent allows organizations to "enroll" in Centrify Privilege Service and to "bridge" multi-source enterprise directories like Active Directory, LDAP, Google Directory and Centrify directory.


All these scenarios make use of Public Key Infrastructure to establish the assurance that clients are talking to the right entity (non-repudiation) and encryption in transit is enforced.  An important point to understand about every Centrify SaaS or on premises tenant is that it has an internal certification authority that is used for multiple uses including encryption, non-repudiation, mobile management and authentication.


PKI Trust and Multi-factor Authentication

With Centrify Identity Service and Privilege Service, it's possible for current users of Centrify Express or Centrify Standard Edition to implement MFA in a very quick and effective way; supporting both modern and legacy-based (RADIUS) solutions.  In the platform's 16.10 release, Centrify proactively deprecated Integrated Windows Authentication (SPNEGO) over HTTP to exclusively use HTTPS.  

Before release 16.10, Centrify announced the deprecation of IWA over HTTPBefore release 16.10, Centrify announced the deprecation of IWA over HTTP

The implication for users is that any interaction that used IWA (SPNEGO) required PKI trust in the authentication framework for MFA negotiation.


This means that framework after 16.10 looks like this:

mfa model.png

As you can see from the framework above, there are 3 ways you can make sure the PKI requirements are satisfied:

  • Enterprise Trust:  This is the preferred method. Ideally, an organization has a properly-implemented PKI trust capability. Unfortunately, this is relatively obscure especially in the mid-market.  A great benefit to organizations using Microsoft PKI is that Centrify DirectControl agents will take care of the enterprise trust automatically by bundling the Root and Intermediate CAs into the proper UNIX or Linux bundle.
  • Public Trust:  This was a bit expensive a while back, but the easiest way to make sure that PKI trust works out of the box is to use certificates issued by a public vendor like Verisign or GoDaddy.
  • Tenant Trust:  Each Centrify tenant will automatically create IWA certificates for all the Centrify connectors in the deployment.  This means that customers can either manually, with DevOps or with Microsoft GPOs can set up a trust chain.  This can be automated but requires a bit of work.
    The tentant will give you the option to download the IWA root certificate or the connector's host certificateThe tentant will give you the option to download the IWA root certificate or the connector's host certificate

How to determine if your UNIX/Linux system is ready for MFA

Centrify provides a tool (adcdiag) that will allow users to spot issues with the MFA configuration.   For example, in a Centrified system with an AD environment with Microsoft PKI, the root CA certificate is automatically downloaded to the /var/centrify/net/certs folder and appended to the bundle corresponding to the platform.  

Here's a sample output from a Centrified system with Enterprise Trust:


This output is favorable because DirectControl (adclient) is making sure a lot of the moving parts are in place including making sure that any root or intermediate CA certificates are in the trust chain.  The reason why this "just works" is because a few seconds after joining AD, and if the system is allowed to certificate auto-enrollment, the client will make sure all the proper certs are provisioned to the system and the CA bundle is updated.  This makes this process work like plug and play. 


In cases when there is no trust, then the ca-bundle has to be updated with the IWA trust certificate from the tenant.  When you run the adcdiag, several checks will fail including this one:


 If you inspect the file referenced by adcdiag, there will be the following information in this section: 

"Error setting certificate verify locations" and this will point to the CA bundle for the platform (e.g. /etc/pki/tls/certs/ca-bundle.crt).  There are several ways to solve this issue:

  • Enterprise:  Appending the root CA certificate in PEM format to the CA bundle file
  • Public:  Making sure the CA bundle is up-to date
  • Tenant:  Appending the IWA root ca in PEM format to the CA bundle file.


Fixing MFA CA Trust issues in UNIX/Linux platforms

You'll need to know:

  1. How to get the certificate in question
  2. The encoding of the certificate you're receiving
  3. The location of the bundle for the operating system in question
  4. For large production deployments, you'll need to use a viable distribution method



adcdiag failed in a CentOS 6 system.  The issue is with the /etc/pki/tls/certs/ca-bundle.crt.  I am working with a SaaS instance of Identity Service.

Locate the IWA Cert and Determine the Encoding

  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.
  3. Save the file and transfer it to your target system (e.g. IWACert.crt)

Append the certificate to the CA bundle

  1. In the target system, concatenate the contents of the certificate file to the platform CA bundle.  E.g.
    $ sudo cat /home/user/IWACert.crt >> /etc/pki/tls/certs/ca-bundle.crt
    Note:  there are OS utilities like "update-ca-trust" that perform this step the correct way.  This is for illustration only.
  2. Re-run adcdiag and verify the results.

Enterprise Environments

As you can see, the steps above won't scale in a large environment.  This is why the preferred method is to have enterprise trust in place.  Other ways to distribute certificate settings include scripts, DevOps solutions like Chef or Puppet and in Microsoft PKI scenarios, you can use Group Policy.


How to determine if your Windows system is ready for MFA

Windows systems may be easier to work with when it comes to Enterprise Trust but  you have to be skillful to troubleshoot as well. 


Windows Tools

  • Certificates MMC snap-in:  This allows you to review all certificate store.
    Note that you have to be a local administrator to view the computer certificate store and that Centrify will add certificates in the local store of systems running the Connector.
    Make sure you review the Enterprise Trust certs in that scenario.Make sure you review the Enterprise Trust certs in that scenario.
  • Certutil:  This is one of the most powerful tools around "certutil -viewstore root" will display the trusted root CAs.


Centrify Access Manager

This Microsoft management console provides the capability to perform an end-to-end testing in scenarios where DirectAuthorize Roles are being used for MFA.  You'll need to be at least on version 2016.

This option is under right-click Direct Manage Access Manager > Test Centrify Cloud Connection.


Diagnostics and Centrify Logger Service


The DirectAuthorize applet provides a "troubleshooting" tab that enables advanced capabilities like Diagnostics or Log inspection.


The diagnostics functon has been enhanced to help identify or troubleshoot issues with Identity Platform, this functionality is available if you are running version 3.4 (suite 2017) and above,:


The Centrify logger service is installed with Centrify Server suite.  You can add it to the Centrify Agent for Windows(tm) for advanced troubleshooting capabilities.


Identifying Issues

The Centrify Agent for Windows will provide you visual feedback when there's a PKI-related issue (see below) but internally it's checking the Certificates directory under \ProgramData\Centrify\DirectAuthorize for the binary blob that represents the tenant's certificate.


 In this case, the same solutiona applies, but in this case, we're placing the certificate in the trust store for Windows.


Like we discussed before, in large Enterprises, ideally Enterprise or Public trust is set up with automation tools or Group Policy.

Microsoft provides a great article on the topic:  https://technet.microsoft.com/en-us/library/cc772491(v=ws.11).aspx


 Bottom-line:  When attempting to configure MFA, don't forget this checklist:

  • Is there a PKI trust between the system and the Centrify service?
  • Can the system authenticate via Kerberos?  (is it joined to the domain natively (Windows) or via Centrify (UNIX/Linux))
  • Is the machine added to a Centrify role that allows for Computer Login?
  • Are all the ports required for communication cleared  (8443 or custom)?


PKI Trust and Identity Broker

Identity Broker is Centrify's newest capability that allows for multi-directory authentication in private or public clouds.

IB also requires trust for operations like enrollment. 


Identifying issues with cdebug

Depending on the state of the Linux system (if the ca-bundle is non-existent, modified or outdated) the enrollment operation will fail.  Let's look at a failed enrollment log using two PuTTY windows.


Window 1:  /usr/share/centrifycc/bin/cdebug on
Window 1:  tail /var/centrify/centrifycc.log -f

Window 2: cenroll -t tenant.my.centrify.com -c [code] -F all -l Identity-Broker-Users
Window 2: Failed to initialize connection to Centrify identity platform: Failed to connect to Centrify identity platform
Window 1:
Dec 17 18:16:07 engcen6 cenroll[9201]: DEBUG <centrify/cloud.post> Failed
to post HTTP request: Post https://tenant.my.centrify.com/health/ping:
x509: certificate signed by unknown authority

 This can be further verified with the cURL command:

$ curl https://tenant.my.centrify.com
$ curl: (77) Problem with the SSL CA cert (path? access rights?)


In this particular case, my tenant is on-premises Privilege Service, so I  can follow the instructions on this KB:

KB-7973: How to configure Linux machine trusted certificate chain to perform enrollment for Centrify...

The steps are very similar to the ones outlined above.  The strategy depends on the use case Enterprise, Public or Tenant trust is being used.


When trying to enroll, the output is very different:

Verbose: Platform detected: centos_6_6_standard
Verbose: Trying to connect to Centrify identity platform [https://tenant.my.centrify.com/] without a proxy...
Enrolling in Centrify identity platform https://bootcamp.my.centrify.com/ using registration code...

Starting Centrify agent...
Centrify agent started.
Verbose: Trying to connect to Centrify identity platform [https://tenant.my.centrify.com/] without a proxy...

Feature enabled: Application-to-Application Password Management
Feature enabled: Centrify Agent Authentication

Verbose: Restarting Centrify agent after enabled features...

You have successfully enrolled in Centrify identity platform: https://tenant.my.centrify.com/

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


Constant Improvement

At Centrify capabilities change to provide ease of use and supportability.  We hope this article can help you anticipate issues with your testing or setup.  Ultimately, at the enterprise level, PKI is a vital capability that has to be taken seriously and designed to balance the people-process-technology triad. 

I was recently reading an article about AWS security blunders.  The article takes a very common-sense approach to what can be applied on any Public or Private Cloud.   


My personal observation is that many of the challenges on any public cloud relate to the complexities of extending enterprise capability out to a public cloud and Identity and Access Management is as the heart of it. Starting with the Amazon Account and IAM, these could potentially be managed in parallel from the current IT infrastructure; this slowly becomes a management nightmare while increasing security exposure.  


The good news is that at Centrify we provide products and capabilities to meet and exceed the Access Control requirements for AWS around IaaS and our platform is uniquely positioned to help you today.




Leverage your Identity and Access Management to secure your AWS IaaS

In the article, blunders like “not knowing who is in charge of security” typically happen due to infrastructure duplication and fragmentation.  Since everything starts with Identity, at Centrify we allow you to integrate Amazon’s Identity and Access Management (IAM) with your existing directory (Active Directory or LDAP) leveraging SAML or the Native APIs.


To address the issue of “giving away too many privileges” & “not taking root seriously”  securing the Amazon Account and Implementing Amazon IAM are key areas and quick wins that can be accomplished with minimal effort using Centrify’s Identity Platform. 

Here are a few Tech Blogs that cover this topic:



The article also mentions challenges with Passwords and Keys (“relying too much on passwords” & “exposed secrets and keys”).  Passwords exist in web apps, Linux and Windows servers and even within scripts (a very insecure habit).  A big benefit of the Centrify Identity Platform is that you can implement Shared Password capabilities for web apps (password walleting), and vaulting of Windows, Linux and other systems.


See a technical showcase on CPS here:  http://community.centrify.com/t5/Community-Tech-Blog/A-Playbook-to-secure-your-Amazon-AWS-Infrastruc...


AWS and the Identity Challenge

A common strategy is to implement or extend Active Directory to AWS.  This will eliminate the need to rely on keys.  With products with our Centrify Server Suite, an access control and privilege management model can be implemented quickly and it provides a single-pane of glass that can provide security and visibility across Windows and Linux systems in AWS.  Learn more here:



However, this does require either the implementation of AD in the cloud (new forest) or the extension by implementing a site-to-site VPN and using either a 1-way trust or an RODC setup.  Although these are great best practices for the enterprise, they come with cost and complexity when working with public clouds.


Exciting New Alternatives to Secure Extend your Enterprise Identity to AWS

With our November release of the Identity Platform, we are providing two exciting capabilities:


a) Centrify Agent for Windows:  Extends our award-wining Windows PIM capabilities to Identity Service or Privilege Service customers looking to secure Windows systems on console login, RDP or screen unlock.


The back-end services supported are MFA methods like Mobile Authenticator, Yubikey, OATH Token or even your legacy tokens via RADIUS (e.g. SecurID, Vasco, Symantec), plus step-up methods like Phone Factor, SMS, or E-mail.

To see an article that covers this new capability, click here:  http://community.centrify.com/t5/Community-Tech-Blog/AWS-Shared-Responsibility-Login-MFA-for-Windows...


This new capability provides security mechanisms for organizations using Windows systems as AWS jumpboxes or that simply it is required based on the system's risk profile.


b) New Platform Agent for Linux -  an alternative way to provide Authentication and AAPM services for Linux systems in private or public clouds like AWS.  It’s a brand-new, “lightweight” Centrify agent.

This client works with the identity platform.  Linux systems are “enrolled” to our service and we act as an Identity Broker for your enterprise AD or LDAP-based identities.


The convenience of the new agent lies in its simplicity and low overhead.  Since newer workloads don’t require legacy support for NIS-like services this makes the footprint very small and the infrastructure requirements minimal in comparison of deploying a full AD forest or LDAP tree, and simpler than alternatives like one-way trusts or RODCs.   Simply drop a Centrify connector in your AWS (or other) cloud and that’s it.  Connector to cloud and agent to connector (or cloud) only requires HTTPS connectivity.  Enrollment can be fully automated using codes.


Here's a quick demo



The architecture of Centrify Privilege Service for AWS (or any public loud) is quite simple.  The Centrify connector talks to our service over HTTPS and extends cross-platform services like federation, policy, MFA, shared account password management, privilege session brokering, application-to-application password management and more.


The huge benefit is the service's identity flexibility.  Regardless of your identity source (traditional LDAP or AD), modern (Google Directory, Federated Identity, Centrify Cloud Directory) you can extend application access and PIM services.  All you need is the Centrify connector where you want those services available. 




In conclusion, regardless of your Public cloud, you will find that with Centrify you can meet or exceed your security requirements PLUS you can balance value and functionality, keeping capability fragmentation at bay.


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

Centrify Identity Service and MFA for VMware Horizon View 7

By Centrify Contributor III on ‎10-13-2016 04:58 AM - last edited ‎10-14-2016 11:41 AM

Steps for configuring MFA with RADIUS in VMware Horizon View 7 and Centrify Identity Service



Quick and easy LDAP server installation including importing user entries.


Add an LDAP server for users to access the Centrify Portal in a few simple steps.



Many governmental and commercial organizations have implemented smart cards as their preferred method for Multi-factor Authentication.  This post explains how to configure Centrify Identity Service or Centrify Privilege Service to provide authentication using Smart Cards.  This article provides the configuration steps to enable Smartcard (certificate)-based authentication for CIS or CPS.


How it works

Generally, cryptographic credentials (user certificates) are stored in the smartcard (PIV or CAC card) and the system has a dedicated reader.   Upon successful authentication (credentials verified and PIN submitted) the operating system or application will use a standard protocol (like Kerberos) or a one-time-code to grant access to the system or application.


For example, Centrify Server Suite allows the user of Kerberos for SSO to applications like Secure Shell (SSH).  Our DirectAuthorize can enforce if the user is allowed to log in with a password or with Kerberos/GSSAPI only.


In the case of Identity Service and Privilege Service, we use a Centrify capability called Zero Sign-on (SZO).  SZO provides a one-time token to use for authentication if the Authentication Profile that applies to the user is configured for Certificate-based Authentication.  All the user needs to do is navigate to the CIS/CPS site, select the smart card certificate and PIN.


This setup provides strong authentication to access Apps or for Privileged Identity Management scenarios.


What you'll need:

  1. An instance of Centrify Identity Service App+ or Privilege Service  (CPS can be SaaS or On-Prem)
  2. Public Key Infrastructure Infrastructure  (Enterprise CA, Revocation Infrastructure, well-configured PKI clients) and understanding of how the subject name is being provisioned.
  3. A copy of the Certificate Chain (or Root CA) for your PKI infrastructure.
  4. A SmartCard or Yubikey configured for authentication into your environment.
    This post contains instructions to set up a lab. See "Lab - Base Setup"

Strong Disclaimer:  This is a PKI-related topic.  You should always be workign with your PKI SME with anything related to certificates, trust chains, revocations, etc.


Configuration Overview
The configuration depends on the deployment option of the service.


  1. Configuring the Root CA in Identity Service App+ or Privilege Service
  2. Configuring a Policy that allows for Integrated Windows Authentication
  3. Testing the configuration
  4. Appendix:  Configure Privilege Service On-Premises CNAME and Zero Sign-on SSL Certificate


Configuring the Root CA in Identity Service App+ or Privilege Service (SaaS)

  1. Sign-in to Cloud Manager
  2. Go to Settings > Authentication > Certificate Authorities
    Note:  If you can't see the Certificate Authorities option, you're not running the App+ edition or in the case of Privilege Service on-premises, you have to perform the activation steps (see below).
  3. Press Add and complete the follwing information:
    Name:  descriptive name of the CA
    Extract login name from:  The options are
    a) Principal Name from Subject Alternate Name
    b) E-mail address field from Subject Alternate Name
    c) Username from Subject
  4. Click Browse and select the location of the root ca certificate.
  5. If you are confident that you have a highly-distributed (Internal & Internet facing) Certificate revocation infrastructure, check the "Enable Client Certificate Revocation Check" if you are not sure un-check the box for now.
    Note:  If you don't know what PKI certificate revocation is, it's time to find your in-house PKI expert and get him or her involved.  This is a serious topic.
  6. Press Save

Configuring a Policy that allows for Integrated Windows Authentication

  1. Sign-in to Cloud Manager
  2. Go to Policies > [Select your Test Policy] > Expand User Security Policies > Login Authentication
  3. Set the "Enable authentication policy controls" setting to Yes, if not selected.
  4. Scroll down to "Other Settings" and make sure that the "Allow IWA connections..." is checked.  Then note the following:
    Note: Certificate-based authentication bypasses the login authentication rules set up for that profile.  The key settings are:
    The first setting "Use certificates for authentication..." is the main switch.  If you un-check this box, the users in scope for this policy won't be able to use smart cards for authentication.  This bypasses any controls set under "Login Authentication" in the preceding section.
    The second setting  "Set identity cookie..."  controls whether the cookie is set for the browser.   I would not set this flag if you expect users to access via non-managed systems.
    The third setting "Accept connections using certificate..." defines whether if users logging in with smart cards or certs are treated as "strongly-authenticated"

    Make your selections based on your desired security posture.
  5. Press Save.


Testing your configuration

  1.  Navigate to your Identity Service or Privilege Service URL
  2. Depending if your browser is configured correctly, you'll see any of the following pop-ups will come up:
  3. After selecting the Certificate on the Smart Card, you'll be prompted for the PIN:
  4. Once you type-in the PIN, you'll be redirected to the appropriate portal (User | Cloud Manager | Privilege Manager).


Quick Setup Video



Appendix 1:  Enabling Certificate Authorities for Centrify Privilege Service (On-Premises)

Background:  Centrify Privilege Service can be deployed on premises on a Windows Server 2012 R2 system.  You need a CNAME record for the Zero Sign-On website and a x.509 certificate with that DNS name.


Pre-requisite tasks:

a) Set-up a DNS CNAME record to with the name hostname[zso].domain.name pointing to the hostname.domain.name.  E.g. if your system name is app1.corp.contoso.com, create a CNAME record to app1zso.corp.contoso.com and point it to the original host name.

b) You need an SSL Certificate with the DNSname for the SZO special host. 


  1. Log in to the server hosting Centrify Privilege Service
  2. Open an Administrative PowerShell and navigate to %Programfiles%\Centrify\Centrify Identity Platform\Scripts
  3. Run the setup_certauth.ps1 script.   The program will ask if the pre-requisites have been met.
  4. Confirm and you'll be prompted to provide the x.509 (SSL) cert for the SZO site.
  5. Once completed, you can return to Cloud Manager and perform the steps outlined above in the:  "Configuring the Root CA in Identity Service App+ or Privilege Service (SaaS)" section.


Other Resources and Related Topics

Documentation:  https://stage-docs.centrify.com/en/centrify/adminref/index.html?version=141#page/cloudhelp%2FCloud_Po...

Centrify's support for Derived Credentials: 
- Blog: https://www.centrify.com/products/identity-service/emm/derived-credentials/

- Docs:  https://stage-docs.centrify.com/en/centrify/adminref/index.html?version=141#page/cloudhelp%2Fderived...


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 https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
$ 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 [user.name] domain.name
user.name@DOMAIN.NAME'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 pam_google_authenticator.so 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     pam_google_authenticator.so

#auth       include     password-auth
account    required     pam_nologin.so
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
    https://www.google.com/[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

How to auto-enroll Windows servers into the cloud using Group Policies and RestAPI

By Centrify Advisor IV on ‎05-09-2016 06:39 PM - last edited ‎05-10-2016 05:19 AM

By popular demand, let me explain how we demonstrate how to let Windows servers auto-enroll to the Cloud as resources managed by Centrify Privileges Service using RestAPI and Group Policies.



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


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.

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:  http://community.centrify.com/t5/Community-Tech-Blog/LABS-Setting-up-the-MFA-for-Servers-feature-of-...



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. user@corp.contoso.com 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


This is the fifth and final article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to integrate your Linux and Windows systems to Centrify zones in AWS Active Directory for the purposes of authentication and privilege management.


In this article we'll discuss how to use Centrify Privilege Service to provide shared account password management, privilege session management plus recording and strong access controls.  Here are the detailed goals:

  • To provide a redundant secure point of access for AWS-hosted systems
  • To provide password lifecycle services:  request-approve-check-out-check-in-rotate-auto/rotate
  • To provide temporary access (sessions and password checkouts)
  • To provide application to application password management capabilities
  • To provide advanced jumpbox access to SSH and RDP systems in AWS
  • To be able to proctor SSH and RDP sessions in real time
  • To be able to review session transcription and provide session replay (DVR)
  • To provide advanced access controls like strong authentication, time-fencing, geo-fencing and more
  • To continue to leverage Active Directory or use other identity schemes(LDAP, Google Directory, Social Identity, Centrify Cloud Directory or even a SAML IdP as the identity source)
  • Minimize exposure by eliminating the need for elastic IPs (publicly facing)

Centrify Privilege Service Architecture

I've written about CPS in the community before, for some features and demos review this article: 

In summary, it is a SaaS-based Password Manager and Jump Box (in Gartner speak, provides SAPM, PSM and AAPM), however it uses the assets of identity service:  Federation, Workflow, AD-Bridge, Multifactor Authentication and more.  CPS has a connector-based architecture like this:

AWS part 5 - CPS arch.png


This means that there are several ways to use Privilege Service in IaaS scenarios.  However, I will focus on this type of design:

AWS part 5 - CPS arch.png

The benefit oft his design is that it allows flexibility. Here are some highlights:

  • The single source of identity continues to be the on-premises Active Directory.  AD Principals (like groups) can be used to control entitlements like who can access the management portal, check out passwords, modify resources, etc.
  • Allows for connected or disconnected AWS connectivity.  Cloud Connectors in AWS act as jumpboxes, regardless of the EC2 scheme (domain-joined or not) the connectivity is centralized.
  • Advanced Controls like
    • Step-up authentication:  Centrify MFA, OATH OTP, Phone factor, SMS, Email, PKI/Smartcard
    • Allow access only from corporate network: Users must be on-premises to access AWS assets
    • Geo-fencing:  access can be limited to only corporate locations.
    • Workflow:  Resource and password check-outs can use an access request system (Centrify or ServiceNOW)
    • Temporary access control.
  • Time-to-Market:  Password and session access can be deployed in minutes by launching an instance and deploying a cloud connector.  The same goes for internal datacenters.

We'll discuss some planning and provide some implementation/verification videos:



Stakeholders:   Infrastructure Lead, Directory Services Lead, Security lead, AWS SME, UNIX/Linux or Windows image lead, Database (SQL Server) SME etc.


Discussion topics:

  • What are the systems that need to be accessed?
    The answer to this question has implications for AWS security groups.  For example, the security group where Cloud Connectors will be residing must be able to establish connections over port 22 (SSH) and 3389 (RDP).
  • What are the user populations that need access to AWS systems?
    This determines the identity stores.  User populations can be full-time employees, contractors, vendors, etc.  Depending on the existing strategy, maybe not all users have AD accounts, this is where identity flexibility of CPS becomes handy.  Some examples:
    - Temporary contractors may be provisioned in the Centrify Cloud Directory instead of AD.
    - Perhaps ADFS has been implemented or partners need access, in that case CPS can be the service provider in a federation relationship.
  • What are the groups that should manage the system?  what are their entitlements?
    The answer to this question has directory service and functional implications.
  • What are the security controls to be put in place?  (strong auth, geo-fencing, time-based controls, workflow/approvals)
    The data classification of the systems determines the controls that should be in place.  The most basic could be that all AWS access must be generated from the corporate IP range, and access to the portal requires strong authentication.
  • Password Management lifecycle questions:
    Should approvals be required for password checkouts?  Should multiple password check-outs allowed? should passwords be rotated in a specific interval?  Should password health be monitored? should password be allowed from mobile devices? Should passwords for temporary systems be managed?  Should active directory account passwords be managed?
  • Password Storage
    Should the Centrify Secure Storage be used or is a physical or virtual HSM (Safenet SecureKey) available?
  • Will AAPM or self-registration be needed?
    The answer to this question has implications for AWS images or DevOps.  Centrify provides a Linux package (CLI toolkit); this allows for automation and automatic system registration.
  • Monitoring and Reporting
    What events should be sent to log aggregation (SIEM) platforms?  What reports should be generated and who are the consumers of these reports?
  • Attestation
    What is the process of validating that certain privileged users should have (or continue to have) access to certain resources?
  • Session Recording
    What is the data retention policy for audited sessions?  How many concurrent sessions (SSH/RDP) can be expected?
    These topics are covered in depth in Chapter 2 of the DirectAudit Administrator's guide



In this example, I will use an AWS environment with Active Directory to:

  • Add a cloud connector for privilege service session management
  • Manually register some EC2 Linux and Windows systems for jumpbox accesss
  • Manually manage the password of a local Linux, Windows and Active Directory domain account.
  • Use two AD groups:  AWS-CPS-Full Access and AWS-CPS-Read-only access. Members of the 2nd group must request access for password checkouts or proxied sessions.
  • Enforce Strong Authentication.
  • Using the CLI toolkit for CLI password checkouts and manual/automtatic resource and account registration.

Moderation note:  Due to the blog's 20K character limitation, videos will be used.


Requirements for this Lab

  • An AWS instance with Active Directory (managed by you or hosted by Amazon)
    • Two AD groups:  AWS-CPS-FullControl & AWS-CPS-Limited
    • A Domain Administrator to authorize the cloud connector
    • Outbound Internet connectivity via single-attached Elastic IP or Internet gateway (preferred)
  • From Centrify you'll need:
    • A Centrify Privilege Service evaluation or production tenant with sysadmin-like credentials.
    • The Installation bits for Centrify DirectAudit
  • A domain-joined system for:
    a) Centrify Cloud Connector (although not recommended, this can be the DC if running a simple lab).  Cloud connectors require outbound HTTPS connectivity and to act as jumpboxes for Linux and Windows systems, they should have connectivity over TCP ports 22 and 3389  (or your custom ports if changed).
    b) DirectAudit components:  this will be the not recommended all-in one scenario (Database/Collector/Agent). 
  • Test Linux and Windows EC2 instances.
  • Optional:  An Android/iOS mobile device for Touch/OTP MFA or a Yubikey 4 or NEO for OATH OTP


Requirements Verification

Installing a Cloud Connector

Installing DirectAudit

Configuring Roles for CPS Access

Configuring Workflow and Approvals

Using the CLI Tookit (AAPM)

Managing Active Directory Domain Account Passwords

Session Management, Proctoring, Capture and Replay

Dashboards and Reports

Advanced Controls (Policies, Authentication Profiles, Strong Authentication)



Some of the adjustments that can be made include:

  1. Password storage:  HSM or Secure Centrify Storage
  2. Different directory sources for different user populations
  3. Smart Card Authentication
  4. Bulk import of systems
  5. CLI tookit baked into master AWS EC2 Linux instance.
  6. Use of PowerShell to automatically register Windows accounts
  7. Limited visibility of resources using the Privilege Portal login right.


End of Series - Conclusion

This ends the series on AWS and hopefully you've seen how the Centrify product lines:  Server Suite, Privilege Service and Identity Service work together to secure your AWS environments while balancing operational efficiency and productivity.  


Related Articles

Part I: Securing AWS Series Overview

Part II: Securing the Amazon AWS Root Account with Centrify Identity Service and Active Directory

Part III: Securing Amazon IAM using Centrify Identity Service and Active Directory

Part IV: Securing AWS EC2 Linux instances with Centrify Server Suite and Active Directory

Part V: Securing AWS EC2 Session Access (Jumpbox) and Passwords using Centrify Privilege Service

Como gerenciar senhas de identidades privilegiadas com o Centrify Privilege Service

By Centrify Advisor I on ‎03-27-2016 09:32 PM - last edited ‎03-28-2016 02:47 PM

Como gerenciar senhas de identidades privilegiadas com o Centrify Privilege Service - armazenamento e rotação de senhas, check-out, check-in, acesso remoto, monitoração de sessões




In a previous entry, I wrote an article titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" and I described the use of Centrify Identity Platform and Active Directory  to implement enhanced security controls to protect AWS deployments.


In this first part, we'll address how to secure the AWS Root Account.  Amazon suggests protecting the root account with Multi-Factor Authentication, however, in this article I'm describing a strategy to not only meet but exceed the requirements to protect this account.


Amazon Article - az checklist MFA.jpg


Enhanced Objectives

  • Eliminate sharing of the Amazon AWS root account
  • Protect the password by not exposing it to any users
  • Limit access only from the corporate network
  • Limit access to the AWS account to those with business need-to-know
  • Activate MFA with Centrify Step-Up Methods (Mobile Authenticator, Phone factor, SMS, Email, Security Question)
  • Activate MFA with Amazon's OATH-based virtual MFA


The Value of Centrify Identity Service

Centrify Identity Service provides a powerful policy engine that allows for the implementation of these controls, not only for the Amazon AWS app, but for any web application that has a user/password authentication pattern and uses a shared account.


As customary, we'll use the Plan-Do-Check-Adjust methodology.



Role-Based Access Control

- Should the application always be accessible by a limited group of users?

   - Should application access be governed by AD group membership or Centrify Role?

Should the application be accessible to nobody and only requested on demand?

   - Who will approve the application access request?


Additional Controls

  • Should the application be accessible only from the corporate network?
  • Should the application be accessible at certain times?
  • Should the application require step-up authentication.
  • What should be the step-up mechanisms? (Centrify MFA, OATH OTP, Phone factor, Email, SMS, Amazon Virtual OTP,  etc)


An example

Access Control will be controlled by AD group membership (e.g. AWS-Root-Users); ad-hoc access will be controlled via workflow. The app will be accessible with a step-up mechanism. The approvers will be an AD group called AWS-Root-Approvers.


Technical Requirements

  • Active Directory with security groups created and populated
  • Centrify Identity Service Tenant
  • A Member Server running the Centrify Cloud Connector with the AD Proxy capability enabled and connected
  • An Amazon AWS Account and a user with IAM rights to create an Identity Provider and Roles



Access Control Building-Blocks

Create the AD Groups

  1. In Active Directory Users and Computers, navigate to an OU for a CIS bridged-domain.
  2. Create Two AD groups:

- AWS-Root-Users: add the permanently authorized users.

- AWS-Root-App-Approvers: add a set of users that will approve access requests (ideally not the same as above to enforce separation of duties)


Create the AWS Root Role

Members of this role will have permanent access to the AWS Console as root. This is controlled by AD group membership.

  1. In Cloud Manager, navigate to Role and Click Add Role
  2. Description: AWS Root
  3. Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

AWS Article - Securing AWS Root - App-Role - AD Members.PNG 

Create the AWS Root Approvers Role

Members of this role will be able to approve who gets to access this app. This is controlled by AD group membership.

  1. In Cloud Manager, navigate to Role and Click Add Role
  2. Description: AWS Root Approvers
  3. Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.


Configuration in Identity Service

Add and Configure the AWS User/Password App

  1. In Cloud Manager, navigate to Apps > Add Web App
  2. In the Search Box, type AWS and press Enter, on the results, pick the "Amazon Web Services AWS User/Password" template and click Add.
    AWS Article - Securing AWS Root - App.png
  3. When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
  4. Description - in this step you will change the name to something descriptive to your environment.
    AWS Article - Securing AWS Root - Cust App.PNG
  5. User Access - check the box next to the role you created for this purpose (in our example AWS Root)
  6. Policy - we'll revisit this in the "Adjustments" section.
  7. Account Mapping - This is where you'll securely store the AWS credentials. Select
    a) Select "Everybody shares a single username"
    b) Populate the username with the AWS root account email address and the password with the current password.
  8. Press Save, you're ready for initial testing.



At this point you can sign-in to Centrify Identity Service with any user in the AWS Root CIS role or an access request can be triggered via the "Add Apps" menu of the User portal.

  1. Sign-in to the Centrify Identity Service User Portal with a user from the AWS Root Role
  2. You should see the AWS As Root App.  Click on it.
  3. This should launch a new browser tab and provide you with assisted injection of the credentials using the Centrify Browser Extension.
  4. You can also test the Access Request/Workflow capability by logging in with a user that is not entitled to the application, then click "Add App" and search for the newly-created app. 

AWS Article - Securing AWS Root - request.png




Limiting Access only from the Corporate Network

This is desirable if you want to make sure users can only access the AWS console from the on-premises corporate network. The planning steps imply the addition of corporate subnets or IP addresses that are translated via NAT for outbound internet connectivity to the Centrify Identity Service Settings and using the Policy tab of the AWS Root App to enforce these controls.


Adding Multifactor Authentication or Other Controls

MFA is built-in to Centrify Identity Service.  All you need to do is check the box, and provided there's an authentication profile that will support the step-up methods you will be set.


AWS Article - Securing AWS Root - policy.png


Enhancements of CIS 2016.2

Amazon AWS provides an virtual MFA capability that leverages OATH.  As of February 2016, Centrify allows you to use any OATH based OTP mechanisms, this means that you can leverage those mechanisms as well.

AWS Article - Securing AWS Root - OATH.png 


Video Playlist



Related Articles

Part I: Securing AWS Series Overview

Part II: Securing the Amazon AWS Root Account with Centrify Identity Service and Active Directory

Part III: Securing Amazon IAM using Centrify Identity Service and Active Directory

Part IV: Securing AWS EC2 Linux instances with Centrify Server Suite and Active Directory

Part V: Securing AWS EC2 Session Access (Jumpbox) and Passwords using Centrify Privilege Service

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.


Showing results for 
Search instead for 
Do you mean 

Community Control Panel