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 |
|
|
(*)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.
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.
- 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
- 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
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.
