IT infrastructure leads have the need to perform automation activities beyond what's exposed in the  graphical user interface.  This post discusses (with an example) how we can leverage the Centrify Developers site, the Centrify PowerShell Samples, novice scripting ability and  and a bit of infrastructure knowledge to automate this task:  interactively populate a system set with computers with an Active Directory OU.


Employee on-boarding, transitions and departures often require manual and time consuming user administration tasks performed between HR and IT. Generally, identity originates in the HRIS system when the candidate becomes an employee. Coordinate between HR to IT is done such that, IT can create accounts for the new hire in Active Directory and every application required for their job. Similarly, during a transitin or departure, HR coordinates with IT to modify or disable access in Active Directory and every application. 


With an integration to Centrify, Workday can serve as the master employee database within the enterprise. New hires, transitions and departures are managed by HR within the HR system while Centrify automatically provisions or de-provisions accounts into Active Directory and downstream productivity applications. Specific benefits include: 


  • Automatic provisioning of new hires in Workday to Active Directory.
  • Randomly generated Active Directory password automatically emailed to new hire.
  • Automatic account updates (e.g. promotions, department changes) of employees in Workday to Active Directory.
  • Automatic disablement of users in Active Directory when terminated in Workday.

Here is a demo video of how the integration can help streamline user administration in your enterprise: 



See this work within your environment by registering for a free 30 day trial here.

This tech blog explains how an Administrator can extend Active Directory to include Exchange server specific Active Directory Attributes, to use some additional Exchange specific features with Office 365, even though Exchange server is not/was not installed on premise.


Centrify provides an account migration tool that simplifies the process of converting a local account's home directory into the Active Directory account. Migrating the account helps to save the user's files, application settings, and browser bookmarks.


Centrify for Google Chromebook Single Sign-On Configuration Guide


Google G Suite has become one of the most popular on-demand business software in the market and your organization took the plunge to migrate to Google G Suite. You need to assign licenses to your end users automatically, and give them single sign-on. You’re worried about Chrome Book device management and BYOD, and how to manage all that for on-premises apps and cloud apps, too. You’ve got a few questions, and are looking for answers. Without SSO user productivity is greatly affected, without Multi Factor Authentication the risk of exposing inappropriate access increases and without automated account provisioning / de-provisioning IT has to manage all accounts manually.


Fortunately, Centrify Identity Service (CIS) provides a solution. CIS for Google G Suite offers a complete, robust, and easy-to-use Active Directory (AD) or CIS Cloud Directory integration with Google G Suite, providing a seamless authentication experience for Google G Suite users and an easy to use intuitive Administrative interface for IT staff to automate the process of on- and off-boarding employees with day one productivity.

With CIS you can ensure that users have seamless access via single sign-on (SSO) and that their Google G Suite accounts are created, updated, and deactivated on an integrated cycle with the rest of the systems in IT.


Centrify Identity Service enables integration with any web application that also enables administrators to:

  • SSO via SAML or CIS form fill to all Google G Suite: Gmail, Docs, Sites, Calendar, Analytics, etc.
  • Provide secure SSO with Active Directory integration
  • Automatically provision/de-provision users & apps by Active Directory group
  • Demonstrate compliance through usage auditing
  • Increase application ROI with seat-utilization reporting

Secure Application Access via MFA from unauthorized systems or locations


Centrify for Google G Suite offers a complete, robust, and easy-to-use Active Directory (AD) or Centrify Cloud Directory integration with Google G Suite providing a seamless authentication experience for Google G Suite users and an easy to use intuitive Administrative interface for IT staff to automate the process of on- and off-boarding employees with day one productivity.


With Centrify you can ensure that users have seamless access via single sign-on (SSO) and that their Google G Suite accounts are created, updated, and deactivated on an integrated cycle with the rest of the systems in IT.

Secure access to Google G Suite from any device. Enforce and update mobile security settings, and remotely lock or wipe devices. Lock the Centrify Mobile App with a passcode or fingerprint, and prevent unauthorized users from accessing your Google data. No separate software required.


