The Centrify Privileged Identity Management solution provides a set of controls for Google Compute Engine Linux VM Instances to support Enterprise integrated identity and access management functions. This solution enables organizations to consolidate identities, enforce cross-platform least privilege access and control shared accounts, while securing remote access and auditing all privileged sessions.


This guide will show how to setup and configure Active Directory based identity and access controls as well as privilege management for Linux VM Instances running on Google Cloud Platform. It will also show how to take over password management for local root accounts as well as to provide secure remote access to these Linux VM Instances.


Using Centrify Server Suite to prevent the use of SSH keys


This week we've made available our new version of Centrify Server Suite 2017 and like any new release it's packed with new capabilities, features and bug fixes.  This post will allow you to explore what's new in this release and what are the some key planning considerations for successful deployment.


What's new on Server Suite 2017


  • Kerberos Library Upgrade: In this release, Kerberos libraries have been upgraded to MIT  5-1.14.1.
  • Flexible Authentication Secure Tunneling (FAST):  Also known as Kerberos armoring, secures pre-authentication traffic and protects KDCs from error spoofing.
  • This upgrade allows support for Smart Cards using AES-256 encryption.  Centrify has tested with Oberthur ID One 128 v5.5 Dual SHA256 and G&D FIPS 201 SCE 3.2 SHA256 Cards.

Flexible open-source packaging

  • cdc-dep.pngCentrify DirectControl has leveraged OSS packages (OpenLDAP, cURL and OpenSSL); in versions prior to 2017 updating these packages required a re-spin of the whole suite (in all supported platforms)
  • Starting with CSS 2017 (DirectControl 5.4) the packages for cURL, OpenSSL and OpenLDAP are independent and can be separately updated, this will allow for faster response to any CVEs that apply to those components.


  • Implemented transaction control for LRPC2, this provides security improvements over heavy load.  Requires that both DirectControl and DirectAudit are upgraded.
  • MFA: Since Centrify Identity Service version 16.10 the IWA negotiations happen over SSL. This means that either Enterprise CA, Public CA or IWA root certificate trust must be established for Centrify Multi-factor Authentication to be successful.

Centrify Report Services

  • New Operation Mode (zone mode):  The first release of report services works in "domain mode" this means that the "Replicating Directory Changes" delegation was required.  Now in this mode, only delegations at the zones container is needed, keeping the scope of the information sent to report services only to Centrify data.
    reports - modes.png
  • Report options:  include the ability not to generate charts as well as reports for local users.

Centrify-enhanced OpenSSH

  • SSHv1 is no longer supported.
  • AIX:  The LAM version of Centrify-enhanced OpenSSH is no longer shipped.  This is because supported versions of AIX ship with PAM enabled.

Introducing Centrify Licensing Service

  • Customers are asking to provide more efficient and proactive licence capacity and usage and many are asking for elastic licensing to support public cloud workloads.
  • Centrify Licensing Service (v1) targets perpetual licensing and provides mechanisms for streamlined capacity, inventory and notification.
    cls - main.png
  • CLS requires a highly-available Windows server that runs the licensing service (this does not have to be a dedicated server)

LDAP Proxy performance enhancements

  • The LDAP Proxy now implements new caching mechanisms (at the server auth and client) that can result in performance increases.

Centrify Agent for Windows

  • MFA:  Supported at login (console, RDP, screensaver unlock) in two modes:  zone mode and zoneless mode.  Zoneless mode requires a Centrify Identity Service device license.
  • Support for both MFA at login and with privilege elevation (desktop, applications) is exclusive to zone mode (requires Standard Edition license)
    mfa -zoned.png
  • Just like UNIX/Linux MFA, requires IWA over SSL, this means that Enterprise, Public or IWA root cert trust must be planned and implemented.
  • Application Manager:  This application can be assigned to a role to allow Add/remove of Windows programs
  • Feature Manager:  This application can be assigned to a role to allow for Windows feature management

DirectAudit Enhancements

  • Compiled with libaudit support (system call monitoring at the Kernel level) on RHEL and derivatives (more platforms coming in the next releases)
  • DirectAudit is now able to monitor file changes on /etc/, /var/centrifydc and /var/centrifyda
  • DirectAudit is now able to audit commands run inside scripts
  • DirectAudit is now able to monitor for specific command executions.


Platform Support

Platforms Added

  • Amazon Linux AMI
  • CentOS 6.8 (x86, x86_64)
  • CentOS 7.3 (x86_64)
  • Debian Linux 7.1, 8.5-8.7 (x86, x86_64)
  • Fedora 24, 25 (x86, x86_64)
  • Mac 10.12 (x86_64)
  • Oracle Linux 6.8 (x86, x86_64)
  • Oracle Linux 7.3 (x86_64)
  • Red Hat Enterprise Linux 6.8 (x86, x86_64)
  • Red Hat Enterprise Linux 7.1, 7.2, 7.3 (ppc64le)
  • Red Hat Enterprise Linux 7.2 (zLinux) on Standard Edition
  • Red Hat Enterprise Linux 7.3 (x86_64)
  • Red Hat Enterprise Linux 7.3 (ppc64)
  • SUSE 12 (ppc64le)
  • Ubuntu 16.10 (x86, x86_64)

 Platforms Removed

  • Fedora 21
  • Mac 10.9
  • OpenSUSE 13.1
  • SUSE Linux Enterprise 10.x
  • Ubuntu 15.04, 15.10

Component Version Upgrades

  • Centrify-enhanced OpenSSH is now based on OpenSSH 7.3p1
  • Centrify-enhanced sudo (dzdo) is now based on sudo 1.8.17p1
  • Centrify-curl is based on libcurl version  7.51.0
  • Centrify-openssl is upgraded to version  1.0.2j
  • Centrify PuTTY is upgraded to version  0.67


Planning tips for Server Suite 2017

  1. As recommended, read the release notes and upgrade guide.
  2. Even if you don't plan to update your clients right away, you can upgrade your consoles and group policy templates. 
  3. This is a major release and all components must be upgraded: DirectControl, DirectAudit (agents/collectors/database), this is because:
    • Kerberos upgrade
    • New LRPC2 transaction protocol
    • New Open-source packaging
    • OpenSSL upgrade
  4. Plan for Centrify Licensing Service - have the service installed on one or two highly-available windows servers.  Have your technical and procurement leads in the notification lists and designate a thresold to get proactively sent deployment reports.
  5. Due to the new DirectControl packaging, plan to update your DevOps recipes/cookbooks (Chef, Puppet, Ansible, etc)
    Tip:  adjoin has a new option “-F/--forceDeleteObj” to clean up the existing computer object and extension object in Active Directory before performing the adjoin operation.
  6. If you're using Centrify-enhanced OpenSSH on AIX platforms, plan phase out unsupported versions or to migrate and test existing PAM support; this is because we no longer ship a LAM version.
  7. SmartCard: RC4 and DES are no longer supported;  this means you have to plan to upgrade to AES-128 or AES-256 to ensure compatibility.
  8. Leverage the Centrify Repo for quick updates on RPM, APT or Zypper-compatible distributions.
  9. The new capabilities of DirectAudit (config file monitoring, monitored execution, etc) are not turned on by default.  You have to turn on the event.execution.monitor and event.monitor.commands parameters in the /etc/centrifyda/centrifyda.conf file.  Make sure you do a baseline analysis first.
  10. Hybrid-cloud support:  remember that you can use Server Suite in your AWS, Azure or GCP deployments and that Centrify provides unique support for complex AD scenarior like one-way trusts, RODC and now Kerberos Armoring.


