Troubleshooting: Ruling-out issues with the user's AD Account

Verifying that the user's AD account is OK

To verify that the user's account is OK you'll need access to any of these tools:

• Active Directory Users and Computers
• Centrify Access Manager
• The Unix/Linux command line of a Centrified system

You MUST know how provisioning happens in your organization.  Otherwise you're trying to troubleshoot something that you DON'T understand.  How smart is that?

What you're looking for to rule out issues with the AD account

The user account has to be enabled, not locked, not expired, if it has restrictions (logon hours/logon to) those must make sense, they need a Unix Identity (login, uid, gid, etc.) and to belong to the right group if you are granting roles based on group membership.

From Windows with Active Directory Users and Computers

The account tab of the AD user contains most of the relevant info.


The Centirfy Profile tab can expose the user's UNIX identities.

Finally, the "member of" tab can expose the groups the user belongs to.  If any of the groups is used for the purposes of role-based access.  I know to look in here because I understand the process.

From Windows using Centrify Access Manager 

Determining if the user has an identity

Under the Zone/Unix Data/Users node, you can see a list of users.  Double-click the user to see the identity. If the user is not on the list, you may be facing time issues or provisioning issues.

Determining if the user has a role

The "Show Effective UNIX rights" utility is the best tool to determine who has access to which system and at which level.  Just right lick the zone or system and select the function.

From Unix/Linux using CLI tools

You can use the adquery user <user> with the -A switch.  Depending on how it is run, it may produce different results.  If elevated (with dzdo in this case) provides all the information required about the account.

This output tells me that the user has a Unix Identity (because unixname, uid, gid, etc are present), the account is neither expired nor locked, and judging from the output of dzinfo, the user does have a role that allows him to log in and even some privileged commands.

Compare with this output. Here I deprovisioned the user, note the output of a simple adquery user <user> that states that the user is not a zone user.  In this case the user is missing the UNIX identity, so we used the AD user logon name to get the information about the user with the -A switch.

This looks like a good AD account that does not have a Unix Identity. 

Let's put all this together in this video:

Using Switch User (su) or Kerberos tools

If you have a privileged account, switch user (su) can be used to isolate a particular application (like SSH) from a troubleshooting situation.  Assuming the user does have an identity and a role, but can't log in via SSH, you can try to elevate.

george@cen1 ~]$ dzdo su cosmo

AD Password:

Created home directory

[cosmo@cen1 george]$ id

uid=1149240408(cosmo) gid=1149240408(cosmo) groups=1149240408(cosmo),10024(webadmin) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

[cosmo@cen1 george]$

In this sequence, George elevated with Centrify sudo to switch to Kramer. If Kramer is having issues with SSH login, this eliminates his Centrify identity and role from the troubleshooting table.

If you want to take things further and eliminate both the logon application (that may use PAM) and NSS and test the AD account directly, you can use kinit and klist from  /usr/share/centrifydc/kerberos/bin.

[george@cen1 ~]$ /usr/share/centrifydc/kerberos/bin/kinit cosmo.kramer

Password for cosmo.kramer@CORP.CONTOSO.COM:

[george@cen1 ~]$ /usr/share/centrifydc/kerberos/bin/klist

Ticket cache: FILE:/tmp/krb5cc_cdc1149240406_EINhqm

Default principal: cosmo.kramer@CORP.CONTOSO.COM

Valid starting     Expires            Service principal

06/22/14 14:11:36  06/23/14 00:11:40  krbtgt/CORP.CONTOSO.COM@CORP.CONTOSO.COM

        renew until 06/23/14 14:11:36

I would argue that using kinit/klist are the fastest way to determine if any AD account (if the credentials are known) is working correctly. It also ensures that the communication path between the Centrify agent and AD is working as expected. Notice that I did not use the user's unix name (cosmo) but their AD account (cosmo.kramer).

In the next posting, we'll continue our troubleshooting and will look at what happens in the logs.