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

Part I | Part III

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.


Testing and Troubleshooting Centrify's DB2 plugin

By Centrify Contributor I 2 weeks ago - last edited 2 weeks ago

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.


Installing DB2 Express-C on Linux and configuring the Centrify DB2 plugin

By Centrify Contributor I on ‎10-21-2016 09:09 AM - last edited 2 weeks ago

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.


The Centrify LDAP Proxy - From Installation to testing in under 1 minute

By Centrify Guru I on ‎09-28-2016 08:14 PM - last edited yesterday

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.



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.


First article is presenting few examples of the three possible scopes for Role Assignments.


This article is a continuation an blog post I started last month about how Centrify supports multiple schemas to store UNIX information in Active Directory.  We also discussed the challenges with UNIX namespaces, the type of schemas supported by Centrify Server Suite and strategies for discovery leveraging PowerShell and other tools.


[Basics] Centrify Zone schemas, UNIX identity data sourcing and provisioning - Part I

 In this part of the article we discuss strategies on how to source UNIX identity information into Centrify Zones in Active Directory.



  • Sourcing: extracting identity data and injecting from source to destination.  I don't mean synchronization.  This is meant to be a one-time thing.
  • Provisioning:  Once identity migration happens, provisioning are the operational add/moves or changes.



Centrify Standard Edition for UNIX implementations consist of analysis and design work to migrate (source) and operate (provision).  Organizational goals vary and must balance project and production needs. 


Let's picture an organization with this makeup

In this case we have an organization that needs to maintain an old namespace because of legacy UNIX systems, however a big mistake that I see in many of our customers is not closing the project correctly.


In this scenario there should be a strategy like this:

For the migration

  • Linux systems are going to be normalized and migrated, users keep their usernames and UID/GIDs if aligned with current username standards.  Duplicates will be taken care of.
  • The AIX systems will be migrated to the Centrify DB2 Plugin that can take care of the existing challenges.  This is within a 3 month of Centrify operations.  A new child zone will be created for this purpose, during migration this will be overriden at this level. 
  • The HP-UX systems will be retired with application attrition.  The vendor is out of business and management has given two years to find a replacement (most likely web-based).  This can be handled with a child zone or local overrides.
  • Old NIS Maps:  The old nis maps will be maintained using the Centrify NIS proxy, but the application that relies on YP will be decommisioned in a year.  To compensate for the unencrypted traffic, Centrify DirectSecure will be implemented.

For operations

  • Users will get a unix login name based on their AD username
  • GIDs will be long integer numbers that are derived from the AD SID

Notice the clear end of the legacy operations.   Unfortunately, in the field this is not the reality;  many times organizations end-up carrying legacy problems for years.


Now let's talk about how to source and provision data for migrations and operations.


Sourcing Data Into Centrify Zones

Centrify zones can source data using different options.  Flexibility is the key here. Ultimately, a tool that uses the Centrify APIs is required to insert data into zones.  

The tools available are:

  • With Centrify Access Manager (mmc snap-in)
    • Manually using the zone defaults
    • Manually using the import wizard
  • Centrify DirectManage PowerShell
  • Centrify adedit
  • Centrify Zone Provisioning Agent
  • Custom programs that use the Centrify DirectManage SDK

Using the Zone Defaults

Each zone can be configured to provide information from default values.  The options are:

  • Login name:  defaults to the AD username (sAMAccountName) - it can be truncated.
  • UID can be:
    • Not defined:  no value provided (requires manual intervention)
    • Auto-incremented:  this lends itself to collisions
    • Generated UID from SID: provides a unique 32-bit integer number generated using Centrify's algorithm
    • Use Apple UID Scheme:  provides a unique 32-bit integer generated using Apple's algorithm
    • RFC2307:  You need the 2016.1 version of AM to see this, but this option is quite useful to source existing RFC2307 data.


Import Wizard

The import wizard can process UNIX identity data from local files or a NIS directory.  The key is to arrive to a consolidated set of files and that the inconsistencies are understood.

Our professional services teams provide sets of of scripts to identity anomalies with user/group identities and once a consolidated /etc/passwd or /etc/group file has been identified, then the fun can begin:

Another benefit of the import wizard is that combined with the getent command, provides a fast way to onboard users and groups from 3rd parties.  This video should illustrate what I mean.


This topic has been covered as well in different entries:

DirectManage PowerShell

