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:
- You set up a Centrify zone or child zone with the corresponding user and group defaults
- You've configured authorization (computer roles, UNIX rights, roles and role assignments)
- Installed the Centrify agent and joined one or two Unix or Linux systems
- You're trying to test a user or two but have no luck
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).
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.
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