Description of problem: 1) Users can not su to root in 5.2 (could do so in RHL 5.1 and beta). 2) Root can su to other users. The su process will accept a password, pause and then fail with 'incorrect user'. I have checked /etc/pam.d/su and that is not the problem: #%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 The only thing I can come up with currently is that it might have something to do with ldap users.
Moving to nss_ldap as emails from others affected see the problem fixed with changing that component.
I'm also having a similar problem, and have an ldap system too. I don't get the error, but it simply won't allow me to be root. Modifying the /etc/pam.d/su file to this didn't help. #%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 sufficient pam_ldap.so auth include system-auth account sufficient pam_succeed_if.so uid = 0 use_uid quiet account sufficient pam_ldap.so account include system-auth password include system-auth session include system-auth session sufficient pam_ldap.so session optional pam_xauth.so
This is an nss_ldap issue. su failed on our RHEL 5 systems, as well as pipes and backticking in bash. Running system-config-authentication, enabling user caching (and chkconfiging nscd on if necessary) fixed the problem for us.
This looks like a duplicate of bug #448014, which was fixed in nss_ldap-253-13.el5_2.1. Please reopen this report if this update did not resolve the problem. Thanks! *** This bug has been marked as a duplicate of bug 448014 ***