Conclusion - It's all about value

  • With each release of Server Suite, Centrify adds more new capabilities that ensure alighment with security practices and regulations and operational efficiency.
  • You have to learn to spot issues with your current deployment like:
    • Challenging management due to a large number of zones:   this may mean that your implementation is following outdated practices.  Back in 2010 Centrify introduced Hierarchical zones, this allows for better administration, privilege management and a reduced number of zones.
    • Not leveraging privilege management:  Authentication was the problem 10 years ago. Now you're faced with multi-platform attestation, conformance with MFA requirements, etc.  These are all parts of the product that you own.
    • Not getting the proper "insight":  Centrify Report Services and the integrations with Splunk, ARCSight and QRadar are the best ways to understand what's happenning in your Centrify deployment today.
      Check out this article series to see the insights you should be getting:
    • Cognitive gaps:  If you or your team feel that have inherited a Centrify deployment and don't have the proper training, let your reps know and they'll take care of that.
  • For an article discussing what do if you inherited a Centrify infrastructure, go here:

Expect some in-depth articles on some of the newest features of this release.



Security Kaizen - Part II:  System, Roles and Groups + Anomalies

Part I | Part II | Part III | Part IV

In the previous article of this series, we discussed the application of continuous improvement process (CIP) to security practices in the context of access control and privilege management.


We defined that the  goal is to implement the least access and least privilege principles across the board and that we start by collecting metrics like the number of users with system access, privileges, etc.  The idea is to Identity-Plan-Implement and Review.  For example:  If after reviewing the roles assigned to a user, we realize that this was a one-time request that was implemented permanently, we can eliminate the role assignment and have a process to review (perhaps every 30 days);  an improvement over this could be an automatic email sent to the user to extend the access instead of removing it.


We also introduced the concept of dimensions.  In the past article we focused on the user view,  in this article we discuss other dimensions.


System View

Total Centrify-managed systems vs Domain-joined systems

To identify Centrify-managed systems, first you need to identify the existing zones in your environment.

Get-CdmZone | Select Name, Domain, DistinguishedName, Schema 

Once you have identified the zones, you can enumerate the number of systems under all active zones.  An improvement point is to ask: "Why are these zones in existence if no systems are currently being managed?"

Another point of concern is if a large number of classic zones are encountered.  Centrify best practices since 2010 favor hierarchical zones over classic zones. 


The goal in this measurement is to understand which systems are under Centrify management and aren't.  For example, you can use these commandlets:

Get-CdmManagedComputer -Zone (Get-CdmZone -Name Global) | Measure
Get-ADComputer -Filter *  | Measure

to count the Centrified systems and all AD-joined systems.  This will give you a ratio of the % of systems that are managed by Centrify.  For example, in my test system I have 12 total systems with 5 managed by Centrify.


This is important because you need an alternative strategy for assessing who has access and privileges on those systems OR you can ask "Why haven't these systems been set up under Centrify management?"


Computers that grant more access and computers subject to more assignments


These metrics allow you to identify the systems that have the less stringent access controls; in addition, you can identify the systems that are subject to more role assignments.   Reviewing the data classification of the apps on these systems is advisable since the more access exists, the more possibilities of users saving privileged data.


Logins by System

This system view complements the "logins by user" metric discussed in the previous article.  This one has an interesting twist.  Note that I said I have 5 Centrified systems, however, I seem to be only getting data for 2 systems.  This is an indication that perhaps there is a misconfiguration; in my case I only have the Splunk forwarder installed in two of my demo VMs.  Note that in the case of hybrid cloud, because systems are treated as cattle, you may not notice users logging in at all.




Computers subject to more privileges


This is the privilege view of systems.  Notice that my Ubuntu system grants more privileges than the rest; if this was a PCI or SOx system, you want to dig deeper to find out why.


Privileged Access with most computers in scope


This metric allows you to identify what rights are more prevalent in the computer population.  The more common the right is, the more prevalent it will be; expect login rights (e.g. ssh, sshd or login-all) to be more prevalent.  If you see something like "run as root"  or  "Administrative Desktop" as a prevalent command, this may be part of a sysadmin role.


Privilege Activities by Type

Often you may need to look at a system and find out exactly what the privileges activities are most common.  This complements the user view (e.g. most used privileged commands)



Group and Role views

Before moving into groups and roles, let's add some context.  In Centrify DirectAuthorize, the best practice is to assign roles to AD security groups;  however AD security groups constitute what are called "Computer Roles" - these are nothing more than "Teams of Servers";  these constructs allow a system to belong to different types (e.g. a web server and a database server) which may be subject to roles assigned to different populations (e.g. web admins and DBAs respectively).


Roles with Most Access

These are the roles that have the broadest scope in a Centrify deployment.  Note that design principles suggest that Zone-level and computer-level role assignments should be used sparingly.



AD Groups with Most Members

Depending on the deployment mode of Report Services (domain or zone) you can get information about all or only the zone-relevant groups.  In this case, this graph indicates the membership numbers of groups that grant privileges in a Centrify deployment.


AD Group Attestation - Access


The picture above provides information about an AD group that is used in a Centrify deployment.  Note that it also highlights if the group has any nested groups and includes a detail of the systems it grants access to.


AD Groups with Most Privileged Access

 The common practice is to provide both access and privileges within the same group; therefore this report should be very familiar to the access report;  however there are exceptions, especially when using selective auditing.



AD Group/Role Attestation

This report shows the relationship between the AD group, the systems in scope and the rights defined in the system.


This is a great report to generate if you need to answer these questions:

  • What privileges does the "Apache Web Admin" group provides?
  • What role(s) are associated with it?
  • What is the scope of the role assignment?
  • What is the definition of the role (commands) that it provides?



Ideally anomalies are subject to security operation actions, however, as part of your overview of the access model, it's not uncommon to collect metrics of the kinds below, some of them are self-explanatory;  the others we'll provide some color.


Failed Logins by reason


Users with Multiple Login Failures


Failed Logins over Time


Any spike on failed logins could indicate attemps at lateral movement, or a service account with an outdated password.


 Denied Privileged Activities over Time


A spike on these could indicate a compromised account with attempts to perform privilege elevation.  MFA can help mitigate this risk.


Centrify Software Operations

Because a system that is not under management is easier to compromise, there are several operational activities that we should track:

Leave Activities


When a system is not in AD, you lose access control and the Centrify audit trail log.


