How to configure the integration between Infrastructure Service (Auditing and Monitoring Service) and Splunk

Part2 - Integration between Infrastructure Service (Auditing and Monitoring Service) and Splunk


The configuration of a profile will be made to start the recordings of the sessions from the elevation of privileges and the integration will be made with splunk so that the auditing sessions can be viewed directly from the Splunk Portal.


Como configurar la integración entre Infrastructure Service (Auditing and Monitoring Service) y Splunk

Parte2 - Configuración de integración entre Infrastructure Service (Auditing and Monitoring Service) y Splunk

Se realizará la configuración de un perfil para iniciar las grabaciones de las sesiones a partir de la elevación de privilegios y se realizará la integración con splunk de forma que se puedan visualizar las sesiones de auditoria directamente desde el Portal de Splunk.

As customers move more and more to the cloud, many customers are leveraging AWS Workspaces as a Desktop as a Service Solution (DaaS) to provide end users access to corporate resources at any time from any where.  Given Workspaces are available to anyone, from anywhere, a key consideration to moving to AWS Workspaces, is of course Security. 


AWS Workspaces can be configured to require Multi-Factor Authentication (MFA) to add a layer of protection to a user name and password (the first “factor”) by requiring users to enter an authentication code (the second factor), which can be provided by a virtual or hardware MFA solution.


There are two ways to do this.  


Option 1) Use Centrify Endpoint Services.  @Robertson in this article covered how to use the Centrify agent to enforce strong workspace level security with Centrify's Endpoint Services solution to deliver:

  • Access control using Centrify Zone technology
  • Strong Authentication with MFA at login, screen lockout or remote desktop
  • Privilege Elevation for application or administrative desktop

This is the most secure option.


Option 2) Use Centrify's MFA service with AWS Radius support to require MFA before accessing AWS Workspaces


In this howto, we will focus on option 2.  





In this blog post we outline how you can enroll a new Windows Server system (on prem or IaaS) to Centrify Infrastructure Services.  This lab entry covers:

  • Enroll a Windows system in Infrastructure Service
  • Apply local settings, policy or permissions
  • Add the Windows instance to a system set.

We'll illustrate with Amazon AWS but the building-blocks can be used on premises or with any other IaaS provider like Microsoft's Azure or Google's GCP.


Use this blog post to learn how to deploy the Centrify Agent for Windows™ automatically with Windows cloud instances.  Learn how to:

  • Deploy the software
  • Automatically configure it for Zoneless MFA (Console, RDP and screen unlock)
  • Audit Trail

We'll illustrate with Amazon AWS.  This article can be combined with other building blocks in the series.


In this blog post we outline how you can enroll a new Windows Server system (on prem or IaaS) to Centrify Infrastructure Services and secure a local account credential password.  This lab entry covers:

  • Enroll a Windows system in Infrastructure Service
  • Apply local settings, policy or permissions
  • Add the Windows instance to a system set.
  • Create a local user and secure the credential password in Infrastructure Service

We'll illustrate with Amazon AWS but the building-blocks can be used on premises or with any other IaaS provider like Microsoft's Azure or Google's GCP.


The Centrify Agent for Windows provides organizations with the ability to secure Windows systems.  This article's goal is to introduce the basic information (pre-requisites, communications), deployment scenarios and tools available for each deployment option.  The next articles in the series focus on specialized topics or use cases.


As part of the security toolbox, we must deal with shared credentials, more specifically passwords.  Many of you know how Infrastructure Services can secure credentials, however, a lot of work is going on to enhance the DevOps or automation use cases.  In this article we'll explore the options available to retrieve passwords from the CLI using Centrify, how it works, how it's secured and how programs or scripts to retrieve them.

Using shared passwords in CLI scenarios while maintaining assurance

Passwords have been hard to get rid of, unfortunately, even with old technologies like Kerberos and PKI we must accommodate for the need to securely retrieve credentials.  However, at the same time we need to maintain assurance and enforce principles like:

  • Try to eliminate passwords
  • Limit lateral movement
  • Just in time/just enough access/privileges
  • Identity Assurance
  • Monitoring and Auditing
  • Policy enforcement, etc

The maturity model illustrates this best:

maturity model.png 

Eliminate Passwords

Centrify eliminates passwords in this use case by relying on PKI credentials; the process happens during enrollment when a system is onboarded by an authorized party.  The enrollment process looks like this:


Each system is represented by a service account in Centrify Infrastructure Service.  Please note that in order to modify the PKI settings on a system, you must have administrative rights (you you require privileged access on the client side), plus you must have either an enrollment code or a user credential of a user that can enroll a system into Centrify Infrastructure Services. 


In Linux, this is implemented with the cenroll command.  If ther's a manual enrollment, we also ask for MFA based on authentication profiles like here (enrolls a system called centos7 to a vault.centrify.vms using the admin@opie.demo credential and enables all features):

sudo cenroll --tenant vault.centrify.vms --user admin@opie.demo 
--verbose --features all --agentauth identity-broker-users
--name centos7 --address centos7.centrify.vms


If an Enrollment code is available, you can use it (the most common way of doing this, especially for automation), here's how it looks on Windows, with a code (enrolls a system called member-vault using an enrollment code):

Enroll-CIPSystem -EnrollCode "THISIS-WHERE-YOUR-CODE-GOES"  
-FQDN 'member.centrify.vms' -ResourceName 'member-vault'
-Endpoint 'https://vault.centrify.vms'


Access Control, Entitlements and Visibility
Centrify relies heavily on role-based access, but this is an interesting use case because it's highly-related to automation.  In this scenario, most likely a system will be built, and as part of the on-boarding it will automatically enroll to the Centrify platform.  Centrify includes a built-in group called:  Centrify Agent Computers;  by default, this group has visibility to systems, domains and databases.


As a best practice, don't overload the Centrify Agent Computers built-in group.  Just use it for visibility purposes.  Create sets and other roles, and leverage those instead.


For accounts, there are several entitlements

This means that you need View+Check out at the account level to check out a password.  This is a mechanism for least access and limiting lateral movement.


Policy Enforcement and Monitoring

The most common password checkout policies (like multi-checkout or lifetime) are geared towards interactive use, but for machine communications, Centrify offers the ability to override the checkout lifetime settings at the account level.



A great policy that can be implemented is the use of internal/external, datetime or even Risk.  This can be applied at the account level.



Because a compromised system, although with limited access is still a potential "stakeout" point, monitoring service account checkouts outside the applicable time or at a rate that is out of the blue, the monitoring and alerting capabilites of CIP provide several tools like:  Dashboards, Reports or the ability to send events to a security operations or SIEM tool.



Deployment Utilities

  • Enrollment codes:  allow Centrify clients to enroll the platform automatically.  The benefit of codes is that you can add restrictions (like how many times or from which networks they can be used) or organizational options like sets or RBAC.
  • Sets:  Sets are collections of objects in CPS; they allow for dynamic or static membership as well as controlling permissions.
  • Packages:  The CLI toolkits are delivered as part of the Centrify clients for Linux or Windows.
  • Policy overrides:  Password lifetime overrides allow for different policies at the parent or account levels.  This is useful when you need policies for human beings vs. machines.



