Perhaps I should have asked for a bit of clarification.
I am answering the question based on the assumption of "Why can user faker log in to good server but can't to bad server?" If this is not what you wanted answered, please rephrase the question.
Keep in mind (back to basics):
In a system joined to a Centrify Zone, two conditions must be in place for the user to access the system:
- The user must have an identity defined in the zone (faker does).
- The user must have a role (assigned directly or via AD group membership) that allows him to log in (here is the issue that I see).
There are two reasons why fakers' line shows like that in the "bad" server, and the two of them are expected behaviors:
- The user once had a valid role assignment and it was assigned temporarily that expired.
- The user has been assigned the "listed" role.
This type of role and assignment is usually done in systems working as filers (NFS or Samba) because you want the user to be "known" by the system, but you don't want to allow the user to log in. - The user may have a poorly constructed role (e.g. a role missing a PAM right) - long shot but possible.
The best way to confirm/dismiss this is to look at the output of the "dzinfo faker" command in both systems (this has to be run with privilege).
The domain controller that they are communicating with is irrelevant (unless you just made the change and want it to be effective).
Let's hope this clarifies a bit, but if you outline (without technical details) the behavor exhibited (faker can't log in to bad server, but can log in to good server) and the behavior expected (I want faker to be able to log in to both systems).
R.P