Business Problems: What does 'Secure' mean to you? Your answer may impact your ability to launch your BigData Project

We've had an opportunity to man the Centrify booth at the Strata+Hadoop show in New York this past week and we were constantly surprised by the focus on the core capability, but when we engaged passers by, the were unaware of the following facts:

• A large majority of Big Data projects never make it into production
• The most visible examples of Big Data projects that add value to organizations involve data that may contain Personal Identifiable Information (PII) or financial information.

It does not take a security expert to realize that these projects would be subject to the biggest security requirements.

When challenged, we heard answers like "but [management tool] can be integrated to Active Directory" (on the more informed side of the spectrum) or simply, people were focusing on areas like table-level security.

It became clear to me, that "to secure" a capability has a different meaning depending on who you ask (e.g. Big Data Scientist vs. Linux administrator vs. Security Analyst);  this is why at Centrify we always encourage the main stakeholder to bring in their infrastructure and security peers.

The key takeaway is that regardless of who you ask, there are reasons like

• people: being able to find capable data scientists
• data: availability of the data
• cost
• dynamics: integration with business processes
• need: is it just a fad (business want to jump into the BigData bandwagon without real requirements)

But security will always come up, that's a common denominator across all Big Data.  We know this first hand because that's what we do.  Upwards of 60 of our customers are using Centrify to align their Big Data deployments with security requirements.

If you're tasked to launch a Big Data project, you have all the opportunity to get a leg-up on this problem and attack security early.

At a basic level you have to look at this in terms of layers.

To simplify, there's two of them:  The Identity/Infrastructure layer and the Big Data layer.  The concerns and focus are completely different.

OS Layer
I also like to call it the Identity/Infrastructure layer because it plays directly into what Identity and Access Management is set out to do:

a) Use a common directory to identify and authenticate users
b) Enforce the least access principle
c) Enforce the least privilege principle
d) Eliminate the human problem of shared accounts
e) Implement strong controls (e.g. end-to-end session auditing or multi-factor authentication) when needed
f) Be able to attest who has access to a system
g) Provide reporting and tools for attestation

Big Data Layer
I can't even pretend to advise on the Big Data layer, but all I know is this:
If you can't identify - you can't authenticate - if you can't authenticate, you can't authorize;  and if you can't authorize, you can't enforce strong access controls.  Regardless of Knox, Sentry and any other security initiatives at the Big Data layer, you need robust OS services to optimize those.

A promising future
We were also excited by the bright spots:  Cloudera, Hortonworks and MapR are taking security very seriously because they realized that this affects their ability to bring nodes into production.

Centrify is here to help!!!   Learn what we mean by "secure" - it's all about the OS Layer (Identity and Access Control)

Overcoming the Hadoop Security Challenges at the IAM layer with Centrify

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (4/5)

This is part 4 of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".  (Also relates to PCI DSS 10.2)

CSC 12-11

Configure systems to issue a log entry and alert when unsuccessful login to an administrative account is attempted.

Why should you do this?
This is a detective control.  You can't control what you're not tracking.  Security operations typically leverage log aggregation technologies that tap into the native OS log facilities and centralize all this information into a centralized logging infrastructure that may or may not offer intelligence.

What is the typical approach?
On Windows:  Harvest and mine of the Windows event logs.  Surprisingly, a lot of outfits are not auditing the logon/log-off success/failure events.
On UNIX:  Harvest and mine the UNIX syslogs.

What is the real challenge for organizations?
Data vs. Noise.   How can organizations reconcile all the sources of data into meaningful information?  This is not Centrify's main capability, but it can certainly help by requiring meaningful data (e.g. change control/authorization numbers) and if all logs fail, there's always the session capture/replay capability.

Centrify's enhancers:

• Use what's native:  Uses syslog and event logs.  Unix logon/logoff success or failure are logged in the security log of the domain controller if configured by the Windows sysadmin.
• Enhance to differentiate the data from the noise:  Centrify can be configured to require reference information upon elevation, for example, change control number.
• Contextualize with DirectAudit to "clear the noise":  Enterprise Edition offers session capture and replay for both UNIX, Linux and Windows.
• Adding DirectAudit (Enterprise Edition) exceeds the requirements of PCI DSS 10.2 "reconstruct events"

Have a look:

How privileged elevation is logged (syslog) and recorded with Centrify on UNIX:

How with the Centrify dzdo validator, you can add more meaningful data to privilege elevation

How privileged elevation is logged (eventlog) and recorded with Centrify on Windows:

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (3/5)

This is part 3 of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".

CSC 12-7

Utilize access control lists to ensure that administrative accounts are used only for system administration activities, and not for reading e-mail, composing documents, or surfing the Internet. Web browsers and e-mail clients especially must be configured to never run as administrator.

Why should you do this?
To limit the exposure of administrative accounts to malware.

What is the typical approach?
On Windows:  Two sets of accounts are given to administrators,  a "dash-a" account and a normal account.  On the server side, to access the internet there's an air gap or the proxy server does not allow the servers or the "dash-a" account to go out to the internet.  The IE Enhanced Security mode is enforced.

On UNIX:  Systems are crippled from internet access or GUIs.  The email/surfing computer is different from the server systems.

What is the real challenge for organizations?
Human nature - people find ways to go around this, especially in the process of doing their actual jobs.  In the times of "knowledge on demand" having an internet browser to consult FAQs and community boards is very common.

Centrify's enhancers:
It's not all about just giving separate accounts, but being able to establish additional controls, like scope of systems, types of roles, privilege effectiveness, logon experience and flexible assignments.

CSC 12-10

Configure systems to issue a log entry and alert when an account is added to or removed from a domain administrators' group, or when a new local administrator account is added on a system.

Why should you do this?
At basic level this is a detective control, all administrative access should be traced back to an approval, otherwise this is misuse or a data-breach.

What is the typical approach?
Log aggregation.  Logs from multiple systems are sent to an enterprise security operations dashboard.

What is the real challenge for organizations?
Log aggregation lends itself for NOISE, then the log aggregation needs to be complemented by a data mining engine;  this is all to make sure that what's happening out there is authorized.

Centrify's enhancers:

• A Centrify deployment limits the local root or administrator account to break-glass situations.  They are not needed.
• Centrify (without any modification) augments log aggregation.  Therefore, the existing collection mechanisms can have richer data.
• Plus, Centrify reporting shows you what are the AD principals that grant the administrative roles, if things are tied to a Workflow or an IDM, anything that is not there by way of approvals will be identified quickly or rolled back.
• Plus Centrify DirectAudit provides the ability to view or audit who makes changes to the governance model.

Short video:

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (2/5)

This is the continuation of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".

CSC 12-3

Configure all administrative passwords to be complex and contain letters, numbers, and special characters intermixed, and with no dictionary words present in the password. Pass phrases containing multiple dictionary words, along with special characters, are acceptable if they are of a reasonable length.

CSC 12-5

Ensure that all service accounts have long and difficult-to-guess passwords that are changed on a periodic basis, as is done for traditional user and administrative passwords.

CSC 12-8

Through policy and user awareness, require that administrators establish unique, different passwords for their administrative and non-administrative accounts. Each person requiring administrative access should be given his/her own separate account. Users should only use the Windows "administrator" or UNIX "root" accounts in emergency situations. Domain administration accounts should be used when required for system administration instead of local administrative accounts.

CSC 12-9

Configure operating systems so that passwords cannot be re-used within a timeframe of six months.

Why should you do this?
Because the password policy for admin accounts should be a step-up from regular users given that they hold the keys to the kingdom. 

What is the typical approach?
On Unix:  cracklib PAM module.
On Windows:  group policy.

