Basics: Centrify Zone Schema Types and Identity Sourcing - Part I

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:

• Microsoft's deprecation of Identity Management for UNIX and Services for NIS
  https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/
• Limitations of current OS-native alternatives and less investment from alternative 3rd. parties.

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.

Basics

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

Benefits:

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

PowerShell:

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


PowerShell:

$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 forests 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.