The Google G Suite Deployment Guide covers…


  • Preparing your Google G Suite and Google G Suite developer account
  • Limiting access to certain Google G Suite based on Security Group
  • Configuring automated account provisioning into Google G Suite
  • Enabling Single Sign On in Google G Suite
  • Provisioning new Users
  • Integration with Active Directory
  • Securing the Administrative Account for Google G Suite



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


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

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



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


Basic AWS Setup

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

  1. Sign Up for AWS

  2. Create an IAM User (optional)

  3. Create a Key Pair

  4. Create a Virtual Private Cloud (VPC)

  5. Create a Security Group

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


Planning to modify your Security Rules

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

Create an S3 Bucket

Official instructions here:

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


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

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


Active Directory in AWS

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

For more information:



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


1. Setting-up Active Directory in AWS

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

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

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

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


2. Configuring Microsoft DNS with a  Forwarder

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

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

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

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


Using an Amazon-hosted option

Simple AD:

Active Directory:


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


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

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


  1. Open the Amazon VPC console at

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

  3. Select Create DHCP Options Sets.

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

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

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

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


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

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


Centrify Standard Edition Lab Setup - Member Server

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

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

Add Windows Features

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


Install Centrify Standard Edition Tools

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

 Initialize Centrify Standard Edition

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

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

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


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


Sanity Check # 3

At this point, you should:

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


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

Users, Groups and Roles

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


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

Sample User Creation Script

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

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


Create and Configure a Centrify Zone

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


Zone Creation and User UNIX-enablement

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

 This script creates the AWS zone and enables our users 

UNIX and Windows Admin Roles + Assignments

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

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

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

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

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

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

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




Install Centrify DirectControl and run adcheck

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

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


Modify default AWS EC2 SSH Server Settings

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

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

Join your EC2 Linux instance to Active Directory Manually

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

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

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


Verify your UNIX Access and Privilege model

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

     Now you can logout Lisa.

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

Join your EC2 Windows member to the Centrify Zone

Grant your test users remote desktop access

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

Install the Centrify Agent for Windows

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

Verify your Windows Access and Privilege model

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

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



Sanity Check # 4 

At this point you should have

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

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




Privilege Service Lab Setup - Centrify Tenant and Connector 

Obtain a Privilege Service Tenant

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

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

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


Sanity Check # 5
At this point, you should:

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

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



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

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

Using local MacOS administrator accounts can lead to security and compliance issues such as unauthorized sharing of the administrator password with non-administrators or remote access by a former employee. The secure approach is to grant Active Directory users Mac administrator rights to minimize risk and meet regulatory compliance. This article will show you how to grant Mac administrator rights to Active Directory users through Centrify's Active Directory group policy settings.


 1. In Group Policy Management, create a GPO and enable: Computer Settings > Policies > Centrify Settings > Mac OS X Settings > Accounts > Map zone groups to local admin group




   a) Click on the Add... button. A new window will appear.




   b) Click on the Browse button. A new window will appear. You can enter manually enter a group name in this window but it is better to browse and select the group to ensure the proper group name is entered.



Selecting Group.png


   c) Enter a keyword into the Name field for the Active Directory group that you want to add, then click on Find Now. Make sure you add IT/helpdesk team and any user that needs admin rights on the Mac.


type group name.png


   d) Select the desired group name and click OK.


Select desired group.png


The setting will apply when the user logs out and logs back in.


If your Mac is using Zone mode, use the following article:



Prevent unauthorized access and minimize risk by restricting MacOS login access to specific Active Directory users or groups. 


How to retaining the user's Mac home directory, when a user wants to change their name after marriage or divorce.


Support has helped multiple customers who are trying to meet the challenges posed by the badlock vulnerability in samba while also learning about how to move to Centrify's new adbindproxy component.  This article is based on our recent experience helping customers migrate in hopes it will help other customers who are seeking similar guidance.


The following information applies to Red Hat Linux. If you are using a different operating system, please recognize that some of the commands may differ somewhat.


Let’s log into a Linux machine that is joined to a Centrify zone and has Centrify-enabled samba on it. Once logged in, let’s check the shares on the machine by running smbclient at the command prompt.


After verifying the correct shares are listed, let’s backup the samba configuration file:


dzdo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak


We’re now ready to uninstall the Centrify-enabled samba installation form the machine using the rpm command:


dzdo rpm –e CentrifyDC-samba   (This is case sensitive)


