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

standard zone.png

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.

sfu zone.png

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.
rfc zone.png



$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