DirectAudit Agent Service Stoppages


Privileged users can stop the session-capture client (DirectAudit), not without audit trail recording it.  Since most systems subject to this capability most likely are highly-sensitive, all anomalies should be investigated to make sure there's no collusion.



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


In part 1 of this series, we described how to configure DB2 Express-C on Linux and how to configure the Centrify DB2 Plugin.  In this article we will focus on testing the installation and an example of how to troubleshoot if things aren't working as expected.



Validating Centrify Zone Delegations

By Centrify Contributor II on ‎01-06-2017 07:06 AM

One of the major strengths of Centrify Server Suite, is that all UNIX identity and authorization data is stored as Active Directory objects in Centrify Zones. As a consequence, delegation tasks of zone management, are stored in Discretionary Access Control Lists (DACLs) on Centrify Zone objects in Active Directory.


The Zone delegations can be implemented using PowerShell (for example, using the Set-CdmDelegation PowerShell CMDlet, which is included with the Centrify.DirectControl.PowerShell module), or by using the 'Delegate Zone Control' context menu option in the Centrify DirectManage Access Manager console. Either method will provide you with the ability to chose from a list of a granular zone delegation tasks, that can be delegated to an Active Directory user or security group.



List of zone delegations in Access ManagerList of zone delegations in Access Manager

Applying zone delegations using the Centrify PowerShell CMDletApplying zone delegations using the Centrify PowerShell CMDlet 

As part of an engagement, Centrify Professional Services can aid you to conceive a delegation model using a RACI matrix, and implement the resultant zone delegations. This allows for implementing least privilege, where (for example) the service account for the zone provisioning agent can only add/remove UNIX profiles to/from a zone, but nothing more than that. If the ZPA service account gets compromised, it cannot be (ab)used to modify UNIX authorizations.


A returning question from customers during these engagements is: How can we validate that the delegations that have been implemented, are actually in place?




This article details the methods available to implement zone delegations, and how zone delegations can be validated.


Customers with NetApp ONTAP filers are looking to provide consistent level of access across multi-protocol CIFS and NFS shares.  To do this, the filers need to obtain Active Directory users and the UNIX identity of those users to provide the unified level of access required.  Customers with Centrify deployed can very easily accomplish this.  The following guide will show you how to integrate NetApp onTap filers with Centrify.  


If you're an existing Centrify customer, you may have seen recent news about the capability to support Multifactor Authentication at Windows Login. This article explains how to set this feature up in your Centrify Server Suite and Centrify Identity Service environment. 


Find out how to recover administrator access to an existing DirectAudit Installation by granting an AD User administrator privileges at the Database level. 


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


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


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




Leverage your Identity and Access Management to secure your AWS IaaS

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


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

Here are a few Tech Blogs that cover this topic:



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


See a technical showcase on CPS here:


AWS and the Identity Challenge

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


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


Exciting New Alternatives to Secure Extend your Enterprise Identity to AWS

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


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


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

To see an article that covers this new capability, click here:


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


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

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


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


Here's a quick demo



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


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




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

In the course of helping customers migrate to Centrify Adbindproxy, Support has identified some instances where the scale of Samba environments impact the effectiveness of the new adbindproxy component.  This blog will summarize a recent issue and workaround which may help other customers facing a similar situation.


Centrify supports another way of implementing stock Samba4 with Centrify that does not use adbindd, but uses NSS instead.  Access control is then based on NSS users and groups with winbind instead of using adbindd (Active Directory).


In one customer's environment, they were using Samba to share directories to a large number of end users whom were moving and accessing lots of large media files to and from those shares.


The Centrify Community has some great resources when it comes to IBM DB2 integration with Active Directory using Centrify. But, have you ever wanted to quickly set up DB2 in a test environment to play with these integrations? By following this article, you can!


OpenSSH 7.0 came up with a lot of improvement and several new features, but more importantly it came up with several deprecated functionalities around cryptography. This came as a long wait from the community but may have impact on your environment if you were using these removed functionalities.


Quando se utiliza o Centrify DirectAudit para capturar sessões em servidores, é muito comum também a necessidade de se apagar as sessões capturadas depois de uma determinada quantidade de dias, seja para reduzir a ulilização de espaço em disco da base SQL, normas regulatórias que exigem a retenção de dados por um período mínimo ou mesmo uma rotina de manutenção dos dados armazenados.


As discussed in part 1 of this series, there are multiple ways of integrating legacy UNIX/Linux systems into Active Directory.


One of those methods, entails using the Centrify LDAP proxy as a source of identities (i.e. source of passwd, shadow and group maps in Name Server Switch), and to proxy all authentication requests for these users by PAM to the Centrify LDAP proxy.


This means, that rather than using password hashes stored as user attribute values in Active Directory, which is very bad from a security perspective, user authentication attempts are proxied by the pam ldap module on the legacy system, to the LDAP proxy server in the form of a a simple bind using the user's credentials.


As an LDAP simple bind is performed in plain text, the connection needs to be secured using either TLS, IPsec, VLAN isolation or through other means.  In this guide, TLS is used purely for demonstration purposes, as in practice, legacy systems are unlikely to support anything better than SSL 3.0 (which is insecure).


Note that some reading material will benefit for the understanding of how the LDAP proxy works, including some configuration advice:



This article will provide a walk-through on how to install and configure a system to use agent-less authentication against the Centrify LDAP proxy, without relying on password hashes stored in Active Directory. It uses a mock-legacy system in the form of a CentOS 6.8 client for this purpose; however the same troubleshooting steps apply when configuring 'real' legacy platforms, such as HPUX 11.00 for authentication against the Centrify LDAP Proxy.


Want to know how to migrate your UNIX profiles from an existing AD Bridging solution or LDAP to Centrify Server Suite for UNIX/Linux?  These steps will who you how to leverage your existing unix profiles and migrate to Centrify from other centalized solutions with minimal impact to your environment and processes.


mkComputerRoles.tcl: A Script for Enabling Centrify Deployment (part 4)

By Centrify on ‎09-29-2016 10:10 AM - last edited ‎09-30-2016 04:10 PM

In part three of this blog, I continued the discussion of using the mkComputerRoles.tcl script with a ComputerRoles.csv definition file to add AD accounts to the User Groups. I showed how to add the AD account to the User Groups from the passwd files, as listed in the ComputerRoles.csv file. As an alternative, I also showed how to add the AD accounts to the User Groups as explicitly defined in a “map file”.


In this final blog of the series, I will show how to implement an enhanced separation of duties model with the mkComputerRoles.tcl script.


Active Directory OU Structure for an Enhanced Separation of Duties Model

The Centrify best practices OU structure is designed to implement a basic separation of (administrative) duties model (this was discussed in part 1). In some cases, however, the need exists to implement a more granular separation of (administrative) duties model. One method of achieving this granularity of separation of (administrative) duties is to store the UNIX computer objects, User Groups and Computer Groups in OUs based on the required separation of duties. Then, create distinct AD security groups and delegate to them the required AD rights to manage objects in those OUs.


