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.

Basics: The Centrify Agent Cache

Background

In a previous post we described the Centrify agent (adclient) and we mentioned that the cache exists for two objectives:  performance and offline access (availability control in case AD is not accessible). Understanding the cache allows any system administrator to be more effective at using the solution.   The client caches DNS, object and authorization information.

The NSCD service

NCSD stands for name server cache daemon.  It is the best method to retrieve cached information since it's implemented and optimized for each version of UNIX/Linux.  As a basic computer science principle, retrieving items from memory is always preferable than retrieving from permanent storage. The rule of thumb is to always implement NSCD in your systems.  This is a very important design consideration.

The best thing you can do to improve performance of any application that uses Name Server Switch is to implement NSCD.  This applies to Centrify for Unix/Linux.

The Object cache

This cache stores the UNIX-enabled users and managed groups that belong to the client's zone. It's implemented as a database that is stored in the /var/centrifydc folder.  It is used so the client does not have to go to Active Directory for each query and provides support for offline access.

Object expiration and refresh intervals

When objects are retrieved they are tagged with a time-stamp and some of the AD information is retrieved (mainly the update sequence number), while the refresh interval is current, the object will be returned "as is" (no queries to AD are made), if the refresh interval expires, then the object's USN is compared to 

the one in the cache, only if the numbers are different the object will be refreshed, otherwise the time-stamp

is renewed.

The notable exception to this logic is when an end-user attempts to log in; at this point (among other things)
the validity of the account is checked (e.g. is the account disabled, locked, expired, allowed to log in at the time, etc) those checks are performed in real time.
Although there are more parameters to fine-tune the cache, the adclient.cache.expires interval governs when objects are expired. Traditionally, by default is set to 1 hour.

The Authorization Cache

This cache is used for the purposes of authorization (roles, rights etc) and it's separate from the object cache.
It uses the AD azman schema and Centrify algorithms to determine if there are changes to the group memberships (or principals) that have roles and rights tied to them. It uses the USN and the adclient.azman.refresh.interval (set to 30 minutes by default).

Depending on the complexity of the AD infrastructure, the operation can be expensive (in terms of LDAP queries) this is because corporate domains are complex and in certain scenarios it's possible that groups are merged.  Since the memberships are fully enumerated, this is something to think about.

How the Authorization Cache affects the User's ability to log in

Notice that before we have mentioned that for a user to log in they require two things: A UNIX identity, and a role that allows them to log-in. One component relates to identification, the other relates to authorization.
This means that it's possible to have a proper login, UID, GID, etc; but still be unknown to a system because the user does not have a role assigned or the role that is assigned doesn't have a PAM login right.

Note that users can be "listed" in a system.
There are other types of cache, but the two most relevant are the Object and Authorization caches.

What does this all mean?

It means that there's a fine balance to be understood in order to provide performance and high-availability. It also means that there are planning implications to the workings of the agent.  Questions like:

• What is this system used for?
  Very different settings for a shared developer's system than a slave node in a number-crunching system.
• What are the current provisioning/de-provisioning SLAs?
  This opens a great question.  The SLA dictates a lot of settings.  For example in a scheme in which users are provisioned using an IdM solution from an HR system, and there are workflows involved to approve access to UNIX/Linux systems, all components have to be accounted for, Including Active Directory replication intervals.

Adfush described

Adflush is a command line utility that allows system administrators to manipulate the cache.  It shouldn't be used without understanding how the cache works.  

usage: adflush [options]

options:

  -f, --force             flush cache even adclient is in disconnected mode

  -a, --auth               flush cached authorization data

  -d, --dns                flush the adclient dns cache and DC locator cache

  -e, --expire             expire everything in the DC and GC object cache

  -o, --objects            flush only the DC and GC object cache

  -t, --trusts             rediscover the trusted domains

  -b, --bindings           force refresh binding

  -v, --version            print version information

  -V, --verbose            print debugging information

  -h, --help               print this help information and exit.

The type of adflush can have implications from slowing things down a bit, to consuming resources to actually eliminating the ability to log-in offline.  This is important to know for roaming users of Macintosh platforms.  A user that runs a forced adflush while at home will have to wait to get back to the office to log in!!!

Basics: Managing UNIX groups from Active Directory with Centrify

Background

With Centrify, UNIX group membership can be managed from AD Security groups.  There's basically a 1:1 mapping between the AD group and the UNIX group.
Note:  In version 2016 of Server Suite, Centrify has added the ability to manage local UNIX groups. Here's a post on how to test the feature: http://centrifying.blogspot.com/2016/01/labs-testing-local-account-management.html

Planning

UNIX groups may be used for different purposes, may contain different members and can mean different things for different administrative groups.  The most important goal is standardization in management, therefore the system administrators have to get together to answer these questions:

