Basics: Strategies for UNIX Identities with Centrify

Background

In lab 8b, we UNIX-enabled some of the users of our test environment and accessed one of our systems. Here are the session results:

The screenshot above outlines some of the issues that will be encountered when a system is integrated in to Active Directory with Centrify and the users are UNIX-enabled with a proper planning exercise.  For our purposes this is OK, because we need to understand why planning and design exercises should be done.  After all, not everyone is a UNIX/Linux identity management expert.

Duplicated Identities

An identity conflict happens when a key user field (like login or UID) are duplicated.  In the example above the OS (CentOS/RedHat) was designed to be smart enough to warn the user about this, but this is not true of all UNIX and Linux distributions.  This problem has a trickle-down effect in many aspects.  Let's look at the root cause in depth, the culprit is the Name Server Switch (NSS) framework.  Let's look at an excerpt of the file /etc/nsswitch.conf in that system:

passwd:        centrifydc    files
shadow:        centrifydc    files
group:         centrifydc    files

All this means is that any NSS-enabled program will look first at the centrifydc source (in our case Active Directory) and if there's an identity match (for login in this case) this will be the identity picked.  CentOS was just smart enough to continue checking and letting us know that there was a match in the local /etc/passwd too.  This was verified with the subsequent command (getent) that returned a UNIX-enabled jmatthews with an AD SID-derived UID (1149240406) and the local jmatthews with UID 503.

This is true regarding the different sources that a system may have.  In complex environments you could have local databases, OpenLDAP directories, Network Information System services, etc.  It can be as complex as this:

passwd:        ldap nis  files db

In this case, any NSS-enabled program will check LDAP, then NIS, then local files, and so on for users.
This issue is very broad, because it not only applies to users (passwd), but to groups too and with all NSS-enabled programs like login, passwd, sshd, sudo, etc.

The next problem that happens has to do with file/folder ownership.  Notice that our user was unable to change folders to the home directory, in turn he is unable to read his basic environment settings!!!!  This has direct-impact in the productivity of the user, and most likely people will have to get involved to do a change of ownership of files and folders.  This is extremely inefficient.

A final, but important issue has to do with usability.  The user does not have any visual cues to find out the context of the user that he is working with.  Is this the local or the AD account?  We can finish this with some group policies.

The reasons outlined above are why companies with mature identity practices for their UNIX systems do a rationalization (normalization or flattening) of their namespace.  Users have unique login names and UIDs.  Many solutions in the market require organizations to rationalize their namespace prior to implementing the solution, but with Centrify that is not the case.  This is where Active Directory and Centrify Zones come into play.  The following video illustrates how we resolve this one-off:

Strategies for UNIX User Identities with Centrify

The correct strategy depends a lot on the current environment of the customer, but, the preferred strategy is typically the end-state for the majority of the deployments: a normalized user state. The biggest constraint is that the business must go on and there are impact assessments and change-control windows to work with.

A New World of Flexibility with Centrify

Centrify allows for UNIX user identities to be defined at the Zone level, Child Zone (CZ) level and Server level.  This means that a user that is uniquely known in AD as jmatthews@corp.contoso.com, in UNIX, then can have these identities:

Level/Field	Login	UID	GID	GECOS	Home	Shell
Zone (HQ)	jmatthews	1149240406	1149240406	%{u:displayname}	%{home}/%{user}	%{shell}
CZ (Marketing)	jessie.matthews	(same as above)	(same as above)	(same as above)	(same as above)	(same as above)
Server (SOL1)	jmatthew	101	101	Jessie SysAdmin	/exports/home	/bin/bash

Notice that the user's identity was defined with the basic defaults, the login name overridden at the child zone level, and then the whole identity revamped at the Solaris server level.  Notably a truncated login name, more friendly UID/GID as well as defined Home and Shell fields.  Flexibility can be a two-edge blade because it allows for exceptions at multiple levels, and this is against two important Information Technology principles: standardization and simplicity.

Note:  The following strategies assume that the previous questions about AD-domain design, naming conventions, Zone structure, Computer Groups, Roles and Rights and naming conventions have been discussed.

The Recommended Strategy:  Normalize now and have peace of mind

1. Perform a table-top exercise to normalize your users and groups.
2. UNIX-enable (or migrate) all users at the zone level with a unique login and a UID generated from SID
3. Perform any role assignments at the Zone, Hierarchical Zone and Computer Role levels.
4. Pre-create all the UNIX computer accounts in Active Directory
5. Place the computer account in their corresponding Computer Role
6. Join the UNIX/Linux Systems to Active Directory.
7. Run the adfixid utility
8. Run the adrmlocal utility

This strategy works if you have committed to fixing this problem and are thinking about the future.  Maybe there are mergers and acquisitions in the future and the namespace is uncertain.  The drawbacks are that the identity rationalization exercise is lengthy and the implementation requires wide change-control windows.  The biggest benefit is that as new systems come online, there's a clean-slate across the board.

Another option:  Obtain results now and normalize later

Use this strategy if you are confident in the existing namespace

1. UNIX-enable all users at the zone level with a unique login and a UID generated from SID
2. Perform any role assignments at the Zone, Hierarchical Zone and Computer Role levels.
3. Pre-create all the UNIX computer accounts in Active Directory
4. Place the computer account in their corresponding Computer Role
5. Override all user identities at the system level (to their existing login/UID/GID)
6. Join the UNIX/Linux Systems to Active Directory.
7. Use the adrmlocal utility
8. Normalize opportunistically (with adfixid) or as new servers come online.

This strategy is the fastest path to productivity, however it does not solve the identity issues right away.  If you haven't done so, you may be forced to rationalize accounts that are using exported filesystems.  This allows for waves of systems to be normalized if needed.

Status Quo:  Be stubborn and reactive

1. Perform a user migration from an existing source (NIS, files, etc.) making sure you conserve the existing identity at the Zone
2. Perform any role assignments at the Zone, Hierarchical Zone and Computer Role levels.
3. Pre-create all the UNIX computer accounts in Active Directory
4. Place the computer account in their corresponding Computer Role
5. Join the UNIX/Linux Systems to Active Directory.
6. Use the adrmlocal utility to remove local users (if local) or clean your network-based (NIS) files
7. If inconsistencies are found, perform local-level overrides.

At the user level, a typical inconsistency is that a user may have different identities in different servers. E.g. in our test environment.  jmatthews has UID 503 on cen1, UID 1001 on suse1 and UID 101 on sol1.
Although this is possible, it's highly inefficient and promotes the same disadvantages of local administration:  non-standardization, exceptions and more exposure.  Unfortunately, this administrative model was highly promoted by Classic zones.  Use this model if you are politically defeated.