The Centrify Agent for Linux, leverages the cgetaccount command (checking out the opieadmin local account password from as system called engcen6 for 5 minutes).


Here's more info about cgetaccount.

Here's how it looks in PowerShell  (checking out the sa SQL server account from the database enterprise for 2 minutes)



Note that these examples are interactive checkouts.  Ideally, a script or program would call this command to retrieve the password string and use it or assign it to a variable; as you can also see, the option to specify the checkout lifetime is available.


Developer Portal

The solutions above address the challenge from the point of view of an infrastructure lead specifically focusing on systems.  Although in this article we don't cover this in depth, it should be known that everything in the Centrify Identity Platform uses REST APIs.


The Developer Reference pages here:  are another resource in your arsenal.


The resource management API, specifically the /Servermanage/CheckoutPassword API provides the capability of password checkouts.  This reference provides the folllowing code samples:

  • cURL
  • Node JS
  • Ruby
  • JavaScript
  • Python
  • PHP
  • Java
  • C# and 
  • Go




PowerShell Sample Pages in GitHub

Many of the CIP methods are already available in PowerShell using the samples posted in Github.



This is an area of a lot of interest for Centrify.  Stay tuned.

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:

Applicable Versions:  Fuji, Geneva, Helsinki, Istanbul (July 2017).



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 third article in the series.  We have covered  ServiceNow federation using Multi-provider SSO, setting-up automatic provisioning with the Centrify Identity Service App and in this post we'll discuss the steps to set up Centrify App Access ServiceNow to add workflow and approvals to Centrify Identity Service applications.


Centrify's Access Request vs. ServiceNow Workflow

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 Centrify Identity Service Instance with some published apps assigned to roles
  • 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 application?
    Depending on the application(s) in question you may have a single group or multiple groups approve.  Or have approval groups per app as well.
  • How will the workflow be designed?
    This topic is very organization-dependent.  Some organizations may chose to have automatic approvals for simple apps and human approvals when the apps require a license or will add access to sensitive data.
  • Have you identified a Default Approval Group in ServiceNow?
    If you chose to have a single group approve access to all apps.
  • Have you mapped all Apps to ServiceNow groups for the purposes of approval?
    E.g. the "twitter" app is approved by the Social Media group;  the "O365"  app is approved by the manager and then the security department.
  • 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 "Role Management" and "Application Management" rights, 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
  • Create an Identity Service role with the minimum rights
  • Create an Identity Service Policy to allow user/password login
  • Download and Install Centrify App Access from the ServiceNow App Store
  • Configure Centrify App Access

Create an Identity Service user

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 two rights:  Application Management and Role Management.   This is to be able to modify role membership and application attributes.


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 an Identity Service role with the minimum rights

When you create the role, grant the two rights illustrated below and add the previously-created user to this role.



Create an Identity Service Policy to allow user/password login