Active Directory PowerShell Modules can be combined with DirectManage PowerShell for some interesting sourcing/provisioning options.  For example:  You can identity all users with posixAccount information (generally those that don't have the uidNumber populated).

If using a Centrify Standard or RFC2307 zone, you can use this information to provision data into the zone.


$zone = Get-CdmZone -Name RFC
$posixinfo = Get-ADUser -Filter * -Properties * | Where-Object {$_.uidnumber -ne $null} | Select-Object  UserPrincipalName, SamAccountName, name, uidNumber, gidNumber, unixHomeDirectory, loginShell 
Foreach ($user in $posixinfo)
New-CdmUserProfile -Zone $zone –User $user.UserPrincipalName -Login $user.SamAccountName  -Uid $user.uidNumber -PrimaryGroup $user.gidNumber –HomeDir $user.unixHomeDirectory –Gecos $ –Shell $user.loginShell

 Alternatively, if you're using an SFU zone and the information is normalized, you only need to update the msSFU30NisDomain attribute to the NIS domain set for the zone in the particular domain. 


$zone = Get-CdmZone -Name SFU30
$nisdomain = $zone.NisDomain
$posixinfo = Get-ADUser -Filter * -Properties * | Where-Object {$_.uidnumber -ne $null} | Select-Object UserPrincipalName, SamAccountName, name, uidNumber, gidNumber, unixHomeDirectory, loginShell Foreach ($user in $posixinfo) { Set-ADUser -Identity $user.SamAccountName -Replace @{msSFU30NisDomain =$nisdomain} }


Zone Provisioning Agent

ZPA is a utility provided for automatic provisioning.  It relies on AD Security groups as the "source" and based on group memberships the service will provision UNIX user or group identities.  ZPA options extend the options seen on the zone defaults.

ZPA can be viewed as a provisioning utility rather than a "sourcing" tool.


Centrify adedit

adedit is a TCL-based utility that can be used to modify Active Directory data and it powers many of the operations performed by the centrify's adclient.


Here's an example of user provisioning:


>bind centrify.vms
>select_zone "cn=rfc,cn=zones,ou=unix,dc=centrify,dc=vms"
>new_zone_user wanda.web@centrify.vms
>set_zone_user_field uname wanda.web
>set_zone_user_field uid 0x8000000
>set_zone_user_field gid 0x8000000
>set_zone_user_field gecos "Wanda Web"
>set_zone_user_field home "%{/home}/%{user}"
>set_zone_user_field shell "%{shell}"
        centrify.vms: dc.centrify.vms
Current zone:
Current nss zone user:
        wanda.web@centrify.vms:wanda.web:134217728:134217728:Wanda Web:%{/home}/%{user}:%{shell}:
Forests have valid license:

adedit is a deep topic.  Here's the documentation:


Centrify DirectManage SDK

The directmanage SDK provides the ability for developers to write their own apps for sourcing or provisioning.  The best resource to find documentation and other resources is to leverage the Centrify Developers page.  The sample applications are in the Suite.  Access Manager, Zone Provisioning Agent and the migration wizards are all created using the SDK by Centrify developers


There are also customers making very innovative use of these resources.




The key to current customers and prospects is flexibility.  Regardless of where and how complex your organization's UNIX identity data is, Centrify offers the deepest options to seamlessly integrate to your existing Active Directory regardless of deployment.

A common category of questions we get from Centrify prospects and customers is around UNIX identity storage and options for sourcing.  The most frequent is:  How do we get UNIX identity data to your solution?

I typically tend to answer:  Where does your UNIX identity data resides?
The answer to this question varies.  I've heard all kinds of responses, including silence or arguments between team members.  Ultimately it boils down to two categories:


Rationalized(*) Not Rationalized
  • There is a naming convention established and the convention is enforced
  • A directory may or may not be in place  (e.g. LDAP, NIS, etc)
  • Every user has a unique login, UID and Primary Group
  • Every UNIX group is defined with the same unix-name and GID, has the same meaning and group members
  • There is typically a unified strategy for multi-protocol filers
  • There is a unified (or centralized) sudoers files
  • The naming convention is spotty or non-existent
  • A directory may or may not be in place  (e.g. LDAP, NIS, etc), but there are pockets of "other stuff"
  • Users may have different naming for login or different UIDs  (e.g. jdoe (501:501) vs john.doe (10001:1)
  • Groups may have different unix-names, different GID numbers, members or meaning.
  • Centralized sudoers files may or may not exist or contain outdated information.

(*)Note: "Fully-rationalized" is typically an aspiration.  Organizations may have historical or legacy reasons as of why they may keep older systems that do not conform to the standards (and yes, Centrify has you covered).


Other questions that follow are:  Will you be using the SFU or RFC2307 fields? What are these zones that you speak of and what are the AD implications?  Can you make use of my existing UNIX information?  How painful (or painless) will the process be?


The answer to the last question varies between organizations.  Some organizations believe the process will be cumbersome and choose to continue with the status-quo (after all, their problems are well documented); others make the painful decision to not get help or training (a decision that really baffles me).


This article explores the different schemas used by Centrify Zones and provides an overview of sourcing options. The topic is very relevant due to the following facts:

Having a solution that provides flexibility, especially in such an important capability that is the foundation to secure critical systems is key for large enterprises.  Let's get started.



  • UNIX identity data consists of login, UID, GID, Home Directory, Shell and GECOS.
  • Centrify Zones leverage Active Directory to provide Identity Management for UNIX, Linux and Macs and Role-Based Access Control + Privilege Management for UNIX, Linux and Windows.

UNIX identity may reside on:

  • Local /etc/passwd and /etc/group files on each individual system (could be the same for /etc/sudoers)
  • Network-based passwd and group files on LDAP or legacy NIS directories (same for /etc/sudoers)
  • In Active Directory in the msSFU30 fields (pre-Windows 2003R2) or the RFC2307bis (after Windows 2003R2) and are attributes of the posixAccount class.
  • In other LDAP-like directories that rely on synchronization (e.g. Oracle, Red Hat, Apple or other third party software, etc)


Centrify Data Storage: Zones
Identity data is inside the Centrify Zone.  A Zone is a set of AD objects that consolidate identity and privilege information.  Centrify identity data is stored on a serviceConnectionPoint linked to the user or group object.  This chalk-talk covers this information in detail.


  • Provides the ability to limit the visibility (and access) of users/groups in different contexts.
  • A user (or group) may have different identities in different contexts (especially useful in M&A activities or consolidations)
  • Provides the capability to group systems (teams of servers) using different options
  • Its structure is hierarchical, provides inheritance and object reuse
  • Aligns organizations with the principle of separation of duties
  • Multi-platform (allows the grouping of UNIX, Linux, Windows and Mac systems)
  • Highly-scalable (overcomes the limitations of other schemes like Auto Zone)
  • Provides support for different schemas (SFU, RFC2307) and UID/GID Schemes


Types of Zones and Schemas
Zones can be Classic or Hierarchical.  Because Classic zones are no longer the best practice, they exist for backwards compatibility.  In the rest of this article, a Centrify Zone is always considered to be a hierarchical zone.


Centrify Standard Schema: UNIX attributes are stored in the keywords multi-valued attribute of the user or group's serviceConnectionPoint

The standard schema was very useful, especially in old Windows 2000 deployments.

Here's how to create a Standard zone using Centrify DirectManage PowerShell:

$cont = "cn=zones,ou=UNIX,dc=centrify,dc=vms"  #substitute with your container DN
New-CdmZone -Name Standard -Container $cont -Schema standard -Type hierarchical

SFU Schema: UNIX attributes are stored with the user or group object and the msSFU30NisDomain is populated based on the zone's NIS domain setting.

Using the SFU schema allows the automatic sourcing for all users that have the RFC2307 UNIX fields populated along with the the msSFU30NISDomain attribute.  The drawback is that you must have rationalized your environment and overrides won't be possible (more about overrides below).



$cont = "cn=zones,ou=UNIX,dc=centrify,dc=vms" # substitute for your container DN
New-CdmZone -Name SFU30 -Container $cont -Schema sfu -NisDomain SFUX -SfuDomain centrify.vms -Type hierarchical

When planning to use SFU as a schema, you are bound by the limitations of having the data with the AD object, most notably UNIX names.  You cannot have identity overrides (for example, changing the UNIX name of a group).  This is illustrated below:


RFC2307-compatible schema:  UNIX attributes are stored with the serviceConnectionPoint that defines the user or group.



$cont = "cn=zones,ou=UNIX,dc=centrify,dc=vms" # substitute for your container DN
New-CdmZone -Name RFC -Container $cont -Schema rfc -Type hierarchical


Tips on Discovering UNIX Data

Due to the fragmented nature of heterogeneous environments (and the fact that they've been around for a long time), information seems to be all-over the place, but here are many tips.


  • UNIX Identity data in files (/etc/passwd or /etc/group) may have different inconsistencies like:
    • unix users with more than one UID
    • unix users with more than one GID
    • unix users with multiple unix names
    • unix users with different shell or home directories  (e.g. /home/user vs. /exports/home/user)
    • unix groups with more than one GID
    • GIDs with different group names
    • unix groups with different group memberships
    • sudoers files with non-existing groups, aliases or unix names

Identifying this information can help with the identity rationalization process.


  • UNIX Identity data in Active Directory
    • Different schemas (SFU vs RFC2307)
    • Multi-domain forrests with inconsistent NIS domain data
    • AD data that is no longer relevant

PowerShell Discovery Query (RFC2307)

Get-ADUser -Filter * -Properties * | Where-Object {$_.uidnumber -ne $null} | Select-Object  UserPrincipalName, SamAccountName, name, uidNumber, gidNumber, unixHomeDirectory, loginShell | Format-Table 


Conclusion for Part I:

Part of the reason why Centrify has been successful is the flexibility of our toolset, the experience of our Professional Services organization, our willingness to listen to our customers and the consistent investment on the product. 


The benefits of having a unified namespace while using a common infrastructure are critical for security, functionality and productivity.  In the field we still see many organizations struggling with this core concept.  With Centrify enterprises are covered not only on a family of Linux systems, but in critical UNIX systems that run AIX, HP-UX, Solaris, OS X and other commercial Linux distributions.


In part 2, we'll discuss some options on how to source data into Centrify zones using multiple toolsets.

Showing results for 
Search instead for 
Do you mean 

Community Control Panel