11 April,19 at 11:50 AM
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.
In this part of the article we discuss strategies on how to source UNIX identity information into Centrify Zones in Active Directory.
Terminology
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
For operations
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:
Using the Zone Defaults
Each zone can be configured to provide information from default values. The options are:
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 $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.