What is the real challenge for organizations?
Human nature - sysadmins love their root or administrator accounts given their inherent mistrust in software, and unfortunately vendors promote fragmentation. 

Centrify's enhancers:
It's the solution that can accomplish this with true RBAC (allowing the administrative accounts to be put away) plus the tight AD integration with Group Policies (and support for fine-grained password policies).  In addition, Centrify's resiliency truly makes sure that the root or administrator account are only needed in emergency situations.

In UNIX - privilege elevation using Centrify-enhanced sudo (no sudoers) - DirectAuthorize (DZ)
In Windows - privilege elevation with the Centrify agent for Windows (DZ Win)

CSC 12-4

Before deploying any new devices in a networked environment, change all default passwords for applications, operating systems, routers, firewalls, wireless access points, and other systems to have values consistent with administration-level accounts.

Why should you do this?
Anyone that has had a Linksys router knows the answer to this.  In UNIX/Linux, there's too much reliance on the root account or the switch user command.  Local administrator in Windows is treasured by Windows admins.

What is the typical approach?
Unfortunately, in a lot of environments there's too much sharing of these accounts.  TACACs, RADIUS and password vaults help with network appliances.

What is the real challenge for organizations?
Human nature.  A Unified approach for these accounts like a password vault is typically the right solution.

Centrify's enhancers:
Due to the true RBAC and privilege elevation methods employed by Centrify, organizations can decrease their costs in password vault user licensing costs, by just leveraging it for non-human admin accounts, while the rest of the population uses RBAC.  The end-to-end nature and resilience mechanisms, makes it more efficient to align with regulatory requirements without a single point of failure.  In UNIX, single-user-mode or Windows safe mode without network will be the only instances in which these accounts are needed.

No need to check-out the keys to the kingdom each time the root, or administrator accounts are needed.

• Tied to your identity infrastructure (Active Directory)
• True Role-based access
• Minimal process impact
• Increased accountability using the native tools (syslog/event viewer)
• Extensible to session capture and replay

Tried and true AAA.

CSC 12-6

Passwords should be hashed or encrypted in storage. Passwords that are hashed should be salted and follow guidance provided in NIST SP 800-132 or similar guidance. Files containing these encrypted or hashed passwords required for systems to authenticate users should be readable only with super-user privileges.

Why should you do this?
There was a time in the security discipline in which encryption was thought to be the solution;  time and different attack vectors have proven this to be wrong; however, encryption in transit and encryption at rest are a must.  There's an arms race going on because although algorithms are strong, Moore's law, virtualization and well-funded and motivated agents are lurking.

What is the typical approach?
Rely on the OS, Directory or the appliance.  Fortunately Microsoft has this very-well documented.

What is the real challenge for organizations?
Human nature, again  It doesn't matter how hard your encryption is if credentials are shared or clear-text passwords are used in scripts or other facilities.

Centrify's enhancers:

• More US-federal government certifications that I can even pretend to understand
• Common Criteria
• FIPS 140-2 Validated

However, the bullets above are just marketing speak if we don't back-it up with examples:

• Kerberized tools:  install.sh adjoin, adleave, adkeytab, adcert, dzdo + more are all Kerberized, which means no need to actually store passwords.  The Hadoop and MongoDB examples illustrate practical use.
• Microsoft CA PKI client:  Use Certificates in your Unix, Linux, Mac systems.
• Extend it to your HTTP, Java, SAP or DB2 needs.

Why even have the problem when you can completely avoid it?

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (1/5)

Background

One of our prospects looking at the Centrify privileged elevation tool for Windows, just highlighted to me that Server Suite is very well-aligned with the SANS Critical Security Controls Section 12: "Controlled use of Administrative Privileges" so I decided to take a deeper look.  We will cover 2 each post until we have the 14 topics explored.

Controlled use of Administrative Privileges

CSC 12-1

Minimize administrative privileges and only use administrative accounts when they are required. Implement focused auditing on the use of administrative privileged functions and monitor for anomalous behavior.

