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.

Terminology

• 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.

Strategies

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:

• Migrating from /etc/users
• Migrating from /etc/group
• Cleanup with the adfixid & adrmlocal utilities by @tchariya

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 $user.name –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}"
>show
Bindings:
        centrify.vms: dc.centrify.vms
Current zone:
        CN=RFC,CN=Zones,OU=UNIX,DC=centrify,DC=vms
Current nss zone user:
        wanda.web@centrify.vms:wanda.web:134217728:134217728:Wanda Web:%{/home}/%{user}:%{shell}:
Forests have valid license:
>save_zone_user

adedit is a deep topic.  Here's the documentation:  https://docs.centrify.com/en/css/suite2016/centrify-adedit-guide.pdf

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.

Conclusion

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.