Centrify

Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

KB-2699: su to "locked AD" accounts fail

Authentication Service ,  

12 April,16 at 11:09 AM

Applies to: Centrify DirectControl 4.4.4 on RHEL platforms
 
Question:
 
After upgrading the Centrify Linux client from version 4.4.3-424 to 4.4.4-543, there is a change of behavior. 
 
With the old version, root can su to any account, even a "locked AD account" (which is normal Linux behavior).
With the new version, root cannot su to a "locked account" (which is NOT normal Linux behavior). 
 
As a result, daemons and cron jobs owned by a "locked account" cannot run.
The PAM config did not change.
 
/etc/pam.d/su: 
 
# lines inserted by Centrify Direct Control (CentrifyDC 4.4.3-424)
account    sufficient     pam_centrifydc.so
account    requisite      pam_centrifydc.so deny
session    required       pam_centrifydc.so homedir
password   sufficient     pam_centrifydc.so try_first_pass
password   requisite      pam_centrifydc.so deny
 
#%PAM-1.0
auth sufficient pam_rootok.so
# lines inserted by Centrify Direct Control (CentrifyDC 4.4.3-424)
auth       sufficient     pam_centrifydc.so enable_dzpamgate
auth       requisite      pam_centrifydc.so deny
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
auth include system-auth
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session optional pam_xauth.so
 
Answer:
 
This is an issue with Centrify DirectControl 4.4.4. 
 
To fix this, please follow the steps below:
 
1) Make a backup of /etc/pam.d/su.
 
2) Copy /etc/pam.d/su.pre_cdc /etc/pam.d/su
 
(or)
 
Create a file called /etc/pam.d/su with the contents below:
 
#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
auth include system-auth
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session optional pam_xauth.so
 
3) Change the autoedit parameter in /etc/centrifydc/centrifydc.conf
(Otherwise upon restart, Centrify will re-add the lines or restore the file)
 
adclient.autoedit.pam: true (default is false)
 
4) Optionally, restart Centrify DirectControl:
 
  service centrifydc restart
 
5) Test su - "locked AD" accounts and it should work fine.
 
Note: The steps above are not required in Centrify DirectControl 5.0.2 or above

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.

Related Articles

 articleKB-6882: User Fails su to an Active Directory Account on AIX. Error Appears: "There have been too many unsuccessful login attempts" articleKB-2081: groups command fail to retrieve all AD groups articleKB-6041: How to show current license type in use by adclient articleKB-6040: How to change the license type in use after adclient successful joined to the AD? articleKB-6073: How to join the Linux/Unix Centrify Server to Active Directory with specific Computer Role? articleKB-6056: How to report the group policy settings that are in effect for the local computer? articleKB-6038: How to specify the license type to use when joining the server to AD using adjoin? articleKB-1861: SSH fails/Access denied if the shell /bin/bash does not exist article[DevOps] Creating a Kerberos Keytab to Automate DirectControl Active Directory joins & removals