And then verify it was removed:


dzdo rpm –qa | grep –i Centrify


Ensure nothing for Centrify samba is listed. We’ll then want to remove any stock samba 3 installations. We will first search for them:


dzdo rpm –qa | grep samba


If any show up, we’ll then want to remove the packages with the yum command:


dzdo yum remove samba*

Enter a y to remove when prompted.


We’re now ready to install samba 4, again utilizing the yum command:


dzdo yum install samba4*

When prompted, enter a y to install.


We should then verify installation:


dzdo rpm –qa | grep samba


As long as the installation is listed, we are ready to move the backed up samba config file into place in order to utilize all of our previous samba settings:


dzdo cp /etc/samba/smb.conf.bak /etc/samba/smb.conf



You can check the date stamp to ensure the smb.conf file is the one we just copied into place.

If you’d like to verify the share files are still showing correctly, please run testparm at the command prompt. The shares should show.


We’re now ready to download and install Centrify’s adbindproxy. Please open a browser and navigate to and then go to Support and then Download Center and use your Support Portal login to log into the site. Once logged in, please go to “Tools and Troubleshooting” and find “Integration with Samba”. It will then show a list of the different operating systems. Please select the TGZ button next to the line that matches your operating system and download the file.




Once the download completes, please copy or move the file to the *nix machine. You can make a directory on the Linux machine where you’d like to untar the tgz file:


mkdir /tmp/adbindproxy


You can then navigate to the directory where the tgz file is located and untar it:


mv centrify-adbindproxy……..tgz /tmp/adbindproxy/

cd /etc/adbindproxy

tar –xvf centrify-adbindproxy…….tgz


We’ll then install adbindproxy with the rpm command:


dzdo rpm –Uvh centrify-adbindproxy…….rpm


After the installation is complete, we’ll want to run the configuration script for adbindproxy and we’ll mostly be taking the defaults in the script with a few exceptions:


dzdo /usr/share/centrifydc/bin/


One of the prompts will ask if you want to join the machine to a zone, if it’s already joined, you can jess press enter. If you need to join it to a zone, you can enter the zone name here and press enter.


The next prompt you want to watch for is the one that says:


Please specify the stock samba winbind listen path(dir)if it is not in [/run/samba/winbindd]:

RHEL 6 often uses /var/run/samba/winbindd for its winbindd listen path so you’ll want to verify the winbindd path and change it here if necessary. If it uses the default path, you can just press enter.


You should just be able to take the defaults through the rest of the script but you may want to read them to verify they are correct before pressing enter.

After the script completes, the samba services, smbd, nmbd, winbindd and adbindd, will need to be restarted. Centrify has a built in command for restarting all four services so that they don’t have to be restarted one at a time. At the command prompt, please run:


dzdo service centrifydc-samba restart


You’ll be able to verify the services are starting OK at this point.


We’ll want to add this setting to chkconfig to ensure this command runs if the server is ever rebooted. We can do that by running the following command:


dzdo chkconfig --add centrifydc-samba


We then need to start this chkconfig process:


dzdo chkconfig centrifydc-samba


And then verify it started correctly for the run levels that are necessary:


dzdo chkconfig --list centrifydc-samba


We’re ready to verify the samba version installed:


smdb –V


We can also verify we see the Linux shares:


smbclient -L //localhost


And then connectivity to the shares:


smbclient //localhost/sharename


It will go to a prompt that looks like smb:\> where you can type in ls and the shares should be listed.


You may also want to go to a Windows machine and verify you can get to the shares from there. If you go to Windows Explorer and, in the address window, type in \\servername\sharename, you should see the contents of the share.


You’re all set. You are now running on stock samba with Centrify’s adbindproxy in place to help integrate samba with Centrify.


Centrify has some additional resources on this subject if you’re interested.

There’s a Samba Integration Guide that came with the adbindproxy download and can be found in the directory where we untarred the tgz file. You can also get this documentation from the Centrify website by going to:


There is also a video that goes over the process step by step that you can view below.



There are also some knowledge-base articles that are helpful with this process. You can find them in the community section of the website. Links to these KBs are listed below.


Quick and easy LDAP server installation including importing user entries.



