Troubleshooting: How to Spot Configuration Issues

Configuration issues can be hard to find.  The issue could be as simple as a missing item, as challenging as an issue introduced during the troubleshooting process or as complex as a configuration item that was set up and conflicts with the current objective.

Spotting Identity Issues with Identities and Role Definitions and Assignments

The most common identity configuration issues have to do with:

• Replication (go here to learn about about this)
• Overrides

About Identity Overrides

Identity overrides can be used to assign an AD user more than one Unix Identity.  Overrides can happen at the Zone, Child Zone or Computer Levels.  Although identity overrides showcase the flexibility of the Centrify approach to UNIX identity management, they are generally a very bad idea.  Overrides promote identity fragmentation within the solution and in specific use cases (like filers) can be a challenge.  Ultimately Identity overrides promote what's known as a Centralized mess.  Administration of identities is centralized in AD but the UNIX namespace is not rationalized.

Nonetheless, overrides can be good for: migrations while rationalizing a namespace, legacy systems, mergers and acquisitions between different UNIX environments and even one-offs.

Classic zones traditionally had used the nss.passwd.override parameter, this troubleshooting purposely ignores this parameter since classic zones are not covered in this blog.

Determining Identity Overrides

The agent will use the PAMGetUnixName call to determine the user's UNIX login name, the key items to remember here are:

a) Is this change effective?
b) Is this a system local override (bad idea)?  If it is, has the centrifydc daemon been restarted?

The best way to make sure that system local overrides are effective is to restart the agent.  This is the only identity-related time that the agent has to be stopped and started.  The behavior varies in the latest versions of the agent, but I'd do a restart to be sure.

Spotting Authorization Issues

For RBAC to work, roles have to be effective, properly created, properly assigned and properly scoped.
The most common authorization issues have to do with:

• Misconfigured Role
• None or missing rights in Role
• Improperly defined roles (another topic)
• Unassigned Roles
• Poor or Wrong scoping

Role configuration issues

1. Role is time-bound: this happens when the role has a time restriction and the user complains that they can't log in at certain times.

2. Role is not configured properly (System Rights):   this is very common. A role is created and properly assigned, but the role creator forgets to set the attributes for the role.  This pic illustrates the main issues:

3. Audit is being enforced (required):  the end user can log in to systems with standard edition, but not enterprise edition.

4. Roles that do not contain any rights:  this is very common.  A role is properly set up and properly assigned, but the creator forgets to add the proper PAM login or commands.  From UNIX, you can run an elevated dzinfo on the target user that is having the issue with the role.

$ dzdo dzinfo yash

...

  PAM Application  Avail Source Roles

  ---------------  ----- --------------------

Privileged commands:

  Name             Avail Command               Source Roles

  ---------------  ----- --------------------  --------------------

  (yash has no privileged command rights)

This excerpt of dzinfo indicates an empty role (no PAM or privileged commands); a role needs at least a PAM right to allow the asignee of the role to log in.  You can also verify this on Access Manager by clicking on the role in the left pane and looking at the detail in the right pane.

5. Unassigned Roles

The RBAC cadence in Access Manager is as follows:

1. Create the PAM rights and Commands
2. Create and configure the role
3. Assign the rights to the role
4. Assign the role to an AD principal (preferably a group) at the correct scope  (zone, child zone, computer role or computer (override))
5. Populate the group and make sure the user's have UNIX identities in the zone.

Unfortunately a lot of end users think that by performing steps 1 to 3, the role is already assigned and to make matters worse, the design may make matters harder or easier to troubleshoot.  My recommendation is:

• Identities are assigned at the highest levels with overrides used as a last resort.
• Role assignments are performed at the computer role or child zone (with high-level roles assigned for a very small set of trusted administrators)
• Very rarely use system overrides.

The tools available to perform high-level troubleshooting are:

a) The user's effective rights utility of Access Manager:

Do not attempt to troubleshoot at the system level if things don't look correctly here (it may be a time issue). 

b) The dzinfo command

c) The Centrify Report Center

6.  Role assigned, but expired

With Centrify, UNIX (or Windows) roles can be assigned during a specific window of time (break/fix, change control, etc).  An expired role can stop the user from logging in or performing admin duties.

Bottom-line, understanding why you're doing what you're doing is crucial, along with a configuration that makes sense.