Why should you do this?
Because the more somebody uses a privileged account the highest risk of malware being executed with elevation, more exposure to attacks like pass-the-hash attack, etc. 

What is the typical approach?
On Unix:  sudo, password vaults or RBAC
On Windows:  dash-a accounts, password vaults or RBAC

What is the real challenge for organizations?
Well, sudo is simple, proven but a pain, PVs just give out the keys to the kingdom in a controlled way - great for appliances BTW, and RBAC is hard to implement given that it typically requires multiple solutions.

Centrify to the Rescue:  Centrify Server Suite offers a serverless, cross-platform Unix, Linux and Windows based solution that provides access governance with RBAC leveraging AD.

End Result: The ability to limit access, control privileges (no giving out the keys to the kingdom) and reusing processes, cross platform, using existing technology and infrastructure.  This was explored in the 10-minutes PCI 7 challenge:.

CSC 12-2

Use automated tools to inventory all administrative accounts and validate that each person with administrative privileges on desktops, laptops, and servers is authorized by a senior executive.

Why should you do this?
This is all about keeping track and being able to attest who approved the type of access that users have.  It's also an administrative preventative control.  This is not limited to domain accounts but local accounts as well

What is the typical approach?
The solution to this is basically workflow.  Unfortunately, simple workflow engines are hard to come by, or they are tied to a monster solution.  Scripts are popular as well.

What is the real challenge for organizations?
This should be relatively simple, but vendors don't make this easy.  Surprisingly PV vendors do a good job due to the appliance/proxy based nature of their solutions. Go to the vault, request access, approver gets notified, approves/denies, then the access is granted/denied.  Great for break/fix.

How Centrify helps?  Although Centrify does not provide workflow capabilities today (wink);  it makes it very easy for any IdM or workflow engine to perform the functions upstream.  Since the process boils down to AD groups and any decent workflow engine can do this, then the solution looks like this:

Utilities:  Automatic provisioning and role assignment is often achieved with ZPA.  This post and video cover a basic design:



In the next post we'll continue with the list.

Security Corner: How your Centrify Deployment Affects your Existing Security Policies, Procedures and Standards

Background

Identity and Access Management capabilities fall under the umbrella of Information Security therefore any technical implementation (such as Centrify for Servers) needs to align with IT Security principles and procedures.  In the Security corner, we discuss topics related to information security and how they relate to these capabilities.

Blog Objectives Refresher

As per our first post, this blog's mission is to:

• Provide general information, discuss use cases and provide step-by-step guides
• Minimize or eliminate IT capability fragmentation
• Promote operational efficiency and process reuse
• Discuss problems from the business and technical perspective
• Project & Capability Management (Plan-Do-Check-Adjust)
• Promote proper security practices

That is quite a lot to balance, but hopefully the topics in this section can focus on the security side of the problem.

The Security Process

In our first post we outlined that all security measures should flow from a sensible risk assessment exercise. Depending on the nature of the business, organizations may protect from (in no particular order):