For example, suppose there is a need to separate the administration of UNIX computers based on their usage; that is production versus development. Then, the Centrify best practice OU structure as discussed in part 1 of this blog, could be manually augmented. For example, an OU called Prod and one called Dev could be created in the Computer Roles, User Roles and Computers OUs. Also, AD security groups such as cfyA_ProdAdmins and cfyA_DevAdmins could be created in the Centrify Administration OUs. These security groups can then be delegated the appropriate AD rights on the relevant OUs (see table below).


An example of the enhanced OU structure and new security groups is:




The minimum AD rights that are delegated to the security groups are:



Delegated Permissions

OU=Dev,OU=Computer Roles



·      Create, delete and manage groups

·      Modify the membership of a group

OU=Prod,OU=Computer Roles



·      Create, delete and manage groups

·      Modify the membership of a group

OU=Dev,OU=User Roles



·      Create, delete and manage groups

·      Modify the membership of a group

OU=Prod,OU=User Roles



·      Create, delete and manage groups

·      Modify the membership of a group




On the Object Tab:

·      Create/Delete Computer Objects (This Object and All Child Objects)

·      Reset password (Descendent Computer Objects)

·      Change password (Descendent Computer Objects)

·      All Extended Rights (Descendent Computer Objects)

·      Validated write to DNS host name (Descendent Computer Objects)

·      Validated write to service principal name (Descendent Computer Objects)

On the Properties Tab

·      Write userAccountControl

·      Write operatingSystem

·      Write operatingSystemVersion

·      Write operatingSystemHotfix

·      Write operatingSystemServicePack

·      Write Description

·      Write displayName

·      Write name

·      Write Name

·      Write ComputerName (pre-Windows 2000)

·      Write dNSHostName




On the Object Tab:

·      Create/Delete Computer Objects (This Object and All Child Objects)

·      Reset password (Descendent Computer Objects)

·      Change password (Descendent Computer Objects)

·      All Extended Rights (Descendent Computer Objects)

·      Validated write to DNS host name (Descendent Computer Objects)

·      Validated write to service principal name (Descendent Computer Objects)

On the Properties Tab

·      Write userAccountControl

·      Write operatingSystem

·      Write operatingSystemVersion

·      Write operatingSystemHotfix

·      Write operatingSystemServicePack

·      Write Description

·      Write displayName

·      Write name

·      Write Name

·      Write ComputerName (pre-Windows 2000)

·      Write dNSHostName


The UNIX administrators of the development computers would be added to the group cfyA_DevAdmins and the UNIX administrators of the production computers would be added to the cfyA_ProdAdmins group.


The Centrify Zone Structure for the Enhanced Separation of Duties Model

Corresponding to the enhanced OU structure, a zone structure is created. It consists of a single parent zone named Global and two child zones named Dev and Prod. For example:


Using Centrify Access Manager, the cfyA_DevAdmins and cfyA_ProdAdmins groups are delegated full (All) control of the Dev and Prod zones, respectively. For example:



Execute the mkComputerRoles.tcl script

The ComputerRoles.csv file looks like this:

Where the engcen6 computer will be joined to the Dev zone and added to the computer role DevServers.


The mkComputerRoles.tcl command to use is:

mkComputerRoles.tcl -d centrifyimage.vms -f ComputerRoles.csv -j ad,scp -a –o ou=dev,ou=computers,ou=centrify –c “ou=dev,ou=computer roles,ou=Centrify” -r “ou=dev,ou=user roles,ou=Centrify” -u tetsu


Note: The mkComputerRoles.tcl script should be executed by a user who is a member of the cfyA_CentrifyAdministrators group, which has been delegated AD rights to create objects under the Centrify OU.


Results of executing mkComputerRoles.tcl script

After executing the mkComputerRoles.tcl script the following objects are created in AD:


  • The Computer Role DevServers is created in the child zone Dev. The Description field is written and an AD group, called a Computer Group (or Computer Role Group) cfyC_DevServers, is created for the Computer Role. For example, as seen in Access Manager:



  • The Computer Group is created in OU=Dev,OU=Computers. For example, as seen in ADUC:


  • The computer object is created in OU=Dev,OU=Computers. For example, as seen in ADUC:

  • The computer object is added to the Computer Group, cfyC_DevServers. For example, as seen in ADUC:


  • A Service Connection Point (SCP) object for the computer is created. For example, as seen in Access Manager:


and as seen in ADUC:


  • The User Group, cfyUC_UNIX Login_DevServers, is created in OU=Dev,OU=User Roles. For example, as seen in ADUC:


  • The UNIX Login role is assigned to the computer role, DevServers using the group cfyUC_UNIX Login_DevServers. For example, as seen in Access Manager:



I showed that the mkComputerRoles.tcl script can be used to create AD objects in OUs specified on the command line. Consequently, it can be used to implement a granular separation of (administrative) duties model.




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


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


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


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


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


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


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


And then verify it was removed:


dzdo rpm –qa | grep –i Centrify


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


dzdo rpm –qa | grep samba


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


dzdo yum remove samba*

Enter a y to remove when prompted.


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


dzdo yum install samba4*

When prompted, enter a y to install.


We should then verify installation:


dzdo rpm –qa | grep samba


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


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



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

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


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




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


mkdir /tmp/adbindproxy


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


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

cd /etc/adbindproxy

tar –xvf centrify-adbindproxy…….tgz


We’ll then install adbindproxy with the rpm command:


dzdo rpm –Uvh centrify-adbindproxy…….rpm


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


dzdo /usr/share/centrifydc/bin/


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


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


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

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


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

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


dzdo service centrifydc-samba restart


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


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


dzdo chkconfig --add centrifydc-samba


We then need to start this chkconfig process:


dzdo chkconfig centrifydc-samba


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


dzdo chkconfig --list centrifydc-samba


We’re ready to verify the samba version installed:


smdb –V


We can also verify we see the Linux shares:


smbclient -L //localhost


And then connectivity to the shares:


smbclient //localhost/sharename


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


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


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


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

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


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



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


This article will show how to install, configure and setup the Centrify LDAP Proxy for testing in under 1 minute.


Tweaking Your DirectAudit


In part two of this blog, I discussed the command line options to the mkComputerRoles.tcl script. I demonstrated the use of the mkComputerRoles.tcl script along with the ComputerRoles.csv definition file, to create Computer Roles, to create User Groups and to assign the UNIX Login role to the Computer Roles (or Computer Groups) using the User Groups. The script also created the UNIX computer objects in AD and added them to the Computer Groups.


In this blog I will examine the options to add users to the User Groups.


Add users to User Groups from passwd files

The -i <passwdDir> option of the mkComputerRole.tcl script can be used to add AD users to the User Groups. Where passwdDir is a directory containing the UNIX passwd files of the computers listed in the ComputerRoles.csv file. The passwd files must be named “FQDN”.passwd, where “FQDN” is the FQDN of the computer as listed in the ComputerRoles.csv file (e.g., engcen5.centrifyimage.vms.passwd).