This step may require you to create an Authentication profile that only asks for password (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 Identity Service 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 Identity Service App from the ServiceNow App Store

  1. Go to the ServiceNow app store and search for Centrify.
  2. Click on Centrify App Access
  3. Click "Get" to make the Centrify Identity Service 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 Centrify App Access

There are three configuration tasks required.  Properties, API Sync and Applications.  The third category is only needed if you are using individual groups as approvers for each app.
  1. In the application pane (left) navigate to Centrify App Access > Properties.  Populate these three fields
    Centrify Cloud Tenant URL:  the URL for your identity service tenant.  (e.g.
    Centrify Cloud Service Account: the account you created in previous steps
    Centrify Cloud Service Account Password:  the strong password you created for the user
  2. Default Approval Group (Optional):  now you have a decision to make based on the planning above.  Populate the "Default Approval Group" if you decided to use a single ServiceNow group to approve all application 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 App Access > 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 CIS Apps and Roles available with ServiceNow.  Alternatively, you can go to the Applications and Roles sections and press the Sync Now button.

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 "Amazon as root" app will be approved by the Software 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. First, you must verify that the roles and applications have been properly populated.


For example, in my scenario I chose to have independent approval groups.  My requester (Stewie) will request the app and this request has to be approved by ITIL user.



Once the request is approved (and the underlying task) the app will perform the provisioning of the role that grants access to the application and the icon will show up automatically.


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 App Access approvals section.




This is the the second lab in the series around Strong Authentication.  In the previous lab we focused on StrongAuth for Windows access and privilege elevation with YubiKey.

We will be focusing on UNIX/Linux system access leveraging strong authentication to Windows (or Mac) systems via smart card or YubiKey.  Centrify Server suite allows definitions of roles that only allow non-password authentication to be enforced.   YubiKeys are full-fledged personal identity verification (PIV) cards that work very well with AD and Certificate Services.



  • Recent advanced threats leverage the collection of passwords and poor security practices to exploit systems.
  • The variability (heterogeneity) of systems (Windows, UNIX, Linux, Macs) poses a big challenge for organizations
  • The proliferation of "best of breed" solutions promotes IT fragmentation and limits organizational flexibility.
  • The "jumpbox" or proxy approach combined with additional controls like workflow can help as long as connections are centralized, however many organizations are getting audit comments due to circunvention of these mechanisms.
  • Although there are different multifactor providers in the market and most of them provide Pluggable Authentication Modules for their solutions, the implementation requires a high-degree of expertise and translating the capability to hundreds or thousands of servers with heterogeneous OSs can be quite complex.


Although Centrify can accommodate the "jump box and shared account" model using Centrify Privilege Service, organizations should complement their security strategy with the least access model:

  • Users shall only access the systems they need to based on business need-to-know with strong authentication
  • Users shall be limited to the minimum privileges required for their functions:  this is accomplished by providing users roles with the rights that they need.
  • Rights shall be assigned and limited to the business function with a privilege elevation mechanism (e.g. sudo) that has the flexibility to provide strong authentication.
  • In sensitive systems, access and privilege elevation shall be supplemented with session capture and replay.
  • Active Directory and Centrify provide a stack that can secure systems and eliminates complexity across the different UNIX/Linux platforms

Lab Goals

  • Limit privileged users to a subset of UNIX/Linux systems based on their needs (AD and Centrify Zones enable this)
  • Require strong authentication for local or remote (SSH) access  (this is enabled by Centrify DirectAuthorize)
  • Require strong authentication on privilege elevation if needed (OTP, SMS, E-mail, phonefactor, etc)
  • Reproduce privileged sessions (session capture, transcription, replay).

What you'll need

  • Active Directory with Certificate Services
  • A domain joined member server with Centrify Server Suite 2016 (DirectControl)
  • One or two UNIX/Linux systems with Centrify DirectControl and Centrify-Enhanced OpenSSH
    Because we will be relying on SSO, Centrify OpenSSH comes compiled with Centrify methods that simplify the process in simple and complex AD environments.
  • For SSO to work, the system has to be resolvable by name (shortname or FQDN) by the Kerberized clients.
  • SSH client that supports SSO; e.g. stock PuTTY (GSSAPI) or Centrify-enhanced (Kerberos)
  • Access to Centrify Standard Edition (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 or use the Announcement Post.


Scenario Description: 

We will use the Yubikey/Smart Card with the Certificate provisioned to the user in the base lab.  With Centrify Access Manager, we will create a role that allows her to access a system (locally and via SSH) and we will prove:

  • That the user can only log in to her Windows station with her Smart Card/YubiKey
  • That the user cannot sign-in to UNIX/Linux system locally or remotely (via SSH) with a password
  • That the user is only allowed to log in remotely via SSH to UNIX/Linux systems  via SSO (Kerberos or GSSAPI)
  • That these rights can be assigned to groups of systems, or groups of users in a temporary or permanent basis
  • Minimal to zero configuration at the system level.  Once the system is joined to AD, the security measures should just work.

Note:  We will not focus on privilege elevation.  We have covered this exhaustively, including with MFA/2FA in previous labs.



Centrify Setup

In this instance we are setting up a Web Admin role that contains the pre-defined "login-all" PAM right.  We are not breaking down the rights to prove that we can stop the user from logging in via console or via SSH with a password. 

The privileged user assigned the role must have authenticated with her YubiKey or SmartCard to obtain a Kerberos TGT from Active Directory, subsequently, Centrify DirectAuthorize will be in charge of denying access to the user if they don't use SSO for access (via Kerberos or GSSAPI).  All we're going to need is a zone and a role. 


To set up using PowerShell

Import-Module ActiveDirectory
Import-Module Centrify.DirectControl.PowerShell

$user = Get-ADUser -Identity Maggie.Simpson  # substitute for your test user
$cont = "cn=zones,ou=unix,dc=centrify,dc=vms"  # substitute for your container DN
$zone = New-CdmZone -Name "Yubikey-Demo" -Container $cont

$cmd1 = New-CdmCommandRight -Zone $zone -Name "Edit http config file" -Pattern "vi /etc/httpd/conf/httpd.conf" -Authentication none
$cmd2 = New-CdmCommandRight -Zone $zone -Name "Httpd service control" -Pattern "service httpd*"
$cmd3 = Get-CdmPamRight -Zone $zone -Name "login-all"

$role = New-CdmRole -Zone $zone -Name "UNIX Webadmin - StrongAuth" -UnixSysRights ssologin, nondzsh, visible

Add-CdmCommandRight -Right $cmd1 –Role $role
Add-CdmCommandRight -Right $cmd2 –Role $role
Add-CdmPamRight  -Right $cmd3 –Role $role

New-CdmUserProfile -Zone $zone –User $user –login $user.SamAccountName -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmRoleAssignment -Zone $zone -Role $role -TrusteeType ADUser -ADTrustee $user | Out-Null

To perform the steps for the script above manually

Create, Configure and Assign the Demo role

 In Access Manager > Open they Yubikey-Demo zone > Authorization > Right Click Role Definitions > Select Add Role

  1. Name:  UNIX WebAdmin - StrongAuth
    System Rights:
    - Non-password (SSO) login is allowed  (checked)
    - Login with non-Restricted shell (checked)
    Access Manager - role Strong Auth.png
  2. Create two UNIX commands.  
    Since this will be our "Web Admin" we'll allow the role to manipulate the httpd daemon and edit the config file for the Apache server.  The commands are:
    Glob expression vi /etc/httpd/conf/httpd.conf from the standard user path /usr/bin no reauthentication required.
    Glob expression service httpd* from the standard system path /usr/sbin no reauthentication required.
    Access Manager - role command.png
  3. Add the rights to the role.  Right click the "UNIX WebAdmin - StrongAuth"  role and select "Add Right"
    Access Manager - role command.png
  4. The role is ready to be assigned.  Now press OK and right-click the Authorization > Role Assignments > Select Assign Role
  5. Press the Add AD account > type the name of your test user, select it and press OK.
    Access Manager - assigned.png
    Note: This is a permanent direct assignment to a user principal at the zone level.  This is not the best practice, typically you grant role assignments temporarily (for attestation), in a subset of systems and to AD groups for better administration.

 Install DirectControl and join the system to the Centrify Zone

  1. Use your preferred software distribution method to copy the Centrify software
    In my case I already have a local repo for RHEL and derivatives.  (Read how to set up here)
  2. Log in to your UNIX/Linux system and use your favorite package manager to install Centrify DirectControl and Centrify-enhanced OpenSSH
    $ sudo yum install CentrifyDC CentrifyDC-openssh
      CentrifyDC.x86_64 0:5.3.0-213   CentrifyDC-openssh.x86_64 0:7.1p1-
  3. Now Join the Centrify zone and you'll be ready for testing.  Use the adjoin command and an authorized user:
    $ sudo adjoin -z Yubikey-Demo -c "ou=servers,ou=unix" -u dwirth centrify.vms
    [sudo] password for centrifying:
    dwirth@CENTRIFY.VMS's password:
    Using domain controller: dc.centrify.vms writable=true
    Join to domain:centrify.vms, zone:Yubikey-Demo successful
    Centrify DirectControl started.
  4. If your system was not resolvable by Windows DNS, you can use the addns command to register automatically with dynamic updates (if your DNS zone allows):
    $ sudo /usr/sbin/addns --update --machine
    Updating both HOST and PTR record for: centos67.centrify.vms
    Deleting old reverse lookup records for centos67.centrify.vms on
    No old reverse records deleted because no host records found for centos67.centrify.vms on
  5. Verify that your users are correctly UNIX-enabled and with the expected rights (use adquery user and dzinfo)
    $ adquery user maggie.simpson
    maggie.simpson:x:1040191002:1040191002:Maggie Simpson:/home/maggie.simpson:/bin/bash
    $ sudo  dzinfo maggie.simpson --roles
    User: maggie.simpson
    Forced into restricted environment: No
    Centrify Cloud Authentication: Supported
      Role Name        Avail Restricted Env
      ---------------  ----- --------------
      UNIX Webadmin -  Yes   None
        Effective rights:
            Non password login
            Allow normal shell
        Centrify Cloud Authentication:
            Not Required
        Audit level:
        Always permit login:
    All set on the Centrify side.

Configure your Test user for Smart Card Authentication

  1. In ADUC, find and double-click the test user.
  2. Account Tab > Account Options > Check the box for "Smart Card is required for interactive logon"
  3. Press OK. You are ready to start testing.


Test Plan:

  1. Try to access the system with any other AD user than test user - expected result:  Access Denied
    This is because users need to be explicitly be granted access a UNIX identity and a Centrify role in the zone for the computer.
    login as: dwirth
    WARNING: This is a PRIVATE system exclusively for Centrify demos
    Your actions will be monitored and recorded.
    Using keyboard-interactive authentication.
    Access denied
    Using keyboard-interactive authentication.

  2. Try to access the system with your test user (Maggie) with her password (Console or SSH) - expected result:  Access Denied
    This is because the test user was defined with "Smart card required for interactive logon"
    login as: maggie.simpson
    WARNING: This is a PRIVATE system exclusively for Centrify demos
    Your actions will be monitored and recorded.
    Using keyboard-interactive authentication.
    Demo Password:
    Using keyboard-interactive authentication.
    Account cannot be accessed at this time.
    Please contact your system administrator.
  3. Log in to Windows system (you are forced to smartcard login) - Launch PuTTY (configured for SSO)
    Expected result:  Access Granted
    Yubikey UnIX - success.png


Other considerations:

  • When forcing stong authentication, you must have a plan for other shared non-human accounts.  This is where Centrify Privilege Service shines.
  • Don't underestimate the need for good process around the lifecycle of PKI and smart cards.  PKI is serious business.


This is the first lab in the series around Strong Authentication (series link).  We will be focusing on Windows systems and providing strong authentication for privileged users using Yubikeys.   Yubikeys are full-fledged personal identity verification (PIV) cards that work very well with Active Directory Certificate Services and Centrify software for UNIX, Linux and Windows.


The challenges

  • The Windows security model lends itself for organizations to grant additional privileges to users by way of the local Administrators group.  In Active Directory environments organizations struggle with excessive memberships on privileged groups like Domain Admins.
  • In Active Directory, a common mitigation strategy is to provision each privileged user an "administrative" account (e.g. joe/joe-a).  This strategy can be supplemented by having the "-a" account password stored securely.
  • Unfortunately, advanced attacks like password mining, pass-the-hash and others have become more ubiquitous, this makes a member of a privileged group ("-a" or not) more susceptible to exposure.
  • The "dual account" model is often paired with PSM (jumpbox) to provide session brokering and recording.  Unfortunately, this model can be circumvented by bypassing the jumpbox, and since the "-a" account is very powerful, that means that the privileged user can go anywhere.

The opportunity

Although Centrify can accommodate the "dual account" model using Centrify Privilege Service, ideally organizations would implement the least privilege model:

  • Users shall only access the systems they need to based on business need-to-know with strong authentication
  • Users shall be limited to the minimum privileges required for their functions:  this is accomplished by providing users roles with the rights that they need.
  • Rights shall be assigned in the context of applications, desktops and network rights.  Strong authentication shall be required when using privilege elevation.
  • In sensitive systems, access and privilege elevation shall be supplemented with session capture and replay.

Lab Goals

  • Limit privileged users to a subset of Windows systems based on their needs (AD and Centrify Zones enable this)
  • Require strong authentication for console or remote (RDP) access  (this is supported natively by Windows)
  • Require strong authentication on Privilege Elevation (applications/desktops)  (DirectAuthorize is Smart Card ready)
  • Reproduce privileged sessions (session capture, transcription, replay).

What you'll need

  • Active Directory with Certificate Services
  • A domain joined member server with Centrify Server Suite 2016
  • Access to Centrify Standard Edition (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 or use the Announcement Post.


Scenario Description: 

We'll use the smart card user certificate provisioned to your test user's Yubikey.  In Active Directory we'll require smart card authentication for the user (this also be implemented in a subset of systems using Group Policy).

We will grant the test user a Centrify DirectAuthorize role that allows her to:

  • Run Disk Management as the local administrator and will require strong authentication to be launched
  • Use an administrative desktop  (as local administrator) and requires strong authentication to be launched



Complete the Base Lab Setup

The base lab set up is in the announcement post:


Centrify Setup for Windows Access and Privilege Elevation

To set up using PowerShell

Import-Module ActiveDirectory
Import-Module Centrify.DirectControl.PowerShell
$user = Get-ADUser -Identity Lisa.Simpson # substitute for your user
$cont = "cn=zones,ou=unix,dc=centrify,dc=vms" # substitute for your container DN
$zone = New-CdmZone -Name "Yubikey-Demo" -Container $cont

$criteria1 = New-CdmMatchCriteria -Description "Disk Management - Direct" -FileType "msc" -FileName "diskmgmt.msc" -Argument " "   -Path "C:\Windows\System32\"
$criteria2 = New-CdmMatchCriteria -Description "Disk Management - MMC" -FileType "exe" -FileName "mmc.exe" -Argument "C:\Windows\system32\diskmgmt.msc"  -Path "C:\Windows\System32\"
$cmd1 = New-CdmApplicationRight -Zone $zone -Name "Disk Management Combo" -MatchCriteria @($criteria1, $criteria2) -RunasSelfGroups "Builtin\Administrators" -RequirePassword $true
$desktop1 = New-CdmDesktopRight -Zone $zone -Name "Admin Desktop" -RunasSelfGroups "Builtin\Administrators" -RequirePassword $true

$role = New-CdmRole -Zone $zone -Name "Demo Role" -WinSysRights remote
Add-CdmApplicationRight -Right $cmd1 -Role $role
Add-CdmDesktopRight -Right $desktop1 -Role $role

New-CdmRoleAssignment -Zone $zone -Role $role -TrusteeType ADUser -ADTrustee $user | Out-Null

To perform the steps for the script above manually

Create the Zone

  1. Open Access Manager and right-click Zones > Create New Zone
    Name:  Yubikey-Demo
    Container:  Browse to your container.
  2. Press Next and Finish

Create the Disk Management Application

  1. Launch Disk Management (e.g. Start > Run > diskmgmt.msc)
  2. Open Access Manager > Open they Yubikey-Demo zone > Authorization > Windows Right Definitions > Right Click Applications > New Windows Application
    Name: Disk Management ComboMatch Criteria:  Press Add > Import Process and Select Disk Management and Press OK
    Press Add > Import File > Browse to c:\Windows\System32 and select diskmgmt.msc, press OK.
    This will add another way to launch the application.
    RunAs:  Self with added group privileges > Press Add Builtin Groups > Select Administrators, press OK and check the box for Authentication Required and press OK.

Create the Admin Desktop Right

  1. In Access Manager > Open they Yubikey-Demo zone > Authorization > Windows Right Definitions > Right Click Desktops > New Windows Desktop
    Name: Admin Desktop
    Runas:  Press Add Builtin Groups > Select Administrators, press OK and check the box for Authentication Required and press OK.

Create, Configure and Assign the Demo role

 In Access Manager > Open they Yubikey-Demo zone > Authorization > Right Click Role Definitions > Select Add Role

  1. Name:  Demo Role
    System Rights:  "Remote Login is allowed"  <  this will allow the user only to access via RDP
  2. Press OK and right-click the newly created role and select "Add Right"
    yubikey-win-role add right.png
  3. The role is ready to be assigned.  Now press OK and right-click the Authorization > Role Assignments > Select Assign Role
  4. Press the Add AD account > type the name of your test user, select it and press OK.
    Note: This is a permanent direct assignment to a user principal at the zone level.  This is not the best practice, typically you grant role assignments temporarily (for attestation), in a subset of systems and to AD groups for better administration.

 Install DirectAuthorize for Windows and join the system to the Centrify Zone

  1. In your domain-joined test systems, browse to the path for the Centrify Standard Edition software.
  2. Go to  Agent > and Run "Centrify Windows Agent.exe"
  3. Follow the Wizard, you will select the "Access" components.  If you have DirectAudit, also select Audit.
  4. When the installation ends, you need to configure the client to join your desired zone.
  5. The system will ask to reboot when complete.

Important Notes:

  • When a Windows system is added to the Centrify Zone, the security model changes.
  • In order to access a Centrified Windows system, users must be explicitly granted logon rights.  This means that even Domain Admins won't be able to access those sytsems.
  • The type of access is based on the Windows setup (Remote/Log on Locally) and the Centrify Role definition (Console/Remote)
  • When adding your first system to a zone, you will have an opportunity to explicitly add Domain Admins, otherwise you may completely lock the system

Configure your Test user for Smart Card Authentication

  1. In ADUC, find and double-click the test user.
  2. Account Tab > Account Options > Check the box for "Smart Card is required for interactive logon"
  3. Press OK. You are ready to start testing.


Test Plan:

  1. Try to access the system with any other AD user than test user - expected result:  Access Denied
    This is because users need to be explicitly be granted access using a Centrify role.
  2. Try to access the system with Lisa with her password - expected result:  Access Denied
    This is because the test user was defined with "Smart card required for interactive logon"
  3. Try to access the system via the console with Smart Card - expected result:  Access Denied
    This is because the role created in Centrify does not grant console login.
  4. Try to access the system via RDP with smart card PIN - expected result:  Access Granted
  5. Try to run application "disk management" normally - expected result:  Error: "You don't have access rights to logical Disk Manager on [Server]"
    This is because when the user launches the app, they are doing so without any privileges.
  6. Launching App or Privileged Desktop:
    Right click App > Run with Privilege >  Challenge with Password - Expected result:  Access Denied
    Right click App > Run with Privilege >  Challenge with smart card PIN- Expected result:  Access Granted

 Video Playlist

Announcing a new series!!!


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


Here are the series links:

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

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

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



About the Series

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


Strong Authentication (PKI) Smart Card / Yubikey

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

Strong Authentication for Windows Privilege Elevation

  • Applications
  • Desktops

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



Strong Authentication (Smartcard/Yubikey) & OATH OTP access

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

 Here's a quick overview/demo


Lab - Base Setup

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


What you'll need

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

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


Create Test Users and AD Group

On the member server

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

Certificate Services

Modify the Smart Card User template

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

Publish the Newly-Created Template

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

Provision the Smart Card User Certificate into your Yubikey

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


Lab Verification Video


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


This is the fourth 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 secure Amazon Identity and Access Management (IAM)  by leveraging Centrify Identity Service and your on-premises Active Directory.

In this article we'll discuss how to use Centrify Server Suite to secure your AWS Server instances by leveraging Active Directory (in AWS, on-premises or a mixed environment).  The drivers behind this are:

  • To continue to leverage Active Directory as the source of identity and privileges
  • To eliminate the reliance on SSH keys or fragmented identities
  • To provide a tried and true privileged elevation mechanism (sudo) without the inconveniences of sudoers files
  • To be able to deploy additional controls such as time-fencing and multi-factor authentication for linux
  • To be able to quickly attest who can access systems, their roles, privileges and how the privileges were granted
  • To enforce the principle of separation of duties

Active Directory and AWS

The prescriptions outlined on this article depend on how your Active Directory AWS strategy is designed.  It's even possible that there's no AD in your AWS deployment today, in that case you'd benefit from looking at the next entry in the series (that focuses on session brokering and password management).  Assuming you are using AD in AWS, here are some of the models we've seen with our customers:


AWS-CSS-connected model.png

The Connected Model

This model implements some degree of permanent connectivity between AWS and your on-premises infrastructure (e.g. Amazon DirectConnnect, Firewall ACLs, VPNs/Tunneling, etc); the end result in the Active Directory layer is that the following models can be implemented:

  • Account-resource model:  With accounts living on-premises and a resource domain existing in AWS (for example, with a one-way trust).
  • Extended model:  Domain controllers extend to AWS (writable or read-only).

The connected model allows for organizations to extend their AD and Centrify deployments and treat AWS as another site.  As far as Centrify goes, it's like adding another branch or site.


The implications of this model are permanent connectivity (and costs), plus the need to implement the network and security components prior to the AWS deployment.  Once it is in place, the administration is simplified.


 AWS-CSS-disconnected model.png

The Disconnected Model

This model uses the opposite approach.  It treats AWS as a disconnected entity.  Users connect to AWS through the Internet.  Directory services are separated.


In this scenario, independent AD forests exist on premise and in AWS.  The benefits of this model are:

  • Faster-to-production because there's no need to wait for dedicated connectivity to be set up.
  • No need to architect a security model around AD.

The obvious drawback of this model is dual administration.


Commonalities and Customer Inquiries

When communicating with prospects and customers on the field, these are the commonalities that I have observed:


  • They want to extend the Centrify Server Suite benefits to these environments
  • They have questions about their AD architecture (the two models below hint at how things would be designed and managed)
  • They have questions about the instance lifecycle:
    • How can I automate Centrify client deployment?
    • How can I automate AD joins when systems are launched?
    • How can I automate AD leaves when systems are terminated?
  • They have questions about management frameworks  (e.g. Scripts, DevOps, Amazon OpsWorks)
  • They want to automate privileged operation leveraging PowerShell
  • They want to deploy additional controls (like multifactor authentication or time-bounding)
  • They have miscellaneous questions about pre-validation and the use of DirectAudit (session capture and replay)


Fortunately the building-blocks for all the questions asked above are scattered in the Tech Blogs and the Centrify Knowledgebase.  Instead of using the Plan-Do-Check-Adjust model in this article (because of the combination of scenarios), I will speak about each bullet-point individually.


Extending Centrify Server Suite to Amazon Web Services

This one is straightforward.  CSS requires Active Directory and there are several avenues that you can use.  This all depends on the access and privilege model to be implemented. 

  • If status-quo will be maintained and the same user population retains the same rights to AWS
    • You may only need to create a child zone or a computer role in your existing zone structure.
    • Active Directory design principles are maintained: 
      - AD Sites and Services (subnets/sites) need to be created and maintained. 
      - Global Catalog location needs to be accounted for, especially if Universal or nested groups are used.
    • If RODCs are in use, adjust your instance provisioning model based on the prescriptions of the Server Suite planning guide (pg. 205).
  • If there's a different access model being implemented
    • If there will be a completely new governance model within the same forest, then a parallel zone may need to be created and delegated to the proper group.
    • If a brand-new forest with a 1-way trust is created, then a zone in the resource domain will have to be created and principals from the trusted domain have to be added to provisioning and role-granting groups.

EC2 Instance Lifecycle

The EC2 lifecycle (Launch, Stop, Terminate) has implications depending on the use cases.  In permanent environments, systems are expected to be there for a long time;  in elastic environments systems may be alive for a few weeks while an app is tested, or may be scaled-up or down depending on load or business seasonality.

Aspect that require planning include naming conventions, properly deprovisioning systems and using the analyze wizard to make sure things are tidy.  Some resources:

Deploying the Centrify Software and Joining (or leaving) AD automatically

Deployment depends on the approach.  I've seen customers that bake the software into their private AMIs (this allows for them to test and validate any corporate software) or I've seen the use of repositories and configuration management software.  The guidance here is consistent:  If you want the system to participate in your AD, you must align your hostname with your naming convention,  specify the domain name, and automate the AD join (using a krb5.conf file and a service account keytab).

Baking the software and utilities to an image makes things more predictable; however using a DevOps framework is the way of the future (given the testing orientation). 



This article shows how to create these building blocks: [HOWTO] Use Centrify Tools for Public/Private Cloud Automation Activities

The Termination sequence is relatively the same:  retrieve utility files, run kinit and instead of adjoin, run "adleave --remove" this will remove the computer from AD and Centrify, freeing-up the license.


DevOps Frameworks

Amazon AWS provides a great set of tools based on Chef (OpsWorks).  If you choose to use this framework, you need to have your recipes and underlying infrastructure in place (e.g. an APT/YUM repo, or Chef infrastructure) to host the dependencies.  If you are looking at the DirectControl, DirectAudit or CLI toolkit as an app, you have to sequence the triggering of the script based on your design (e.g. user-data, setup/configure/deploy/undeploy/shutdown). 


Here are some avenues:

User Data field:




These articles show the same sequence using Chef or Puppet:


AutoScaling, OpsWorks and Automation Resources


Automating Access and Privilege Operations with PowerShell

Amazon AWS provides a powerful toolset that has been implemented in PowerShell.  This is very aligned with Centrify's efforts (both Centrify Suite Standard and Enterprise edition provide PowerShell management tools). 


The subject of PowerShell is very broad, here are a few resources:


Securing Windows Servers in AWS

Some of you are also using Windows servers in AWS and ask us how we can help.  The windows security model has been challenged by modern threats like PtH and the dependency on high-privileged accounts (like Administrator) and groups (like Administrators and Domain Administrators).  Centrify DirectAuthorize provides a powerful mechanism to control access and privilege elevation.


This article goes to length to explain the process for Windows:


Automation: In Suite 2016, Centrify added the ability to join zones automatically with the dzjoin command.  This can be combined with the EC2Config tasks for your Windows based AWS systems.  The User's Guide for Windows describes dzjoin in detail.


Advanced Controls and Reporting

Depending on the data classification or risk profile of the systems hosted in AWS, organizations may want to deploy additional controls to provide the assurance that only authorized users are accessing these systems, in addition, these systems may be subject to attestation requirements just like on-premise systems.  We will explore other controls in part 5, however Centrify Standard Edition provides multi-factor authentication for access and privilege elevation as well as several mechanisms to obtain access data.


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


Note:  this is a companion article to the blog post titled: "[HOWTO] Orchestration Basics - Using a Chef recipe to deploy Centrify and join Active Directory";  these posts are relatively identical, the only difference is the tool.


In the field, we often get inquiries on deployment, governance or orchestration frameworks.  Common questions range from: how do I deploy the Centrify client?  or How do I establish an approval flow for the Access Control model that you facilitate? 

Sometimes we also hear these questions:  We use Ansible | Bladelogic | Chef | Puppet in on premise or with our IaaS (cloud) deployment, how would I go about deploying your product using those tools?

These are important questions, especially in the age of private/public clouds and elastic environments.  Some of you are adopting frameworks like OpenStack, Amazon AWS or Microsoft Azure that underneath use these toolsets.


At Centrify we have invested heavily through the years to make sure that the products "just work".  From a deployment perspective, we our messaging is consistent:

  • We always provide the native platform package
  • Our tools are all Kerberized  (ready for automation)
  • We also provide other tools like and Deployment manager that abstract the underlying OS package manager
  • The Centrify agent automatically maintains its configuration and the Kerberos configuration based on Active Directory, and it uses AD specs for Sites and Services, DC location, offline cache.
  • The configuration parameters can be managed by any tool, plus native Active Directory Group Policy.

In other words, Centrify software is easier to use in these scenarios than what the typical IT Infrastructure lead may think.


Disclaimers and Acknowledgements

  • This article provides a "quick basic configuration";  in a true deployment you have to account for high-availability, replication, security, package integrity, supported platforms, supported versions, change control, etc. 
  • All names, logos and trademarks used in this articles correspond to their existing owners.
  • We are not Puppet, Chef or Bladelogic subject-matter experts, hence the use of a stand-alone script or recipe. 
  • Puppet Master server/slaves/node architecture is outside the scope of this post
  • This would not be possible without my customers/prospects asking and the tutorials available online.  Some great resources:
    - Introduction to Puppet:
    - Willams' blog post "How to install Puppet in Stand-Alone mode on CentOS7"
    - Kudos to MaestroDev for the wget Puppet extension:

What is required?

  • An Active Directory domain
  • A Centrify zone (optional - if using Centrify in licensed mode/privilege management)
  • A Centrify zone and a Computer Role  (optional)
  • An Active Directory service account for joins and removals, plus a keytab for the account and a usable krb5.conf file.  Read this article if you want to know how to create the service account and obtain the keytab.
  • A RHEL-based system with enough storage for the Centrify RPM packages for each platform (or just for the subset you need to support).  This system has to be set up as a YUM repository, as described in the the original orchestration article.
  • A second RHEL-derivative system to install Puppet (see below), this system must have DNS settings configured correctly.

Note:  Although it's possible for you to follow this and put together a working prototype, I strongly-encourage that you really explore the concepts  of DevOps/infrastructure as code.  The whole philosophy promotes constant improvement, this means that if you expect this to be a "set it and forget it" solution, I advise that you realign your expectations.


Finally, By no means what's outlined here is ready for production.  Check out the reading list below. 


Example Diagram

Chef Blog - Diagram.png


Implementation Steps



The goal of this lab is to be able to deploy the Centrify bits in a RedHat, CentOS, Scientific or Oracle system in a consistent way.  Also, if you know what you're doing, you can extend this to other OSs, and platforms as well.


The 'core' process without checking for major dependencies or issues is to:

  1. Install Centrify DirectControl
  2. Authenticate against Active Directory with an account with minimal rights
  3. Join Active Directory

Building Blocks

  • YUM Repository with Centrify RPMs (detailed instructions here)
  • AD account + keytab (steps outlined in a previous post)
  • Usable krb5.conf:  You can copy this file from any Centrified system; however, depending on where you're onboarding the system, you want to edit the file only with the DCs that are reachable to the new system.


Make the krb5.conf and service account keytab available to your infrastructure

In the original article, we piggy-backed on the Apache webserver as the transport for our repository.  Now we're going to create another folder for utilities (utils for short) and copy the keytab and krb5.conf file.

If you prepared this for the Chef article, you can skip to Puppet installation.


  1. Create a folder under /var/www/html
    $ sudo mkdir /var/www/html/centrify/utils
  2. Copy the RPMs to the folder.
    $ cd /path/to/files
    $ sudo mv krb5.conf  /var/www/html/centrify/utils
    $ sudo mv ad-joiner.keytab  /var/www/html/centrify/utils
  3. Set the proper permissions in the folder
    chmod -R ugo+rX /var/www/html/centrify/utils
  4. Verify that the files are accessible via the web server (you may have to check the firewall settings)

Install Puppet and the wget Extension

  1. Add the Puppet repository (you must find the proper repository for your RHEL version, version 7 shown)
    $ sudo rpm -ivh
  2. Install the bits
    $ yum install puppet
  3. Make sure your system's DNS settings are up to date (yes, no "localsystem.localdomain")
    Can you ping your own system by name and FQDN?
    What is the output of the hostname command?
    Run this:
    facter | grep hostname
    facter | grep fqdn
    if the output isincorrect, you must edit the /etc/hosts and /etc/resolv.conf and speak to your DNS admin to set things straight
  4. Logout and log back in to verify the ruby path
    $  sudo puppet module install maestrodev-wget
    You should be ready to get going.

Create and test your stand-alone Puppet Script

To recap, the sequence to automate Installation and joins is as follows:

  1. Retrieve a usable krb5.conf file
  2. Retrieve the keytab of a valid service account with minimum rights to join systems to the target AD OU, to the target zone (if using in zone mode) and if adding to a Computer role, with rights to add to the target AD groups.
  3. Install the Centrify Package and use the kinit tool to obtain a TGT
  4. Run adjoin with the proper options.
  5. Perform cleanup


Here is the Non-idenpotent Puppet Script:


# This stand-alone recipe will install the Centrify Agent on RHEL derivatives, 
# joins Active Directory and places the system in a Computer Role
# Notes: This recipe is not idempotent (achieving this is up to you!)

include wget

# Variables for my environment (see blog post)
# domain is the most basic parameter to join Active Directory

$adname = "centrify.vms"  
# Notice that I could not use "domain" like in the Chef example.  
# That word seems to be reserved in Puppet # In Zone Mode (licensed with UNIX identity and Access Control) the zone # parameter corresponds is where the system will be placed. Not needed # if working in workstation or express mode. $zone = "Global" # OU is where your computer object will be placed in Active Directory # your ad-joiner account should be able to join systems to this container $ou = " ou=servers,ou=unix" # A Computer role is one of the ways to group systems and define access # control. A system may be a member of multiple computer roles. # E.g. a LAMP system may be accessible by Web Admins, Developers and # DBAs with different access rights and privileges. $crole = "App Servers" # nodes are the managed system in Puppet; in a true deployment you can # apply to individual systems or collections of systems. Since this is not # idempotent, you must specify the fqdn. node "your-system-fqdn" { # Centrify's utilities are Kerberized, this means that they will use the current # user's Kerberos TGT to attempt the transaction against AD. However, in a # virgin system, there are no working krb5.conf files, therefore kinit won't know # how to find a KDC to authenticate against. This is why we need a krb5.conf # file from a working system (or that points to a reachable Domain Controller), # in the previous blog entry, we piggy-backed on an Apache Web server to # serve those files (engcen6). wget::fetch {"download a working krb5.conf": source => 'http://engcen6.centrify.vms/centrify/utils/krb5.conf', destination => '/temp/krb5.conf', timeout => 0, verbose => true, nocheckcertificate => true, before => Exec["kinit"] } # The keytab corresponds to a service account that has the minimal rights, in # this case, the rights to write a computer object in the designated container # (ou), centrify zone and the AD group that contains the "App Servers"computer # role needless to say, you need to treat this file with care and if possible, # remove when complete. wget::fetch {"download the ad-joiner keytab file": source => 'http://engcen6.centrify.vms/centrify/utils/ad-joiner.keytab', destination => '/temp/ad-joiner.keytab', timeout => 0, verbose => true, nocheckcertificate => true, before => Exec["kinit"] } # We leverage Puppet to ensure the files are present. This will be used later # to guarantee proper sequencing. file {"ad-joiner.keytab": ensure => present, path => '/temp/ad-joiner.keytab' } file {"krb5.conf": ensure => present, path => '/temp/krb5.conf' } # In this command, we authenticate against AD with the keytab of our service # account. Note that we are using the usable krb5.conf file so kinit can reach # a KDC (domain controller). The end-result is that root (or sudo) user will # have a TGT and you don't need to put keys, hashes or passwords in your # script. The before/subscribe and require Puppet directives guarantee proper # sequencing. exec {"kinit": command => "/bin/env KRB5_CONFIG=/temp/krb5.conf /usr/share/centrifydc/kerberos/bin/kinit -kt /temp/ad-joiner.keytab ad-joiner", before => Exec["adjoin"], subscribe => [ File["/temp/ad-joiner.keytab"], File["/temp/krb5.conf"], ], require => Package["CentrifyDC"], } # In a pre-requiste blog entry, I outlined how to create a YUM repository for # RHEL and derivatives. This means that you need a yum or apt repo with # the Centrify packages. Puppet will simply make sure the package is present # notice the differences, I declared this after the previous directives, when # the package is a pre-requisite. package {"CentrifyDC": ensure => 'installed', } # Finally we run adjoin. At this point we are using the variables from my # environment. Although in doing so, we broke the 'idempotent principles, I'm # certain that Puppet experts can find ways to improve on this. exec { "adjoin": command => "/usr/sbin/adjoin -z $zone -c $ou -R \"$crole\" -V $adname", require => Package["CentrifyDC"] } # In the cleanup phase, we clear the TGT and delete the utility files # Although the keytab provides very specific limited AD rights, always make # a habit of cleaning-up. exec {'kdestroy': command => '/bin/env KRB5_CONFIG=/tmp/krb5.conf /usr/share/centrifydc/kerberos/bin/kdestroy', require => Exec['adjoin'], } exec {"/bin/rm -f /temp/*": require => Exec['kdestroy'], } } # End of Script



Verify the recipe

$ sudo puppet apply centrify-build.pp
Notice: Compiled catalog for engcen7.centrify.vms in environment production in 1.77 seconds
Info: Applying configuration version '1458157258'
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Package[CentrifyDC]/ensure: created
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[krb5.conf]/ensure: created
Info: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[krb5.conf]: Scheduling refresh of Exec[kinit]
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Wget::Fetch[download a working krb5.conf]/Exec[wget-download a working krb5.conf]/returns: executed successfully
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[ad-joiner.keytab]/ensure: created
Info: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[ad-joiner.keytab]: Scheduling refresh of Exec[kinit]
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Wget::Fetch[download the ad-joiner keytab file]/Exec[wget-download the ad-joiner keytab file]/returns: executed successfully
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[kinit]/returns: executed successfully
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[kinit]: Triggered 'refresh' from 2 events
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[adjoin]/returns: executed successfully
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[kdestroy]/returns: executed successfully
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[/bin/rm -f /temp/*]/returns: executed successfully
Notice: Finished catalog run in 38.32 seconds


Verification Video




There are absolutely many improvements that can be made.   Here are a few that come to mind (in no specific order):


  • Check for Perl:  CentrifyDC requires Perl 5.8 and up.
  • Chek for DC connectivity:  You can potentially check for connectivity to KDCs prior to attempting to authenticate.
  • Inspect the name of the system:  In keeping with AD Naming conventions, we should check for length and uniqueness in the forest prior to join.
  • Check if the system is already joined or in the desired zone/forest.
  • Inspect the IP/DNS configuration:  Maybe the TCP/IP and DNS config is not right.
  • Perform a Dynamic DNS update using addns:  After join, you can use addns to get the system registered with Microsoft DNS
  • Obtain Certificates with ADCert:  If the system is used for SSL communications, you can get the cert manually using adcert.
  • Manage centrifydc.conf:  There are some basic parameters that may not be manageable via GPO (e.g. DMZ) that can be managed from there.
  • New Information:  Centrify DirectControl can provide information to Puppetregarding the AD topology.
  • Add dependent packages:  LDAP Proxy or Centrify DirectAudit/DirectSecure come to mind.
  • Most importantly:  This requires a Puppet infrastructure.  Make it as idempotent as possible!



This is the third 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 secure the Amazon Root account.

In this article we'll discuss how Centrify can secure Amazon Identity and Access Management by leveraging Active Directory or any other supported Identity Source. 


About Amazon AWS Identity and Access Management (IAM)

For those who aren't familiar with Amazon IAM, it provides capabilities that allow organizations to centrally manage Users, Roles, Rights and Policies efficiently for all services (compute, storage, database, application) provided by the platform. 


Another Identity Silo
Each time a new infrastructure or application is introduced, it has the potential to create another identity silo, Amazon AWS is not the exception.  Large organizations often find themselves duplicating effort by managing their own enterprise directory (like AD) and also having to manage the directory out in the IaaS or SaaS provider.
Many of our customers and prospects due to timing of adoption or while developing cognitive knowledge, find themselves manually managing Amazon IAM.  The typical tasks include user creation, credential/password/key management, password resets, group/entitlement management and attestation. The basic IAM best practices are outlined when you log in to the IAM dashboard:




Once we adopt this "dual-management" we are promoting IT fragmentation, the potential consequences are complexity, limited productivity and possible security expose.  Finally, depending on the data classification or risk profile of the assets in AWS, this identity silo is subject to the corporate security policy (password policies, user attestation reporting, least access management, etc.)

In the past few years, Amazon has recognized this challenge and provides vast extensibility to IAM, via APIs and using standards like SAML and OpenID Connect. 


This article provides a practical example that not only meets but exceeds the best practices around Amazon AIM, eliminates dual-administration and aligns administration with internal policies.



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.


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


  • Increase the speed of Access and Privilege related reports
  • Provide information to your Security or Audit counterparts for Access or Attestation purposes
  • Automate Attestation report generation and delivery
  • Provide a data source for custom report generation.

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.


What is the Centrify Reports feature designed for?

It's designed to overcome the limitations of existing report generation via LDAP (speed), provide flexibility (SSRS or Bring your Own Reporting), and increase productivity (automate report generation and distribution).


Can you describe an example?

The typical scenario is that depending on your risk or regulatory profile you need to provide user entitlements (who has access to a server or collection of servers in a Centrify zone and  what can they do with Privilege using DirectAuthorize).  For example:

  • Who has access to UNIX/Linux or Windows Server? What privileges do they have (dzdo/dzwin)? What AD object grants access?
  • Who can access this collection of systems? What privileges do they have (dzdo/dzwin)?

These entitlement reports, are used typically in attestation exercises.  Attestation may be done manually (you get together an ratify that these are the proper people that should have access) or automatically using a Security Governance tool (at that point, a feed is inserted to the tool).


With the end of extended support for Windows Server 2003, many organizations are exercising due diligence and upgrading Windows Active Directory systems to newer OS versions. Although this requires thorough planning by your organization, many of our prospects and customers often ask about their current AD changes and wonder about how that impacts systems running Centrify Server Suite for UNIX/Linux or Identity Service Mac Edition clients.  This article is a quick primer on what changes when the Domain Functional Level changes.  We are focusing on the jump from 2003 to 2012 as an example.


Repositories for Yellow Dog Updater Modified (YUM) or the Advanced Package Tool (APT) are now part of every IT Infrastructure department's arsenal.  They provide foundational services for deployment and automation of software.  Centrify has traditionally shipped all the native packages for each supported platform, this means any customer (Express or Commercial) should be able to download software from the Download Center and integrate it to their existing orchestration and package management solution.


In many cases prospects and customers ask us how can we help integrate with their existing [Bladelogic | Satellite | Chef | Puppet | System Center | Casper |  other]; the answer is very simple:  "We give you the native package";  however, this may not be enough.  In the "Orchestration basics" series we will write a set of articles that lay the foundation for these services.  


We will start by teaching you how to set up your very own YUM repository to support RHEL and derivatives.  This should be good for the following platforms:  CentOS, Citrix XenServer,Oracle Linux, RHEL, Fedora and Scientific Linux on i386, x86_64, PPC, S/390x and Itanium.  We'll add other strategies like APT, HTTP and NFS as well.


IT Professionals are often required to provide evidence of alignment with security regulations.  At Centrify, since we provide Identity and Access Management solutions, this means that providing capabilities that satisfy regulations is at the heart of many of our products;  it drives design, engineering and marketing efforts.


All this would be nothing if we weren't in the position to coach our customers and prospects on how we can meet or exceed their needs.  This entry is based on a template email that we developed in the New York Metro region to assist when our customers ask us how to prove Server Suite's alignment with the Sarbanes-Oxley Act. 


Amazon AWS is quickly becoming one of the most popular options for Enterprises to extend their Data Center infrastructure out in the cloud. IaaS vendors like Amazon provide an array of services that include directory services, orchestration, automation, APIs and more.  


It's important to understand that flexibility can slowly become chaos, especially for enterprises that have fought hard to consolidate processes around Identity and Access Management.


This multi-part series discusses a basic IAM playbook that can be enabled with Centrify’s Identity Platform (Identity Service, Server Suite and Privilege Service). The principles continue to be the same: Implement Strong Access Controls using what you have: Active Directory as the Identity Store and enhance the experience and security controls leveraging Centrify Technologies.


Organizations can always count with the reliability of IBM hardware, operating systems and utilities for mission critical applications. That’s why Centrify has invested in certifying the product lines with IBM infrastructure.


This post discusses the DB2 SSO Module; this plugin (like the Apache HTTP and Java plugins) leverages the Active Directory integration capabilities and robustness of the Centrify agent to provide additional value and functionality to DB2 implementations.


The DB2 plugin provides the following benefits:

  • No need to keep users local to the UNIX/Linux system to support DB2: When used natively, DB2 users need to have user accounts in the local /etc/passwd file. The DB2 enables AD users to access DB2 so the benefits of Unified Identity, Centralized Administration, Streamlined Authentication and Policy Enforcement are organically attained.

In practical terms: no more getting dinged by auditors when the account of a long-gone user is found active in the /etc/passwd of a DB2 system.

  • Long login names: Support for logins that are longer than 8 characters
  • Single Sign-on (SSO): Centrify enables SSO to DB2 leveraging the GSSAPI
  • Active Directory Group Support: AD group memberships can be leveraged to grant entitlements inside DB2.


This is one of the best Database to AD integration models out there.


This article covers setup, configuration and testing of the DB2 moduleon Linux 64 bit in a lab environment. We will focus on the User/Password and Group Plugin first since they enable a UNIX/Linux admin to set it up without any AD requirements.  In a follow-up post we'll cover the SSO GSSAPI plugin. 


Like any other DBMS, a true production implementation requires planning and understanding of the current environment.


Showing results for 
Search instead for 
Do you mean 

Community Control Panel