• What is this group used for? Why?
• Is this group still relevant?
• Will this group be deprecated by any of the authorization components?
  This is very important, for example, Netgroups are not needed anymore with Centrify zones and Computer Roles.  The other important note is that Role Assignments eliminate the need to maintain UNIX groups for the purpose of sudo usage.
• How many groups are uniquely identified?
• Are there any groups that are defined differently in other systems?
• Are the group memberships uniform?  Are there groups that have network and local users?
• Is this a primary group for all  or a set of users?
• What is the impact of changing the definition?
• What is the impact of the unavailability of the group?
• Is the group in AD going to be managed manually or with a tool?
• Are there any workflow and approvals required?
• Is the group subject to any attestation exercises?
• What will be the naming convention for the AD group that corresponds to the UNIX group?
• What is the scope of the AD group (Domain Local, Domain Global, Universal)?

All these questions need to be answered with a catalog of groups, definitions, members, etc. in a serious table-top exercise.  Because groups are units of identity management, the decisions made here can affect zone design.  

A common issue seen in the field is that a group is part of a legacy infrastructure not understood by the current management team, therefore they decide to keep the status-quo and not compromise on governance, naming or GID to be assigned, this adds complexity rather than understanding the real impact of the group.

For example:

UNIX Group:  db2-dba

UID: 1001

Group Membership:  Includes local account db2inst.
Note: This means that the agent has to be configured to merge NSS group memberships.

Purpose: Used to identify the db2 Database Admins.

Any different definitions:  No

Managed:  Manually

Attestation:  Yes

AD Standards:
                        AD Group Scope:  Domain Local
                        AD Container: UNIX Groups,
                        AD Naming Convention: UNIX-<Zone Name>-Unix Name.   UNIX-HQ-DB2 DBA

Creating the Group Mapping (Do)

Creating the UNIX Group

1. In Access Manager, go to the Zone/UNIX Data and right click Groups and select Create UNIX Group
2. In the Find window, find the corresponding UNIX group (e.g. UNIX-HQ-Wheel), select it and press OK
3. Set the UNIX name (preferable  8 characters depending on platform(s) to be supported) and set the GID.
   
   
   

Populating the Group

1. From ADUC, find and open the group, go to the members tab, click add and add any user principal that has been UNIX-enabled.
2. From Access Manager, right click the UNIX group, select AD properties and follow the steps outlined above.
3. From UNIX using adedit:
   a) Log in to UNIX/Linux with an account that can modify the group (or use kinit) and open adedit.
   b) bind to the domain
   >bind corp.contoso.com
   c) add the ade_lib library
   >package require ade_lib
   c) use the add_user_to_group function
   >add_user_to_group "jessie.matthews@corp.contoso.com" "UNIX-HQ-DB2 DBAs@corp.contoso.com"

Note:  Remember that you can use an Identity Management tool, a script (VB, PS) to populate an AD Group.

Process Reuse:  Now your organization can reuse the existing process and tools to manage the memberships to UNIX systems.

Verifying the Membership (Check)

You can always get a snapshot of the Members tab of the AD Group, however, here are some alternatives.

On UNIX with the getent command

1. Log on to a system in the zone that the UNIX group was created.
2. Use the getent command.  E.g. (for db2dba)
   $ getent group db2dba
   db2dba:x:1001:jessie.matthews

On UNIX with the adquery command
This report is great because it can mix the AD and local users if the agent was configured to merge them.

1. Log on to a system in the zone that the UNIX group was created.
2. Use the adquery group command.  E.g. (for db2dba)
   $ adquery group db2dba
   db2dba:x:1001:jessie.matthews

On UNIX with adedit
Log on to a system in the domain.

1. Log in to UNIX/Linux with an account that can modify the group (or use kinit) and open adedit.
2. bind to the domain
   >bind corp.contoso.com
3. Set the object distinguished name
   >set obj_dn [principal_to_dn "UNIX-HQ-DB2 DBAs@corp.contoso.com"]
4. select the object just retrieved
   >select_object $obj_dn
5. Query the group members
   >get_object_field member{CN=Jessie Matthews,OU=Staff,DC=corp,DC=contoso,DC=com}

On Windows from the Command Line

1. On a computer with the AD DS tools installed, open the command prompt
2. Run the dsget command  (eg. for the UNIX-HQ-DB2 DBAs group)
   dsget group "CN=UNIX-HQ-DB2 DBAs,OU=UNIX Groups,OU=UNIX,DC=corp,DC=contoso,DC=com" -members
   CN=Jessie Matthews,OU=Staff,DC=corp,DC=contoso,DC=com"

On Windows with Access Manager Reporting

1. On a computer with Access Manager installed, go to the Reports node.
2. Create your own report or reuse the Groups Report (pre-created)
   

(Adjust)ing the Group 

Some of the events that may require an adjustment are:

• Merging local users in the result:   This is needed in situations in which a local group (existing in the /etc/group) that contains a local user needs to be merged with the AD-managed group.   This is documented in the centrifydc.conf file:
  adclient.local.group.merge  (by default false) - use with caution.
• Adjusting the GID:  This may be required if redefining the group's unique identifier. It can be facilitated by tools like adfixid.

Basics: Centrify Zones

What are zones?

• As per Dictionary.com:
  noun. "Any continuous tract or area that differs in some respect, or is distinguished for some purpose, from adjoining tracts or areas, or within which certain distinctive circumstances exist or are established."
• A marketing name (1, 2, etc.)
• A mechanism to establish a Security Governance model using Active Directory and Centrify technologies across UNIX, Linux and Windows  (yes, Windows).

The third option is the best definition because of the key concept of security governance.  In the context of security, Centrify zones are AD constructs that allow the storage of multi-platform systems, UNIX identity data and Authorization information.  It leverages the RFC 2307 specification, proprietary Centrify techniques and the Windows Authorization Manager API to allow the implementation of the following security principles:

1. The "least access" principle:  an internal control that states that end users shall only have access to the systems based on business need to know.
2. The "least privilege" principle:  an internal control that states that end users shall only have the rights and privileges in systems based on business function.
3. The "separation of duties" principle: an internal control that requires more than one person to perform a function in order to prevent fraud or error. 

All these principles are the basis for Role Based Access Controls (RBAC). 
Zones also allow for flexible Management of UNIX identities (login, UID, GID, login, Shell, etc.) 
Process Reuse
A very overlooked advantage of Zones is that they allow organizations to reuse their current processes for the purpose of UNIX identity provisioning (or deprovisioning), access management and privilege management.  The process is the practice of adding or removing users from Security groups in AD.  For years this process has been used to grant privileges, access to file shares, printers, Exchange Services, SharePoint sites, etc.

What does this mean?
It means that integrating any solution to Centrify for the purposes of UNIX identity provisioning or privilege management is very easy and it doesn't require dedicated connectors or agents.  ANY Identity Management platform or solution has the ability to integrate to AD and to add/remove users into Security Groups.
Regardless of the solution (Oracle, Courion, Microsoft FIM, Sailpoint, etc.) all of them have that capability, and many of them with workflows.

Centrify Zones History
Zones used to be flat constructs (classic zones), this made it very cumbersome for organizations to manage them.  This changed a few years ago when Centrify introduced hierarchical zones.  The real power of zones was unleashed when the authorization components were introduced.  Since version 2013, now zones can be used to segregate and perform privilege management both UNIX/Linux and Windows systems!!!  This has huge implications for organizations that are security and cost conscious.  
Moderation note:  It is the opinion of this author that classic zones should be deprecated.  This blog does not cover them.

What are the design rules for zones?

• A single zone and computer roles should satisfy the needs of most organizations;  however there may be regulatory or legal reasons to implement other zones (for example: European Union Rules, Separation of Divisions, PCI, etc.)
• Each zone used to control UNIX system access has to have a set of defaults for identity data (UID, GID, login, Shell, GECOS).  Access Manager provides multiple options, but the default options are typically fine for a manual provisioning scenario:
  login is the AD samAccountName  (username)
  UID/GID the best option is to generate the UID from the SID - this provides uniqueness.
  GECOS defaults to the AD Display Name.
  Home and Shell use variables to specify the defaults for the system.  These can come very handy.
• For each zone dedicated for UNIX purposes, provisioning mechanisms need to be accounted for.
• Identities shall be provisioned at the zone level.  Identity overrides shall be considered exception.
• RBAC Assignment at the zone or computer level overrides shall be used sparingly.  On the flip side, Computer Role level RBAC assignments are the preferred method.

Like we have previously outlined, zone design is subject to the Plan-Do-Check-Adjust method too.

What is AutoZone Mode?

AutoZone is a mode operation for Centrify Agents that allows the UNIX, Linux or Mac system to be joined to Active Directory with no access restrictions (like any client workstation), therefore any user in the domain (or in a trusted domain) can log in to the system.
AutoZone is the only mode of operation of the Centrify Express for UNIX/Linux.  Although desirable in client scenarios, it is not a proper security practice to allow everyone to log in to sensitive systems.  

Other disadvantages of AutoZone are the following:

• A high-degree of planning is required to deploy in AutoZone mode.  The caching required for all objects (especially) in large domains may affect performance during cache buildup.  The rule of thumb is that the domain is larger than 1500 users, then limits have to be established.
• AutoZone (express) does not allow for Identity Overrides (manipulating login, UID, GID, etc)
• AutoZone does not include the authorization components.  No least access or grouping of systems or Privilege Management (no RBAC)

AutoZone is covered in a very limited basis in this blog.