The script will append the supplied AD domain name from the command line to each UNIX name in the passwd files, and then search the AD domain for a user with a matching UPN. If a user is found, the user is added to the corresponding User Group for the computer, as defined in the ComputerRoles.csv file.


For example, given the following data (excluding the header) in the ComputerRoles.csv file:



and the following two passwd files in the passwdDir directory:


engcen5.centrifyimage.vms.passwd  engcen6.centrifyimage.vms.passwd


The mkComputerRoles.tcl script is executed with the following options:


mkComputerRoles.tcl -d centrifyimage.vms -f ComputerRoles.csv -j ad,scp -a -i passwdDir -u tetsu


Result of Executing the mkComputerRoles.tcl Script

After executing the mkComputerRoles.tcl script the following objects are created in AD:


  • The parent zone Global and the child zone Engineering are created. The Computer Role Engineering Servers is created in the child zone. The Description field is written and an AD group, called a Computer Group (or Computer Role Group) cfyC_Engineering Servers, is created for the Computer Role. For example, as seen in Access Manager:


  • An AD group called a User Group (or User Role Group), cfyUC_UNIX Login_Engineering Servers, is created. It is then used to assign the UNIX Login role to the Computer Role (or Computer Group). For example, as seen in Access Manager:



Note: The role assignment is time bound. Meaning, it is only effective on the start date/time and expires

on the end date/time. This is an optional setting in the ComputerRoles.csv file.


  • With the use of the “-i passwdDir” option, the users from the passwd files were added to the User Group. For example, as seen in ADUC:


The result is that the users who are member of the User Group, cfyUC_UNIX Login_Engineering Servers, have the right to logon to all the computers that are member of the Computer Role (i.e. Computer Group) cfyC_Engineering Servers. For example:



This method of deriving the user UPN from the UNIX logon name and the AD domain name does not hold true in many situations. Consequently, another method is supported by the mkComputerRoles.tcl script, namely a “map file”.


Add users to User Groups from a Map File

The -i <MapFile> option of the mkComputerRole.tcl script can be used to add AD users to the User Groups. Where MapFile is a CSV formatted file that list the User Groups and the AD accounts that should be added to the User Groups. The format of the file is:





UserGroup is an AD group that is used to assign a role to a Computer Role (as defined in the ComputerRoles.csv file) and user is an AD account that will be added to the User Group. For example, the contents of the file MapFile.csv:


cfyUC_UNIX Login_Engineering Servers,chris.rock,tina.fey@centrifyimage.vms,eddie.murphy


The command to run is:


mkComputerRoles.tcl -d centrifyimage.vms -f ComputerRoles.csv -i MapFile.csv -u tetsu


Note: The “-j” and “-a” options are omitted because they have already been used. However, they could have been used again with no effect.


The resulting membership of the cfyUC_UNIX Login_Engineering Servers group is:




Using the mkComputerRoles.tcl script with the “-i” option, the User Groups can be populated with the AD accounts corresponding to the UNIX logon name in /etc/passwd files. If necessary, a “map file” can be created that list the AD accounts to be added to each User Group and the mkComputerRoles.tcl script can then add the AD accounts to the specified AD groups.


In the next and final blog in this series I will demonstrate another option to the mkComputerRoles.tcl script the enables the separation of duties model.


This article will describe how Centrify helps customers address disjointed AD and DNS namespaces to achieve Kerberos SSO.



 Centrify DirectAuthorize for Windows provides a solid defense mechanism against “Pass the Hash attacks” as it enables the granting of privilege only to a specific machine and a specific process at a point in time.  This tech blog shows how to confirm this with Process Explorer.  


This series of articles will walk you through some real-life examples of how Centrify Role-Based Access Control (RBAC) can help get better control of your Identity Access and Privilege management.


This article is going through several exemples of Roles and Rights on UNIX and Linux systems and how they can answer various IT security rules in real life examples.



Regulatory frameworks have evolved to require documented evidence of approval for development or infrastructure-related change control.  These activities usually require the exercise of elevated privileges.  Some examples of these requirements and guidelines can be found on PCI DSS, SANS Critical Security controls, ISO 27001 and others:



Centrify DirectAuthorize and DirectAudit provide end-to-end, role-based access controls for UNIX, Linux and Windows, in addition it provides mechanisms for validation and tracking of changes via ticketing or request systems.



We've had customers that have two categories of requirements:

  • Tracking activities related to a particular change control or approved request
    For example: We want to track all privileged activities related to a change control in my security operations dashboard.
    We covered this on this on the original dzdo validator article.  When privileges are elevated, entries in both syslog or DirectAuthorize get created automatically.
    Using Centrify-enhanced sudo:
    $ dzdo tail /var/log/messages
    Enter the change control ticket number:1255


    Nov  7 15:04:39 engcen6 dzcheck.sample[35173]: User "dwirth@centrify.vms" will run "/usr/bin/tail /var/log/messages" as "root" with ticket number "1255"
    DA Console:
    DirectAudit Analyzer - dzdo.validator event.jpg
  • Implementing controls to prevent unauthorized changes
    For example:  We want to make sure that any privilege elevation is only allowed with an approved request.
    This lab covers a basic lab setup to implement this requirement.


Lab Diagram



What you'll need:

  • Centrify Standard Edition and a Centrify Zone with some UNIX roles defined
  • An AD-joined UNIX or Linux  system in the Centrify zone
    The system should be able to reach the ServiceNow instance directly, via proxy or via ServiceNow MIDServer.
  • A DirectAuthorize role for UNIX
  • A ServiceNow instance (Fuji release minimum) and a shared credential or token to query existing requests
    Make sure that the credential only has the minimal rights (e.g. read-only) for your requests.
  • Optional:  Centrify Privilege Service (Saas or On-Prem) to vault the SN user's credential. 


Use Case

  1. Privileged user obtains a change control manager approval via ServiceNow workflow request.
    The request has a change control window.  (date/time range)
  2. During the request validity timeframe, the privileged user needs to perform activities (using Centrify-ehnanced sudo) and when the commands are issued, the SN request number has to be provided.
  3. The dzdo.validator script uses the ServiceNow Perl API to validate if the request is approved or not.
    Additional validations can be added like user, time-range, etc;  these won't be covered for blog brevity.
  4. If the request is a approved, the Centrify-enhanced sudo command is allowed to execute.  If not, the user is notified.


Implementation  Overview

  1. Install the ServiceNow Perl API
  2. Test ServiceNow Instance connectivity
  3. Optional:  Protect the shared credential using Privilege Service
  4. Modify one of the sample scripts to work with ServiceNow Requests
  5. Modify the dzdo.validator script to call the ServiceNow Perl API script
  6. Implement the dzdo.validator via parameter or GPO
  7. Test your results


Install the ServiceNow Perl API

