PAM Module Ordering Question
In our enterprise, we settled on using PowerBroker's AD-integration tool, LikeWise. We also need to make use of the STIG-recommended security settings on our systems.
By default, LikeWise's installer seems to key off the final line of the /etc/pam.d/password-auth file's auth-stanza when it injects its call-out to pam_lsass:
auth required pam_env.so
auth sufficient pam_unix.so try_first_pass nullok
auth requisite pam_succeed_if.so uid >= 500 quiet
auth requisite pam_lsass.so smartcard_prompt try_first_pass
auth sufficient pam_lsass.so try_first_pass
auth required pam_deny.so
However, the STIG's specify that you insert pam_faillock just after pam_env, resulting in a configuration of:
auth required pam_env.so
auth required pam_faillock.so preauth silent audit deny=3 unlock_time=900
auth sufficient pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=900 fail_interval=900
auth required pam_faillock.so authsucc deny=3 unlock_time=900 fail_interval=900
auth requisite pam_succeed_if.so uid >= 500 quiet
auth requisite pam_lsass.so smartcard_prompt try_first_pass
auth sufficient pam_lsass.so try_first_pass
auth required pam_deny.so
In our dev environment (where I write our CM automation modules), we pretty much exclusively use key or token-based login-managment (SSH keys, PKI fobs/cards or GSSAPI tokens). So, when I was originally writing our modules, everything appeared to function fine. However, when we moved the stuff to production, the complaints came in that "password logins aren't working for AD users". Ultimately, tracked it down to how, when OpenSSH doesn't receive a recognized token as part of its internal processes, OpenSSH passes off to PAM for further authentication-handling. PAM runs through the defined auth-sstack, hits pam_faillock (which doesn't grok AD-managed users) and exits. Result: even when the AD user gives a valid password, they keep getting prompted, over and over, for their password and can never login (even though SSH key-logins, Kerberos logins and password-based local user logins all still work).
I ended up side-stepping the problem by moving the pam_lsass lines ahead of the faillock lines. However, I'm concerned that, even though this fixes my login problem, it may create other problems I'm (not yet) noticing. I vaguely recall that doing such when using pam_tally and/or pam_tally2 resulted in the fail-counter getting incremented, even when the AD-auth module indicated a success condition.
So, my question is, "is there a better solution than simply moving pam_lsass ahead of pam_faillock?
Responses
Tom,
I can see that no one has responded to your post so it only looks like you and I have the same situation. I am about to try your workaround "sidestep" solution but I wonder have you found any true answer to your question, or noticed any negative effects from moving the pam_faillock.so lines below the pam_lsass.so lines?
Is there anyway you can send me your password-auth and system-auth files? I tried just moving the lsass lines up and it still breaks AD authentication if I have
auth required pam_faillock.so preauth silent deny=3 unlock_time=604800 fail_interval=900
active in the system-auth file. If I remove / comment it out then CLI login works fine with all the faillocks in the password-auth, but GUI logon doesn't work if there are faillocks in password-auth ... well I got frustrated with it being the end of the day and just commented them all out of the password-auth file and left.
Possibly a paperwork workaround. Doesn't all this faillock stuff only work on the accounts local to the RHEL box? The AD account lockout settings, etc. are controlled on the DC. If we remove these from the pam files and state to our ISSOs / ISSMs that all account management happens in AD then they should accept the risk right? That is if we don't make local accounts.
I had a similar problem with local user authentication spilling into sssd module (for AD/LDAP) if the local user was locked but provided a valid password during the lockout period. I ended up re-routing them via a pam_localuser module to skip over the pam_faillock/pam_unix combo, and added an additional "auth requisite pam_deny" so it didn't leak into SSSD section:
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
# if user account (UID>=1000) flow to localuser module, else skip to unix/faillock block
auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet
# If localuser flow into unix/faillock block, else skip to SSSD section
auth [default=5 ignore=ignore success=ok] pam_localuser.so
auth required pam_faillock.so preauth audit deny=3 unlock_time=900
auth [success=1 default=bad] pam_unix.so
auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=900
auth sufficient pam_faillock.so authsucc audit deny=3 unlock_time=900
# die if local auth gets this far..
auth requisite pam_deny.so
# SSSD auth section (AD/LDAP)
# Fail auth and exit immediately if service account (UID<1000)
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
4th module is the kicker. The pam_succeed_if's were auto-added by authconfig from realmd, not critical to your issue I think
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.