Staff changes are part of organizational life; promotions, job changes, expired contracts, M&A activities, retirements and other causes contribute in IT turnover.  In researching this article I saw turnover rates from 17% to 38% in different industries.


As technology deployments mature, managers and subject matter experts will change, for those who inherit new security practices there's no other source of stress than being handed infrastructure that came-in "before my time" - there's a natural impulse to press the "reset" button.  Regardless of what your role is (Application Architect, IT Manager, UNIX or Active Directory Lead), you first need to get an understanding of what Centrify products are providing for you today, if you are maximizing the investment, if the current SMEs are trained to support the products, and if the solutions can solve existing or upcoming challenges.


This article provides tips for leads that inherit Centrify Datacenter deployments.


Tip #1:  Know your Centrify Representatives

This is a fundamental step.  Your Centrify representatives (Regional Account Manager and Systems Engineer) have a lot of information about your account.  They understand the original drivers for Centrify implementation and may also know areas for improvement.  Here are a few things they can do for you:

  • They can onboard your SMEs to the Customer Support Portal
  • They can help with escalations if there are outstanding cases
  • They can provide briefings about new or existing features
  • They can help with commercial topics (business justification, budgets, quotes, etc)
  • They can help you understand your maintenance benefits
  • They can help you understand the product lifecycle
  • They can coordinate roadmap sessions with Product Management leads.

As you can see, staying in touch with your existing representatives can help you maximize your benefits as a Centrify customer.


In an nutshell, Centrify provides 3 solutions:


Tip #2:  Make sure all staff has access to the Customer Support Portal and other Resources
Centrify has invested a lot on revamping resources for customers, therefore access to the Support Center is a key asset because you can:

a) Access the KnowledgeBase:  This is the first step when encountering an issue
b) Create and Manage Cases/Escalations: Obtain a self-service view of any or all outstanding cases.
c) Documentation Center:  All Centrify documentation resources in a single place.
d) Download Center:  All current customers with maintenance are entitled to upgrades
e) Security, Support and Lifecycle centers:  Read all about security notifications, SLAs and software version support.
f) Centrify community (public):  Feel free to leverage the community for questions, issues or enhancement requests.

Tip #3:  Internally:  Identify your Stakeholders

You and your team need to have a 360-degree view of your stakeholders.   Centrify Server Suite is all about re-using Windows Active Directory infrastructure for authentication and privilege identity management, however the reach extends beyond what's obvious:


Application Architects:

Architects may look at the authentication methods exposed by Centrify (Kerberos, GSSAPI, SPNEGO, PAM, SASL, etc) and may be using it with applications.  This use case goes beyond Operating System authentication and privilege elevation.  They also may be counting on Centrify's AD integration in IaaS environments like Microsoft Azure or Amazon EC2.  They may also be leveraging the Centrify LDAP Proxy to provide lookup or authentication services for legacy apps.


Security:  Security leads may be using attestation data provided by Centrify to answer the proverbial question: "Who has access to these systems and what can they do" or they may be in charge of defining roles/rights, etc.  Extra tip:  Centrify has invested on a Report Service just for attestation data.


Active Directory:  As the underlying infrastructure used by Centrify, you have to be involved in impact assessment and change control for AD.  Extra tip:  Centrify software is ready for any Domain for Forest functional level, however it is good to know what are the implications.


Other Infrastructure Leads:  There are other infrastructure leads (e.g. storage administrators) that may be using Centrify utilities (like the LDAP or NIS proxy) for Windows to UNIX identity consolidation or Mac OS X administrators that have achieved advanced AD integration with Centrify's OS X client/


Tip #4:  Know where your deployment is today
This is a key step.  You need to understand how Centrify is used today because of compliance alignment or capability reasons.


Technical Category

  • Are you using software that is end-of-life?
  • Are you over or under-deployed?
  • What's your current Centrify inventory?
  • Are you missing any activation keys?
  • Are you using out of date practices (e.g. Classic zones)?
  • Are you submitting deployment reports as per your MSA?

The questions above can be answered by using the Access Manager console or the stand-alone Centrify Deployment Report Utility.