The full instructions and requirements are here:

  1. Make sure you have the appropriate Perl plugins  (e.g. CentOS 6.x):
    SOAP::Lite  (e.g. yum install perl-SOAP-Lite)
    Crypt::SSLeay (e.g. yum install perl-Crypt-SSLeay)
    IO::Socket::SSL ( e.g. yum install perl-IO-Socket-SSL)
    MIME::Types (e.g. yum install perl-MIME-Types)
  2. Download the Servicenow Perl API  (link to 1.01 version) to your UNIX/Linux system
  3. Unzip the file in a new folder and run the following commands:
    ## create a new folder, download and unzip
    $ mkdir SN
    $ cd SN
    $ wget
    $ unzip
    ## compile the files
    $ perl Makefile.PL $ make $ make test $ make install
    Follow the prompts, once you have all the ServiceNow Perl API libraries installed to use with your scripts.


Testing Connectivity with your ServiceNow Instance (Sample Script)

  1. Create a new file with these contents
    # This script retrieves all the requests from your servicenow instance
    # it is used to test connectivity.
    #!/usr/bin/perl -w
    use ServiceNow; use ServiceNow::Configuration;

    # This example uses Centrify Privilege Service's AAPM capability
    # by checking-out the password from the vault at runtime, we eliminate
    # the need to use a cleartext password in this script.
    # uses cgetaccount to check out the password for your-SN-user for 3 mins.
    # Alternatively you can enable OAuth and use Tokens (recommended)

    $SN_PASSWD = `cgetaccount -s -t 3 your-SN-user`; my $CONFIG = ServiceNow::Configuration->new(); $CONFIG->setSoapEndPoint(""); $CONFIG->setUserName("your-SN-user"); $CONFIG->setUserPassword($SN_PASSWD); my $SN = ServiceNow->new($CONFIG); my @requests = $SN->queryRequestedItem(); my $count = scalar(@requests); print "Number of requests=" . $count . "\n"; foreach my $request (@requests) { print "Request number: $request->{'number'}\n"; print "Requested by: $request->{'sys_created_by'}\n"; print "Date Created: $request->{'sys_created_on'}\n"; print "Approval Status: $request->{'approval'}\n"; print "\n"

 2. To test the script, add the execution flag and run it

$ chmod +x
$ ./
Number of requests=34
Request number: RITM0000002
Requested by: fred.luddy
Date Created: 2016-05-02 18:15:39
Approval Status: requested

Request number: RITM0000004
Requested by: fred.luddy
Date Created: 2016-09-03 17:15:39
Approval Status: requested

Request number: RITM0000005
Requested by: fred.luddy
Date Created: 2016-05-22 19:15:43
Approval Status: requested
[output truncated]

Modify the Sample Script to work with Individual Ticket Numbers

To do this, you need to change the script to require arguments and check for usage.   The modified lines would look like this:


#!/usr/bin/perl -w

# You're checking for arguments here.  If there are no arguments
# show the usage and exit.  E.g.  checksn RTM00005

if (@ARGV)  {

# The previous program can go here.  Make sure you modify this line
# to look like this:

my @requests = $SN->queryRequestedItem({'number'=> $0})

}  else {
          print "USAGE:  checksn [ServiceNow Request ID]\n"

Note that there's no error logic for requests that are not found.  We're going to have to add this later.


Modify the dzdo.validator script to to use the ServiceNow Perl API script


Centrify provides a sample dzdo validator script called dzcheck.sample.  This script exists under /usr/share/centrifydc/bin.

With the author's limited scripting knowledge we were able to modify it to work this way:


  • Initialize the proper libraries and variables
  • Retrieve the password for the ServiceNow user (your-user) and store it in SN_PASSWD
  • Connect to ServiceNow instance
  • Prompt the user for a Change Control number
  • If the number is not found, log to syslog and the user will not be allowed to run the command
  • If the number is found but the status is not approved, log to syslog and the user will not be allowed to run the command
  • If the number is found and approved, log to syslog and allow the end user to run the command.

Note that additional error logic and checks can be added.


#!/bin/sh /usr/share/centrifydc/perl/run
# A modified demo for Centrify-enhanced sudo (dzdo) validator 
# Modified to work with ServiceNow Requests
use strict; use lib "../perl"; use lib '/usr/share/centrifydc/perl'; use CentrifyDC::Logger; use ServiceNow; use ServiceNow::Configuration;
# Use privilege service to retrieve SN shared account password
# Alternatively, you can modify the script to use an OAuth token
my $SN_PASSWD = `cgetaccount -s -t 3 your-user`; my $dzdo_user=$ENV{DZDO_USER}; my $dzdo_command=$ENV{DZDO_COMMAND}; my $dzdo_runasuser=$ENV{DZDO_RUNASUSER}; my $CONFIG = ServiceNow::Configuration->new(); $CONFIG->setSoapEndPoint(""); $CONFIG->setUserName("your-user"); $CONFIG->setUserPassword($SN_PASSWD); my $SN = ServiceNow->new($CONFIG); my $logger = CentrifyDC::Logger->new('dzcheck'); printf STDERR "Enter the change control ticket number: "; my $user_input=<>; my @requests = $SN->queryRequestedItem({'number' => $user_input});
# Check if request(s) exist, if not, exit (1) if (scalar(@requests)==0) { system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input"; $logger->log('INFO', "Change control ticket number: %s", $user_input); $logger->log('INFO', "User \"%s\" will not be allowed to run \"%s\" as \"%s\" with ticket number (REASON:not found) \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input); exit 1; }
foreach my $request (@requests) { my $req_status = $request->{'approval'}; # Exit if request is not in approved status if ($req_status ne "approved") { system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input"; $logger->log('INFO', "Change control ticket number: %s", $user_input); $logger->log('INFO', "User \"%s\" will not be allowed to run \"%s\" as \"%s\" with ticket number (REASON:not approved) \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input,$req_status); exit 2; } }
# Run command and log if request is approved
system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input"; my $logger = CentrifyDC::Logger->new('dzcheck'); $logger->log('INFO', "Change control ticket number: %s", $user_input); $logger->log('INFO', "User \"%s\" will run \"%s\" as \"%s\" with ticket number \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input); exit 0;

I've saved this script as dzcheck.snow in the same location.


Configure Centrify-enhanced sudo (dzdo) to use the ServiceNow Requests validator

  1. Open the /etc/centrifydc/centrifydc.conf file for editing
  2. Uncomment the dzdo.validator and set it to our scripts
    dzdo.validator: /usr/share/centrifydc/sbin/dzcheck.snow
  3.  Perform and adreload (or restart the agent)



We'll use a modified version of the sample script to check the requests for validity first, then we'll try to flush the cache using dzdo.

  1. Ticket does not exist  (ABC123)
    Request verification
    $ ./sncheck ABC123
    Request not found.
    $ dzdo adflush
    Enter the change control ticket number: ABC123
    Sorry, user dwirth is not allowed to execute '/usr/sbin/adflush' as root on engcen6.centrify.vms.
    # syslog contents
    Sep 20 18:00:52 engcen6 dzcheck.snow[35963]: Change control ticket number: ABC123
    Sep 20 18:00:52 engcen6 dzcheck.snow[35963]: User "dwirth@centrify.vms" will not be allowed to run "/usr/sbin/adflush" as "root" with ticket number (REASON:not found) "ABC123#012"
    Sep 20 18:00:52 engcen6 adclient[1526]: INFO  AUDIT_TRAIL|Centrify Suite|dzdo|1.0|1|dzdo denied|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=35961 utc=1474412452436 centrifyEventID=30001 status=DENIED service=dzdo command=/usr/sbin/adflush runas=root reason=Dzdo Validator checks failed. Do not permit to continue the privileged command.
  2. Ticket is not approved (RITM0010022)
    Request verification:
    $ ./sncheck RITM0010022
    number of requests=1
    Request number: RITM0010022
    Requested by: robertson.pimentel
    Date Created: 2016-09-16 16:55:06
    Approval Status: requested

    $ dzdo adflush
    Enter the change control ticket number: RITM0010022
    Sorry, user dwirth is not allowed to execute '/usr/sbin/adflush' as root on engcen6.centrify.vms.
    # syslog content
    Sep 20 18:03:04 engcen6 dzcheck.snow[36011]: Change control ticket number: RITM0010022
    Sep 20 18:03:04 engcen6 dzcheck.snow[36011]: User "dwirth@centrify.vms" will not be allowed to run "/usr/sbin/adflush" as "root" with ticket number (REASON:not approved) "RITM0010022#012"
    Sep 20 18:03:04 engcen6 adclient[1526]: INFO  AUDIT_TRAIL|Centrify Suite|dzdo|1.0|1|dzdo denied|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=36009 utc=1474412584884 centrifyEventID=30001 status=DENIED service=dzdo command=/usr/sbin/adflush runas=root reason=Dzdo Validator checks failed. Do not permit to continue the privileged command
  3. Ticket is approved (RITM001003)
    $ ./sncheck RITM0010003
    number of requests=1
    Request number: RITM0010003
    Requested by: diego.jimenez
    Date Created: 2016-09-11 14:57:57
    Approval Status: approved

    $ dzdo adflush
    Enter the change control ticket number: RITM0010003
    Demo Password:
    DNS cache flushed successfully.
    Authorization cache store flushed successfully.
    GC and DC caches expired successfully.
    The auditing service's name cache has been successfully flushed.
    The DirectAudit installation information cache has been successfully flushed.
    # syslog content Sep 20 18:06:22 engcen6 dzcheck.snow[36108]: Change control ticket number: RITM0010003 Sep 20 18:06:22 engcen6 dzcheck.snow[36108]: User "dwirth@centrify.vms" will run "/usr/sbin/adflush" as "root" with ticket number "RITM0010003#012" Sep 20 18:06:22 engcen6 adclient[1526]: INFO AUDIT_TRAIL|Centrify Suite|dzdo|1.0|0|dzdo granted|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=36106 utc=1474412782119 centrifyEventID=30000 status=GRANTED service=dzdo command=/usr/sbin/adflush runas=root role=UNIX Sysadmin/Global env=(none)


Benefits if you're using DirectAudit

If you have Enterprise Edition, DirectAudit's events will contain information about the Change Control and you can now search for all activity related to an individual change control number.



Benefits if you're using the Centrify Splunk App

The Splunk App will display reports on the reasons why the privilege elevation failed.  You can also add alerts based on this to identify any privileged user trying to fish.




This is a lab blog post, therefore this is just a simple concept, but here are the improvements I'd make:

  • Use OAth tokens for ServiceNow instead of a shared credential
  • Compare the date of execution with the change control date range (we only did simple checks)
  • Provide better feedback to the user interactively
  • Allow the user to create a request if it's not in the system and notify the approver (cli-driven workflow)


Quick Overview Video

 Notes:  ServiceNow, PCI DSS, SANS and ISO 27001 logos are registered trademarks of their respective owners.

Learn how to configure Cloudera Manager to use Centrify Server Suite and the included LDAP Proxy to authenticate Active Directory users and map Active Directory groups to Cloudera Manager roles.


[Mac] Logon banners for SSH

By Centrify Contributor I ‎09-12-2016 11:50 AM

Have you ever wondered if you can enable SSH logon banners for Macs, just as you can for UNIX/Linux?  With Centrify you can!  


LDAP Proxy, and You: A Definitive Guide

By Centrify Contributor I on ‎08-31-2016 02:12 PM - last edited ‎08-31-2016 03:02 PM

What’s an LDAP Proxy? When, how and why should you use one? These questions and more will be answered here.


Let’s start with the basics. What is it?


Centrify Server Suite agents (Standard or Enterprise) include an optional module called LDAP Proxy. This module consists of both a LDAP client and server (slapd) that works alongside the core adclient agent to provide a RFC2307 compliant LDAP interface in front of Active Directory. This is most commonly used in Hadoop environments to facilitate ldap/s communications during the security wizard as well as on-going user sync and authentication functions for ecosystem tools. It’s also very popular in storage device integrations that need to lookup uid/gid information for Active Directory users. But generally, anything capable of talking LDAP that wants clean zone data instead of complex AD queries can take advantage of this tool.


Why do we need it in the first place?


The simple answer is: even if these tools are capable of talking to Active Directory, most, if not all, expect to find POSIX data stored within the user and group objects they are targeting. Most include complex mapping sheets forcing admins to guess which AD attributes might be targeted. However, even if you know the correct attribute name, it’s more than likely the values of those attributes won’t be populated as expected.


There are several Active Directory bridging solutions that either have existed at one time or still remain but one fact has remained fairly consistent among all of our designs: mapping data is stored in dedicated serviceConnectionPoint objects, not the user or group objects they are associated with. So is true with Centrify. What is different about us, is we had the foresight to know this might cause issues for some integrations and created a proxy to make that problem go away. 


So what in the world is a serviceConnectionPoint object and what does that really mean?


In order for an Active Directory user to be authenticated by a Linux/Unix/Mac domain client using a Centrify agent (or any other), the user will first need basic POSIX properties associated with these operating systems: a user ID (uid), a user ID number (uidNumber), primary group number (gidNumber), home directory (unixHomeDirectory), and shell (loginShell). All of these attributes have been part of the standard Active Directory schema since Windows 2003 R2 so the good news is you don’t have to modify or customize your schema in any way to integrate non-Windows systems into Active Directory.


However, from a product design perspective, you have a few options. We could populate the target user or group object using the standard attributes with the appropriate values. However, if we do that, you’re stuck with that same mapping value across all systems that user may come in contact with. You also have to delegate full write access to the user or group object to administrators who may only need access to manage mappings. There are other cons here as well but the take away here is putting everything into a single object makes for a very limited product.


So we, and every other vendor to my knowledge, took the other route. We created a dedicated organizational unit structure and, for each mapping, used built-in serviceConnectionPoint objects to store the mapping details along with a pointer associating it to the securityID of the intended user or group (in this forest, that forest, wherever the user or group may live as long as there’s a trust). When the agent looks up the user, it’s programmed to look at the serviceConnectionPoint object for user details and follows the securityID trail to authenticate against the real user object. This data is all cached so it’s very efficient and very flexible when it comes to multiple mappings, delegation granularity and all the rest.


Problem solved, right? World peace is established, all programs everywhere can simply use PAM to talk to adclient and always be served up fresh data in exactly the format they need without worrying about the backend plumbing. Unfortunately, not…


The reality is most Unix based programs and appliances simply don’t have the experience integrating with Active Directory and even if they did, they probably wouldn’t design their integrations around what are mostly third-party designs. That leaves neatly secured systems in a tough spot when it comes to making all of this work together. That’s where the LDAP Proxy comes in.


Now, instead of pointing the app to Active Directory to look-up Unix details (and failing), as long as they include a compliant LDAP option, we can take all of the hard work away. App points to the proxy, makes its query, is given clean data from adclient cache, and we’re back to world peace status. Crack open a beer, kick your feet up, watch some Netflix; problem solved.


Not so fast. We have to set it up first. Fortunately, we made that pretty easy too. Most of this is already documented in various guides but I’ll consolidate here for you so it’s easier to find.


The first order of business is: to secure or not to secure? Silly question; of course we’re going to secure but it is worth knowing the option exists. The LDAP client and server are capable of talking straight LDAP over the traditional unsecured 389 port or can be encrypted via certificate to provide TLS security over port 636. Out of the box, 389 access is there but 636 takes a little work.


In order to use LDAP/S, you will first have to install an Active Directory-integrated Certificate Authority, create a new template for the LDAP Proxy and configure group policy to turn on auto-enrollment so the LDAP Proxy server can automatically enroll itself and have the necessary certificate files delivered to the system. I typically do all of this before joining the system so that as soon as I’m joined, I can get right into configurations. While writing this I discovered the handy little guide I’ve been using for months isn’t actually published to the documents library yet. I’m working on fixing that but in the meantime, if you don’t find the Auto-Enrollment Guide there, ask your favorite SE and we’ll happily send you a copy. Follow that, and then come back here.




Welcome back! Now that you have your CA and certificates, let’s move on to configuring both the client and server for TLS and other little tweaks.


If everything went well, you should now have three “auto” certificates sitting in /var/centrify/net/certs on your LDAP Proxy server:






OpenSSL needs the chain file to be in pem format so we’ll generate a fourth file from the existing file:


]$ [dzdo] openssl pkcs7 -in auto_LDAPProxy.chain -text -out auto_LDAPProxy_CA.pem -print_certs


Now you have four certificate files to work with. Next up, let’s configure the client and server to use TLS:


Let’s start with the slapd configuration file. Open up the existing file with your editor of choice, go to the end of the file and add a new section. If you want to be clean about it, you can create a new remark line as well as I’ve done here:


]$ [dzdo] vi /etc/centrifydc/openldap/slapd.conf


#TLS Configuration

TLSCACertificateFile   /var/centrify/net/certs/auto_LDAPProxy_CA.pem

TLSCertificateFile     /var/centrify/net/certs/auto_LDAPProxy.cert

TLSCertificateKeyFile  /var/centrify/net/certs/auto_LDAPProxy.key



Save that away, and we’ll do a similar mapping for the ldap configuration file. Same thing, just add this additional line to the end of the file. This one is much smaller so a comment line may not be necessary:


]$ [dzdo] vi /etc/centrifydc/openldap/ldap.conf


