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?