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.

Basics: How users are identified in UNIX and in Active Directory

In UNIX:  UIDs and more...

UNIX users are identified in the system by their user identifier (UID for short), but a complete UNIX identity has more than that.  For a simple structure, it has stood the test of time:

1. Login name:  this is basically the user account in understandeable format.  Login names are important subjects of planning, because in there are older versions of UNIX that don't like more than 8 characters in the login name.  
2. UID:  user identifier or unique identifier.  This is the number that the OS assigns to files/folders,  processes for permissions, etc.  Typically UIDs from 0 to 100 are reserved.  The root account has UID 0.
3. Group ID or GID:  This is the default group that the user belongs to.  In modern systems, there's a concept of the auto private group, this means that users by default belong to the GID that matches their UID.
4. GECOS field:  Typically the description field.  For humans is just heir Display Name and other information like their phone extension. 
5. Home Directory:  Location of the users's files.  Typically /home, or /exports/home or whatever the standardized location for users is.
6. Shell (or login Shell):  The command interpreter for the end user.  This field also requires a bit of planning because not all shells may be installed in all systems.

User identity information in stand alone systems is stored in the /etc/passwd file.  The format is as follows:

Login name : Encrypted Password (deprecated) : UID : GID : GECOS : Home Path : Shell Path

Example:
login: Jim
UID/GID: 305
GECOS: James T Brown
Home: /home/jim
Shell: /bin/bash

jim:x:305:305:James T. Brown:/home/jim:/bin/bash

Ahhh simplicity!!!!

In Active Directory:  UPNs and more....

Active Directory does things a bit different, as an LDAP directory it uses a lot of X.500 legacy fields, but for the purposes of simplifying the process, here are the key fields:

Note:  When you create a user in AD, all you need to specify are the User logon name, either a name, last name or middle initial and a password.  However, it's a little bit more complex than this.  It will create these key fields:

1. User Principal Name or UPN:  typically in the format of <user>@ad-domain-name 
2. sAMAccountName: This is the account's short name (<20 characters)
3. System Identifier:   In AD speak, the system identifier is called ObjectSID.  It contains the unique domain identifier, plus a globally unique identifier.

However, if you look at our user Jim, here's all the information that was added just by typing the default info:

Dn: CN=Jim Brown,OU=IT,OU=Staff,DC=contoso,DC=com
accountExpires: 9223372036854775807 (never);
badPasswordTime: 0 (never);
badPwdCount: 0;
cn: Jim Brown;
codePage: 0;
countryCode: 0;
displayName: Jim Brown;
distinguishedName: CN=Jim Brown,OU=IT,OU=Staff,DC=contoso,DC=com;
dSCorePropagationData: 0x0 = (  );
givenName: Jim;
instanceType: 0x4 = ( WRITE );
lastLogoff: 0 (never);
lastLogon: 0 (never);
logonCount: 0;
name: Jim Brown;
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=contoso,DC=com;
objectClass (4): top; person; organizationalPerson; user;
objectGUID: 6698f079-e870-43be-9c14-02260dfbafff;
objectSid: S-1-5-21-3571224596-3006733700-3057749774-1297;
primaryGroupID: 513 = ( GROUP_RID_USERS );
pwdLastSet: 12/10/2013 9:28:34 PM Eastern Standard Time;
sAMAccountName: james.brown;
sAMAccountType: 805306368 = ( NORMAL_USER_ACCOUNT );
sn: Brown;
userAccountControl: 0x200 = ( NORMAL_ACCOUNT );
userPrincipalName: james.brown@contoso.com;
uSNChanged: 282804;
uSNCreated: 282799;
whenChanged: 12/10/2013 9:28:34 PM Eastern Standard Time;
whenCreated: 12/10/2013 9:28:34 PM Eastern Standard Time;

Notice that there are significantly more fields created.  A lot of them are internal, others iexternal, like the DN. This is the x.500 format of the directory location of the object.  It says that the user object is in the Organizational Unit IT, under the OU Staff.

Depending on how the Active Directory schema has been modified, it's possible that more fields are added by default.  For example, on an AD that has been modified for Microsoft Exchange, depending on how things are set up, an e-mail address may be provisioned.   Notice that the e-mail address can be different (or the same) as the UserPrincipalName.

So what is a Schema then?

In the context of databases a schema simply specifieswhich attributes can be defined.  It's also known to old System Analysts like me like a Data Dictionary.  The best way to illustrate it is with an example.  

The white pages has a very simple schema:

Lastname, First Name

Address

Phone Number

Suppose that tomorrow a decision is made to include e-mail addresses in the  white pages.  The schema of the white pages has to be "extended" to accommodate e-mail address.  This means that we have to think

a) How many characters can we allow before the @ symbol?

b) Are we going to validate that the domain is valid?

All these decisions have impact on the size of the white pages database.  If tomorrow the White Pages team realizes that nobody will use their service to find email addresses, the database will have been extended and another project has to be initiated to eliminate this field.

In my previous post, I discussed that the Windows Administrator is worried about the use of proprietary schema extensions in AD, because the more schema extensions, the larger the AD database can be and if the product does not cut it, there's no way to go back in and remove those extensions.

In practical terms, there are two mitigating factors about the size concern:  the bandwidth in corporate networks and the database technology in AD  (Extensible Database Engine or ESE) that only replicates the deltas (but that's a topic for another post).
However, the concern is perfectly legitimate when it comes to proprietary extensions.  Can the solution guarantee success?

Centrify's Approach to UNIX Identities in Active Directory

The benefit of using Centrify is that it leverages schema extensions existing in AD since version 31 (Windows Server 2003 R2) specifically RFC 2307.  So do not worry Windows admins, no schema extensions required;  when you combine this with Centrify's proprietary Zones, System Administrators have a very flexible model that allows for a robust UNIX Identity Management model that can satisfy the needs of the most complex enterprises.

UNIX Profile properties for an end user in Centrify Access Manager