Are your consoles up-to-date?
Although consoles should not be used for day-to-day administration (if you've deployed based on best practices), it's convenient to keep them up-to-date (no worries, they are backwards-compatible).  New versions of the consoles come out two or 3 times a year.


Have you implemented privilege management? 

A common occurrence in environments with large turnover is that Centrify Standard Edition implementations are not using the software for PIM on UNIX/Linux or Windows;  we often see organizations using sudo/sudoers or "-a" or "run as" accounts instead of leveraging the robustness of Centrify software.


"What is DirectAuthorize"

"A better way to sudo" by @Gautam


Have you implemented multi-factor authentication? 

Step-up or Multifactor authentication has evolved from a VPN-only capability to a must have in different contexts.  Centrify software is ready for this, and with Centrify Identity Service, you can get Push MFA, OTP, OATH, Phone factor, SMS, YubiKey and legacy support for physical tokens like SecurID on UNIX, Linux, Windows, Apps and VPNs.


Have you integrated your filers?

When consolidating Windows and UNIX identity, your heterogeneous client environment can benefit from unified shared folder access and Centrify provides utilities to provide identity data to filers such as Hitachi, EMC, NetApp and others.  This ensures that a multi-protocol share (NFS, Apple, CIFS) provides unified access.


Is your deployment in good health?  When was the last time the environment was analyzed?

There are several tips to know if your deployment is in good health.  Start by using the Analyze Wizard to determine if there are any issues with orphaned objects and poor habits.

On the client side, disconnections and frequent unlatching may be related to issues with DNS, connectivity or domain controller overhead.  Use the "adinfo -T" command or the adcheck utility.


Are your DirectAudit stores holding-up as expected (data retention)?

If you are using Enterprise Edition, data retention and DirectAudit storage has to be closely monitored.  Centrify provides PowerShell to initiate actions automatically

Process Category

  • How is your UNIX/Linux/Mac onboarding today?
  • How do you provision UNX/Linux roles and rights? Is the process manual or automatic?
  • How do you attest or report on access/privileges?  Is the process manual or automatic?
  • How do you manage the lifecycle of servers (build-join-decommission-leave)?  Are there areas of optimization?

Remember that technology enables your process, not the other way around.


Tip #5:  Set up yourself and your team for success

IT is a service-oriented business, however if there are cognitive gaps, your personnel won't be able to deliver on established SLAs and they will go through unnecessary stress.  Ask yourself and your team:

  • Are your SMEs trained to support Centrify?
  • If you're taking on a re-design, are your SMEs ready?

Centrify offers several training offerings including onsite training, public classes and computer-based training.  Learn more here:

If you consider AD and Centrify critical and you want to take it to the next level, you can review the certification program.

Tip #6:  Assess if you are adhering to current Centrify best practices

The core product of Centrify Server Suite (DirectControl) has been around for 12 years at the time of this writing; most importantly, Centrify has invested heavily on the product with new features, security and maintenance releases.  Platforms are added, but most importantly, design guidelines change.  The same way Active Directory's design principles have changed since Windows 2000, a similar change has happened with Centrify.  The introduction of Hierarchical zones, UNIX/Linux and Windows RBAC, Utilities and MFA have changed drastically the way Centrify implementations are executed.  Gone are the days of multiple 'flat' classic zones.  Many other different constructs have been introduced for flexibility. 


In addition, there are many deployments out there that are not complete.  Maybe turnover hit during the project or other priorities pulled your team out of the project before the areas of Privilege Management have been implemented.


There's also the mentality of "if it's not broken, don't fix it" this is completely miss-aligned with the principle of constant improvement.


This is why Centrify includes an upgrade guide with the documentation and also provides PS-led health checks that help identify areas of improvement.  There's also a newly-created Centrify+ program for existing customers. 


2016 upgrade guide:

Centrify Health Check Datasheet:

Centrify+ Datasheet:

Tip #7:  Embrace automation and DevOps
marketing-automation-icon.pngAll Centrify software is ready for your existing automation tool set.  Chef, Puppet, Ansible, Satellite, etc, they all support native package deployments.  In addition, cloud IaaS (like Amazon OpsWorks) have a framework that makes the launching of instances, automatic joins and the decommissioning very simple.


Amazon Series:


Windows PowerShell modules provided with DirectManage and DirectAudit extend automation to other levels.  This can be combined with orchestration, workflow or ITSM tools like ServiceNOW.


Utilities like the Zone Provisioning Agent can make any traditional IdM or Worflow integration point simple, by performing add/moves or changes of AD security groups.


Tip #8:  Are you measuring?  You can't manage or improve what you aren't measuring

Metrics are part of your arsenal to develop a baseline and understand your business area and since Centrify is all about Access Control, you should be able to measure:


  • Successful or failed authentication attempts to UNIX/Linux or Mac assets by regular users
  • Successful or failed authentication attempts to UNIX/Linux or Mac assets by privileged accounts [with or without MFA]
    $ dzdo tail -f /var/log/messages | grep dwirth                                
    Jun 25 17:13:46 engcen6 adclient[1930]: INFO  AUDIT_TRAIL|Centrify Suite|PAM|1.0|100|PAM authent
    ication granted|5|user=dwirth(type:ad,dwirth@CENTRIFYIMAGE.VMS) pid=51511 utc=1466892826753 cent
    rifyEventID=24100 status=GRANTED service=sshd tty=ssh client=member3.centrifyimage.vms       
  • Successful or failed privilege elevation events on UNIX, Linux or Windows systems [with or without MFA]
    INFO  AUDIT_TRAIL|Centrify Suite|PAM|1.0|300|PAM account
     management granted|5|user=dwirth(type:ad,dwirth@CENTRIFYIMAGE.VMS) pid=51481 utc=1466892756393 
    centrifyEventID=24300 status=GRANTED service=dzdo tty=/dev/pts/1 client=(none)  
  • Failed attempts by valid users in unauthorized UNIX/Linux or Mac assets
  • Centrified systems that grant more access
  • AD users with more Centrified system access
  • AD groups with more Centrified system access
  • UNIX/Linux systems without Centrify software (unprotected)
  • Password change frequency for UNIX-enabled users
  • Mean time between access revokation
  • Orphaned accounts (computers, users)

Tip #9:  Maximize your Centrify Assets

  • Unlike other solutions, Centrify is not only Red Hat Linux-centric, it provides support for all commercial Linux, HP-UX, AIX, Solaris and OS X
  • Centrify Standard Edition provides Privileged Identity Management for Windows and helps eliminate the issue of widespread   local/domain administrator while preventing advanced attacks.
  • Centrify Server Suite Enterprise Edition adds session capture and replay for UNIX, Linux and Windows
  • Centrify Platinum Edition adds Group Policy-based IPSec/PKI server and domain isolation
  • Centrify Identity Service is an industry-recognized IDaaS platform that includes SSO plugins for Apache, Java, SAP, DB2 and others.
  • Centrify Priviege Service extends Centrify PIM capabilities providing Shared Account Password Management, Privilege Session Management for systems, devices, databases, directories and more.
  • Hadoop:  If you have a Hadoop deployment, you can accelerate it by leveraging Active Directory and Centrify. 


Tip #10:  Ask us for new capabilities or improvements

Tech companies are only as good as their ability to deliver capabilities required by their customers.  Let your voice be heard in the community or in the Idea Exchange;  feel free to tell us what's next. 



At Centrify we focus on helping organizations secure their assets by focusing on the new perimeter:  Identity.  Our solutions provide operational efficiencies given that they reuse existing infrastructure (e.g. Active Directory) or simply eliminate complexities. 

A Better Way to Sudo – Part 1

By Centrify Contributor II ‎12-31-2015 10:30 AM

Part 1 - Using Sudoers to understand DirectAuthorize

In this first installment of the "A better way to sudo" series we’ll discuss the key gaps in “native” sudoers we hear from customers and why you should consider taking advantage of DirectAuthorize. Next, we’ll compare how how UNIX users interact in the UNIX environment through “dzdo” (Centrify’s enhanced implementation of sudo).  And then we'll use sudoers as a frame-of-reference to introduce the DirectAuthorize policy model.


Su Información Es Muy Importante! No De Papaya!

By Centrify on ‎12-21-2015 02:57 PM - last edited ‎12-21-2015 03:06 PM

Proteger la información de su compañia ante un ataque o robo de datos puede lograrse fácilmente con un poco de malicia y algunas herramientas. Usted debe estar preparado!


Showing results for 
Search instead for 
Do you mean 

Community Control Panel