TLS_CACERT    /var/centrify/net/certs/auto_LDAPProxy_CA.pem


For this next step, we’re creating a whole new file to configure the start-up parameters for the LDAP Proxy server. The purpose here is to configure the listening addresses for the server. That way, even after reboots, your server is started with the correct configurations. Normally, I cover all my bases and configure both the ldap:389 and ldaps:636 for both ‘localhost’ and the fully qualified (DNS) name of the host running the server. In this example, I’ll make up a hostname called Simply replace that name with your own box name.


]$ [dzdo] vi /etc/sysconfig/centrify-ldapproxy


STARTUP_OPTS="-h 'ldap:// ldap://localhost:389 ldaps:// ldaps://localhost:636'"


We’ll do a quick restart of the service to pick-up these options. I’m using a centOS example so you may have to convert to the service management command that fits your operating system if it’s something else:


]$ [dzdo] service centrify-ldapproxy restart


Check the status:


]$ ps -ef|grep slapd


You should now see the service running with all of the start-up options we configured. If so, we are ready to test.


At this point, I’m also assuming you have an existing Centrify zone with some users and groups already mapped. We’ll use the LDAP Proxy to query all of our enumerated users and groups. Before we do that though, let’s discuss how the LDAP Proxy actually works.


The LDAP Proxy can proxy any query directly to AD but will intercept any queries for either posixaccount or posixgroup objects. In these cases, instead of forwarding the query to Active Directory, it will simply return the information from local cache instead. This is a great, easy way to dump your user and group data, already structured and filtered by zone mapping, without the fuss of having to figure out and crawl Active Directory. You can pass it a BaseDN but we’ll just ignore it and give you zone results no matter where the user actually exists.


