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.