Troubleshooting: My brand new users aren't available or can't log in

Background

This is probably the most common task to troubleshoot is user's availability in a system.  Granting access to a brand new user (or users) to a system.  The user may or may not be available to the system or can't log in.

In this initial article, we will cover the mechanisms to minimize replication and techniques on how to rule out issues with the user's AD account.

What you've probably done so far:

1. You set up a Centrify zone or child zone with the corresponding user and group defaults
2. You've configured authorization (computer roles, UNIX rights, roles and role assignments)
3. Installed the Centrify agent and joined one or two Unix or Linux systems
4. You're trying to test a user or two but have no luck

Symptoms:

Unfortunately, your user does not show up in the system (adquery user does not show the user or users), possibly the user shows up, but can't log in;  Maybe the user shows up and can log on after a long time (undetermined time).

Remember:

By default in zone mode (unlike in Express mode) no users have access to the Unix, Linux (or Windows) systems that belong to the zone.  

Troubleshooting Checklist

We can use a two-category technique to troubleshoot this issue.  We can divide it into time and configuration items.  Time can be proactively managed and configurations can be verified and ruled out.

• Enough time should have passed for
• Any Identity Management tool to work (IdM solution, ZPA or program)
• AD replication to complete
• The cache flush interval complete (or the adflush command issued in a target system)
• In order to access a Unix/Linux system, a user needs an identity and a role
• To get an identity: the AD user has to be added to the zone to get a login, UID, GID, GECOS, Home and Shell based on the zone defaults to get an identity
• To get a role:  the role has to be assigned to a user directly or to a group that the user is a member of.
• The role needs to have at least the intended PAM logon right for the user to be allowed to log in.
• The role assignment has to be properly scoped (Zone, Child Zone, Computer Role or System level)
• The role has to be properly created:  logon options, hours, auditing, etc.
• The user's AD account should not be subject to any restrictions (logon, computer)
• The user's AD account should be usable (not expired, disabled or locked)
• The user is not listed in the /etc/centrifydc/user.ignore file
• The user principal has to be readable on the correct side of the one-way trust

Where to go now?

• First, try to understand how provisioning, AD replication and the agent's cache can affect when changes are effective.
• After you've ruled out time, now learn how to rule out the user's AD account.
• Learn how to spot configuration issues
• Learn how to use the addebug tool
• WIP...

Security Corner: Establishing an Identity and Access Governance Model for UNIX/Linux with Centrify and Active Directory - Part 1

Background

An Identity and Access governance model establishes how end users will access your systems, this entails

• Establishing the rules of who should have access to which system
• Establishing what functions (or privileges) they're allowed to perform or use
• Establish the provisioning process (Add/Moves/Changes)

But first, a quick refresher:

Provisioning

As defined by the dictionary, provisioning  means to provide, the reverse is to withdraw or to deprovision.  

In Identity Management, provisioning may mean User provisioning into different systems from an authoritative source.  User provisioning as per Gartner is a whole IT capability (and a source of much confusion)

In the context Identity and Access Management with Centrify for UNIX, the authoritative source is Active Directory;  regardless of how the Active Directory user is provisioned (manually, with an Identity Management solution like Oracle, Courion or Sailpoint, or with other tools) UNIX identity provisioning in AD can be performed in different ways.  With Centrify, the preferred method is with a SCP that contains the user's identity (created manually via Access Manager, or automatically with the ZPA).  

Fortunately, Centrify makes the integration very easy.  It's all about placing users in a security group in AD.

As a refresher, for an AD user to have access to UNIX system in a Centrify Zone, they need two things:

• A user Identity
• A role that allows the right to log in

Therefore, both identities and roles can be granted (provisioned) and removed (deprovisioned).  Centrify implements an RBAC model for UNIX that grants Access and Privileges.

The group nesting feature of AD can be leveraged
to provide Identity and Access with automation.

Access

In a properly managed enterprise, not everyone has access to all systems, and with Centrify you can implement virtually any governance model.  The design ideally is as flat as possible, with a single hierarchical zone and computer roles as the way to establish a governance model.  For example, in our lab we have a simple Access Model:

• Web Servers can be accessed by super users and web administrators
• Database Servers can be accessed by super users and DBAs
• Filers can be accessed by super users, and all UNIX users are listed in the system.

This model works great for our example, but we know that the real world is different.  The guideline is to try to enforce the least access principle.

In Centrify,  access is granted by direct assignment or by making a user a member of an AD group that has been granted the assignment (role granting group), the rest implies to manage the server memberships.

For example:  when a new web server is provisioned, it's dropped into the Web Servers group, and by way of the role assignment, all users that have access (and privileges) will get access automatically.

Privileges

With Centrify, in UNIX, the rights are:

• PAM Access: meaning, "how the system is accessed" or "what protocol"   this allows to grant access via the console and SSH for super users, but only SSH for the rest of the world.  We can go deeper into SSH rights, like allowing a secure file copy, but we aren't going to go that deep.
• Commands:  meaning "what can the user do?" "in the context of what account?" etc.  For example, a super user may leverage Centrify-enhanced sudo to run any command as root, but a DBA may only have one privileged command, like "su - oracle"

Note that Centrify can also perform privilege management for Windows, but that's a whole other topic.  In here, the idea is to start broad (define super users and regular users) and slowly adjust to provide people with the roles that give them just what they need, again, in accordance with the least access principle.

With Centrify roles, there are other settings that can be adjusted like:

• At what time is the role available?  (e.g.  backup operator that runs the tar command as root from 10pm to 4am)
• What is the shell experience for privileged commands (a whitelist of commands or a free-range shell)
• Is the role permanent or just temporary (like in a change control window)

In Centrify,  privileges are granted by direct assignment or by making a user a member of an AD group that has been granted the assignment.

Putting it all together

1. Centrify does not provision AD users, this happens upstream (manually, Idm, etc)
2. To access Centrified servers in AD in a zone a user needs an identity and a role that grants access and privileges.
3. Identities can be granted manually or automatically (by placing the user into an AD provisioning group)
4. Access and privileges can be granted manually or automatically (directly or by placing a user into an AD role-granting group)
5. The reverse of 3 and 4 is possible.
6. Automation and integration is always possible and very simple due to the link to AD groups.

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.