We have an ldapsearch tool you can use to verify your results prior to an integration so let’s go to that working directory first:


]$ cd /usr/share/centrifydc/bin/


Next, let’s perform a query for all of our zone users, all attributes:


./ldapsearch -x -H ldaps://localhost:636 -D -W "(objectclass=posixaccount)"


Just as in our earlier example, you’ll have to replace the user and domain name with the credentials of an account with permissions to query AD. It will prompt you for the password after executing. In this example, our only filter is by objectclass equaling ‘posixaccount’ so the expected result is all zone users, all attributes since the proxy will intercept this query and return results from cache. If we change ‘posixaccount’ with ‘posixgroup’, the same will happen for all your zone mapped groups. If you want to limit the query even further, you could even search for a particular user/group or only a particular attribute of your users/groups. Here’s an example of such a query where we search for the uidNumber attribute of a user named clusteradm:


./ldapsearch -x -H ldaps://localhost:636 -D -W "(&(objectclass=posixaccount)(uid=clusteradm))" uidNumber


Here’s where it gets cool. The proxy server also includes a customizable mapping file, located here:




If you open that file, you will see how we map attribute names to cache items. Anything with an underscore in front of it, means it’s from cache. You can use this file to trick applications who are expecting a value in one format even though it may be something different in AD. This is especially useful if an application badly handles null results. We can stick in another value from cache and work around such issues.


That’s it. We’re done. Queue Eric Idle ‘Always Look On The Bright Side OF Life’ and get back to that beer.


Hopefully you found this helpful. If you have any questions, please feel free to contact either me or your local SE and we would be happy to work with you on this or any other Centrify issue.



Showing results for 
Search instead for 
Do you mean 

Community Control Panel