auth - Authentication¶

Deployer/Auditor notes¶

The Ansible tasks will ensure that PAM is configured to disallow logins from accounts with null or blank passwords. This involves removing a single option from one of the PAM configuration files:

• CentOS or RHEL: removes nullok from /etc/pam.d/system-auth
• Ubuntu: removes nullok_secure from /etc/pam.d/common-auth
• openSUSE Leap or SLE: remove nullok from /etc/pam.d/common-auth and /etc/pam.d/common-password

Deployers can opt-out of this change by setting the following Ansible variable:

security_disallow_blank_password_login: no

Deployer/Auditor notes¶

This STIG control is implemented by:

• If three unsuccessful root logon attempts within 15 minutes occur the associated account must be locked. (V-71945)

Deployer/Auditor notes¶

The STIG requires that accounts with excessive failed login attempts are locked. It sets a limit of three failed attempts in a 15 minute interval and these restrictions are applied to all users (including root). Accounts cannot be automatically unlocked for seven days.

This change might cause disruptions in production environments without proper communication to users. Therefore, this change is not applied by default.

Deployers can opt in for the change by setting the following variable:

security_pam_faillock_enable: yes

There are also three configuration options that can be adjusted by setting Ansible variables:

• security_pam_faillock_attempts: This many failed login attempts within the specified time interval with trigger the account to lock. (STIG requirement: 3 attempts)
• security_pam_faillock_interval: This is the time interval (in seconds) to use when measuring excessive failed login attempts. (STIG requirement: 900 seconds)
• security_pam_faillock_deny_root: Set to yes to apply the restriction to the root user or set to no to exempt the root user from the account locking restrictions. (STIG requirement: yes)
• security_pam_faillock_unlock_time: This sets the time delay (in seconds) before a locked account is automatically unlocked. (STIG requirement: 604800 seconds)

Deployer/Auditor notes¶

The STIG requires all users to authenticate when using sudo, but this change can be highly disruptive for automated scripts or applications that cannot perform interactive authentication. Automated edits from Ansible tasks might cause authentication disruptions on some hosts, and deployers are urged to carefully review each use of the NOPASSWD directive in their sudo configuration files.

Deployers can opt-out of this change by setting an Ansible variable:

security_sudoers_nopasswd_check_enable: no

Deployer/Auditor notes¶

The STIG requires all users to re-authenticate when using sudo, but this change can be highly disruptive for automated scripts or applications that cannot perform interactive authentication. Automated edits from Ansible tasks might cause authentication disruptions on some hosts, and deployers are urged to carefully review each use of the !authenticate directive in their sudo configuration files.

Deployer/Auditor notes¶

Deploying multi-factor authentication methods, including smart cards, is a complicated process that requires preparation and communication. This work is left to deployers to complete manually.

Deployer/Auditor notes¶

The tasks in the security role cannot determine the access levels of individual users.

Deployers are strongly encouraged to configure SELinux user confinement on compatible systems using semanage login. Refer to the Confining Existing Linux Users documentation from Red Hat for detailed information and command line examples.

Deployer/Auditor notes¶

Deployers are strongly urged to review the list of user accounts on each server regularly. Evaluation of user accounts must be done on a case-by-case basis and the tasks in the security role are unable to determine which user accounts are valid. Deployers must complete this work manually.

Deployer/Auditor notes¶

Although the STIG requires that each account is limited to 10 concurrent connections, this change might be disruptive in some environments. Therefore, this change is not applied by default.

Deployers can opt in for this change by setting a concurrent connection limit with this Ansible variable:

security_rhel7_concurrent_session_limit: 10

Deployer/Auditor notes¶

Deployers are strongly urged to utilize sssd for systems that authenticate against LDAP or Active Directory (AD) servers.

The ldap connector for sssd connects only to LDAP servers over encrypted connections. Review the man page for sssd-ldap for more details on this requirement.

Deployer/Auditor notes¶

Deployers are strongly urged to utilize sssd for systems that authenticate against LDAP or Active Directory (AD) servers.

To meet this control, deployers must ensure that ldap_tls_cacert or ldap_tls_cacertdir are set in the /etc/sssd/sssd.conf file. The ldap_tls_cacert directive specifies a single certificate while ldap_tls_cacertdir specifies a directory where sssd can find CA certificates.

Deployer/Auditor notes¶

Deployers are strongly urged to utilize sssd for systems that authenticate against LDAP or Active Directory (AD) servers.

To meet this control, deployers must ensure that ldap_tls_cacert or ldap_tls_cacertdir are set in the /etc/sssd/sssd.conf file. The ldap_tls_cacert directive specifies a single certificate while ldap_tls_cacertdir specifies a directory where sssd can find CA certificates.

Deployer/Auditor notes¶

The PAM configuration is checked for the presence of pam_lastlogin and a warning message is printed if the directive is not found. The tasks in the security role do not adjust PAM configurations since these changes might be disruptive in some environments.

Deployers should review their PAM configurations and add pam_lastlogin to /etc/pam.d/postlogin on CentOS and Red Hat Enterprise Linux or to /etc/pam.d/login on Ubuntu, openSUSE Leap and SUSE Linux Enterprise.

Deployer/Auditor notes¶

The tasks in the security role examine the filesystem for any .shosts or shosts.equiv files. If they are found, they are deleted.

The search for these files will take a very long time on systems with slow disks or systems with a large amount of files. Therefore, this task is skipped by default.

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_remove_shosts_files: yes

Deployer/Auditor notes¶

This control is implemented by the tasks for another control:

• There must be no .shosts files on the system. (V-72277)

Deployer/Auditor notes¶

Although the STIG requires that the sssd.conf contains both nss and pam authentication modules, this change can be disruptive in environments that are already using LDAP or Active Directory for authentication. Deployers should make these changes only if their environment is compatible.

Deployer/Auditor notes¶

Any adjustment to PKI authentication can cause disruptions for users. Deployers should verify that enabling OCSP validation is compatible with their existing configuration.

Deployer/Auditor notes¶

Any adjustment to PKI authentication can cause disruptions for users. Deployers should verify that their environment is compatible with smart cards before requiring them for authentication.

Deployer/Auditor notes¶

Modifying sensitive systemd unit files directly or via overrides could cause a system to have issues during the boot process. The role does not make any adjustments to the rescue.service because this service is critical during emergencies.

All of the distributions supported by the role already require authentication for single user mode.