• Financial loss (mainly in for-profit organizations - here's a current topic)
• Reputation hits  (this affects for-profit organizations, but less and less - e.g. was there any fallout from the TJX data-breach?  I'm sure that management blunders, cost more to non-profits)
  Note:  Some things just don't make sense, but I guess that's the world we live in.
• Risk of injury or human life (or other externalities)
• And more....

The result of an assessment, as it relates to Information Security produces what are called Policies, Guidelines and Standards.  Although we can find a better description somewhere else online, let me try and simplify:

• Policy:  What shall be done.  (Regardless of how)
• Standard:  Establishes what should be the result (What/Per platform)
• Procedure:  The template or recipe on how it should be done in a particular use case  (How)
• Guideline: The best practice to shoot for.
  

We already stated, that a properly implemented countermeasure, includes technical, procedural and administrative controls that are preventive, corrective and detective.  

For example a policy statement like:  "the organization shall limit end-user Internet misuse"  (that I just came up with) may imply controls like this:

• Standard:  The corporate browser is Mozilla Firefox, configured to use a proxy server.
• Standard:  Microsoft TMG is the official Proxy Server, implemented with HTTP and HTTPS access with a filter to block all "Liability" categories.
• Standard:  Group Policies will be deployed to limit access to the Options-Advanced-Network tab of the browser.
• Standard:  All questionable internet usage will be reported and consolidated into a SQL server back-end.
• Guideline:  When possible, make the user acknowledge the fair use statement when users go to questionable sites.

The browser and proxy server standards are the preventive controls, the TMG filter is the corrective control and the reporting is the detective control.

Notice that these standards are mostly technical controls.  For a proper implementation, things that are relevant:

• Standard (administrative):  Background checks for prospective employees
• Standard (administrative):  Security policy attestation (proper use)
• Standard (procedural):  Discuss proper use with employees as an item for performance reviews.
• Guideline (procedural): Assign some points to proper use in the Housekeeping performance category.

Now we have some additional administrative and procedural controls that can prevent the hire of candidates with history of misuse of corporate assets, we are requesting acknowledgement and attestation of the fair use guidelines, and the fair use is being discussed as part of performance reviews.

Technical controls alone can't mitigate all risks, especially when there are human beings involved.

How your Centrify Implementation Affects your Standards and Procedures

With Centrify, the UNIX/Linux administrator has more tools at their disposal, this means that principles like least access, least privileges, separation of duties and more are easier to implement.  Let's look at an example - the password policy.  (by the way, here's a great example of a password policy)

Policy:  End users shall protect passwords and implement them in a way that are not easily guessable.  

Standard: An acceptable password contains at least 8 characters, 1 numeric, one special.  The age of a password will be 45 days, cannot be reused until after 15 iterations and will be stored with non reversible encryption.

So far this is very straightforward:  but when it comes to the sub-standards and procedures, here comes the variability:

On Windows Platforms:  Since all windows computers are domain-joined, the policy shall be implemented with the "Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy" Group Policy objets.

On UNIX/Linux Platforms:  All Linux platforms should implement the standard /etc/login.defs file. On Solaris, the standard /etc/defaults/login. The PAM library pam_cracklib should be implemented.

Notes:  This is overly simplified, but it has implications on the standard build (or image), maybe the files have to be centrally hosted and checked constantly, etc.

Process Reuse: With Centrify in place, the Windows Standard can be reused for the UNIX/Linux platforms and the agent will enforce it.  The standard may be needed for local accounts, but since all human accounts will be in AD, the root account (or any other service account) can have a long password that can be secured.  The privilege management component of Centrify allows to elevate to those accounts without knowing the password.

A Standard Framework to Enforce Access Controls

The Centrify agent implements Role-Based Access Controls (RBAC) that allows for easier implementation of the least access and least privilege principles.  The best way to see it is with our example.  We have a simple model, in which only DBAs can accesses Database Systems (so far CEN1), only Web Admins  can access Web Systems (so far SUSE1) and Sysadmins can access and manage all systems.  This means that standards like the ones outlined in the PCI DSS section 7:

Requirement 7: Restrict access to cardholder data by business need to know

To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.

7.2 Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

Only Doyle and Matt (Web Admins) with Jessie (sysadmin) can access SUSE1

Only Jeremy and Ramon (DBAs) with Jessie (sysadmin) can access CEN1

How is this accomplished with Centrify:

Zones will only allow Active Directory UNIX-enabled users that have a proper role to access the systems.

The privilege management module (directauthorize) with AD and authorization manager.

(And this same model can be extended to Windows too!!!)

Moderation note:  This is why Centrify Express is not discussed in this blog, because by default, it will allow every AD user from the local domain (and trusted domains) to access te UNIX/Linux systems.

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: 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.