Score:0

Issues getting sssd, PAM, and faillock to play along on RHEL7

de flag

I am having an issue that I'm almost certainly is tied to how I have faillock configured in my PAM system-auth and password-auth on some RHEL7 servers. We are required to use STIGs, so I have to use faillock with specific options associated with it. For general user access via SSH, everything is fine. The issue only presents itself when running a Nessus/vulnerability scan via username and password for authentication. The strange thing is, I'm able to SSH in and run all of the sudo commands using the same scanning account, and the scanner is reporting no issues authenticating in initially. However, at some point, the scan hitting the 3 invalid passwords and triggering faillock to prevent access. From the logs I've seen, my guess is the password is failing when it's being used for sudo, which I believe is the system-auth file. If I drop the faillock configs out of my password-auth and system-auth, the scans run fine. If I use an AD account, I do not have this issue, but I believe that's only because the AD accounts aren't bound to faillock. This issue also only cropped up after we integrated our RHEL7 servers into AD via sssd, but that process also requires running some authconfig changes.

This is the authconfig file I'm using now, but I've tried a few variations with changing line placement, how many lines to skip, etc. all to no success. It's likely something obvious, but I'm not a clever man.

auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        required      pam_faillock.so preauth silent audit even_deny_root unlock_time=900 fail_interval=900 deny=3
auth        [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_pkcs11.so nodebug
auth        [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet
auth        [default=1 ignore=ignore success=ok] pam_localuser.so
auth        sufficient    pam_unix.so try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        [default=die] pam_faillock.so authfail audit deny=3 even_deny_root fail_interval=900 unlock_time=900
auth        required      pam_deny.so

account     required      pam_faillock.so
account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3  authtok_type=
password    sufficient    pam_unix.so sha512 shadow try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    requisite     pam_pwhistory.so use_authtok remember=5 retry=3
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_oddjob_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.