Even login as AD user via UNAB was successfull one can find in /var/log/secure
...
Aug 3 11:49:09 rh73 sshd[12458]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=Administrator
Aug 3 11:49:09 rh73 sshd[12458]: Accepted password for Administrator from ::1 port 47750 ssh2
Aug 3 11:49:09 rh73 sshd[12458]: pam_unix(sshd:session): session opened for user Administrator by (uid=0)
...
Similarly when the user is using sesu to switch to another user
(use in seos.ini old_sesu=no, thus pam is used here as well)
...
Aug 3 14:02:05 rh73 sesu: pam_unix(etrust-ac:auth): authentication failure; logname=Administrator uid=2000 euid=0 tty=/dev/pts/1 ruser= rhost= user=Administrator
Aug 3 14:02:05 rh73 su: pam_unix(su:session): session opened for user root by Administrator(uid=0)
...
PIM
Linux
The reason for the “wrong” authentication failure messages is a misbehaviour in the native pam_unix authentication module.
To avoid the error from showing up rearrange the PAM stack configuration to prevent control from reaching pam_unix.
What we found in internal research is that using the alternative pam_ftp module which is to a certain extent working identically like the pam_unix module (without parameters) is not showing this symptom.
Replacing the first call of pam_unix.so with pam_ftp.so allows to circumvent the issue, i.e. authentication as AD user via tty and ssh is working fine and subsequent sesu to root is also not showing any problem.
The “wrong” authentication failure message does not appear.
Put the alternative pam_ftp.so as described below in the two configuration files /etc/pam.d/password-auth and /etc/pam.d/system-auth.
...
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth optional pam_ftp.so # <- this line is to be insert
#auth optional pam_unix.so # <- this line is to be commented out
auth sufficient pam_uxauth.so # added by UNAB (uxauth)
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so
account sufficient pam_uxauth.so
...
Note that pam_unix is a 3rd party module which is out of our control of Broadcom, hence we can not correct this misbehavior.
Although successfully tested in house, Broadcom does not provide any guarantee for the above approach - it is recommended to do own careful regression testing to confirm all is working as expected.