Abstract
| Goal |
Manage authentication, authorization, session settings, and password controls by configuring Pluggable Authentication Modules (PAM). |
| Sections |
|
| Lab |
|
Interpret PAM configuration files and select appropriate configuration profiles with the authselect utility.
The Pluggable Authentication Modules (PAM) system provides a generic way for applications to implement support for authentication and authorization.
Initially, an application that needed to authenticate users used the local /etc/passwd and /etc/shadow files.
Eventually, other authentication mechanisms were invented.
For example, your company might decide to implement Kerberos, in which case the application must verify the correctness of the passwords against the Kerberos Key Distribution Center (KDC).
Alternatively, you might choose to deploy a Lightweight Directory Access Protocol (LDAP) infrastructure, and so the application must contact the LDAP server for authentication.
As a result, every time that a new authentication method emerged, applications had to be rewritten to support it. Each application was handled separately, which led to a duplication of effort, and led to many implementations that had to be audited for correctness.
A PAM-enabled application calls the PAM library, libpam, to perform all authentication tasks on its behalf and to return a pass or fail response to the application.
The PAM modules implement these different authentication methods.
For example, the pam_krb5 module performs authentication against Kerberos.
The pam_ldap module authenticates against an LDAP server.
The pam_unix module uses the standard local files, /etc/passwd and /etc/shadow.
The PAM-enabled applications can directly use these authentication methods without having to be modified or recompiled.
The following figure provides an overview of how PAM-enabled applications authenticate users.
In this figure, the login program contacts PAM for authentication.
PAM reads the /etc/pam.d/login configuration file to retrieve the list of modules to use for authentication.
PAM calls the modules, in the /usr/lib64/security/ directory, and these modules perform the authentication.
PAM returns a successful authentication status to the login program.
The vsftpd FTP server also uses PAM to authenticate FTP users, but in the figure, the user provides incorrect credentials, and PAM returns a fail code to the vsftpd FTP server.
Determining whether a client is permitted to access a resource is a two-step process. First, the application must authenticate the client. That is, the application must prove that the client is who they claim to be. Then, the application must determine whether that client is authorized to access the resource.
For example, a client that types the correct username and password at a login prompt has authenticated that they are that user. However, access control restrictions might not authorize that user to log in at the current time, so the client might be returned to the login prompt.
PAM manages both authentication and authorization.
PAM configuration files determine the modules that are used for each application.
Each PAM-enabled application has its own PAM configuration file in the /etc/pam.d/ directory, and generally this file has the same name as the application.
For example, the login program uses the /etc/pam.d/login file, and the sshd daemon uses the /etc/pam.d/sshd file.
If the service file for an application is missing, then PAM uses the /etc/pam.d/other file by default.
These configuration files contain rules that specify the modules to call for authentication and authorization.
In this way, each application can use a different authentication method.
However, applications often use the same sets of authentication methods.
Most PAM configuration files use the include or substack directives to include a common configuration from the password-auth or system-auth files, which are also in the /etc/pam.d/ directory.
In Red Hat Enterprise Linux 8 and later versions, administrators are no longer expected to edit PAM configuration files directly.
Instead, you can select security profiles by using the authselect tool.
When a profile is selected, the authselect tool modifies the /etc/nsswitch.conf file and the configuration files in the /etc/pam.d/ and /etc/dconf/db/distro.d/ directories.
When using the authselect tool to manage PAM configurations, do not edit the managed configuration files manually.
The authselect tool overwrites any modifications to managed files when the tool runs, such as during system updates.
You do not need to use the authselect tool if any of the following conditions apply:
Your host is part of Red Hat Enterprise Linux Identity Management (IdM).
Joining your host to an IdM domain with the ipa-client-install command automatically configures the System Security Services Daemon (SSSD) authentication on your host.
Your host is part of Active Directory via SSSD.
Calling the realm join command to join your host to an Active Directory domain automatically configures SSSD authentication on your host.
Red Hat recommends against changing the authselect profiles that are configured by the ipa-client-install or realm join commands.
If you need to modify the authselect profiles, then display the current settings before making any modifications, so that you can revert to the current settings if necessary:
[root@host ~]# authselect current
Profile ID: sssd
Enabled features:
- with-sudo
- with-mkhomedir
- with-smartcardRed Hat Enterprise Linux 8 and later versions provide several security profiles.
You can list the available security profiles by using the authselect list command.
minimal
This profile is for minimal installations with only local users.
nis
This profile enables Network Information Service (NIS) for system authentication.
sssd
This profile enables the SSSD for system authentication. This profile is the typical profile to use with LDAP or other identity providers.
winbind
This profile enables winbind for system authentication.
The security profile that you choose depends on your organization's environment and security requirements.
Each security profile can implement additional features, which enable specific additional PAM modules or which adjust existing PAM configurations.
To see the available additional features for a security profile, use the authselect list-features command.
The following example lists the additional feature options for the minimal profile:
[root@host ~]# authselect list-features minimal
with-altfiles
with-custom-aliases
with-custom-automount
with-custom-ethers
with-custom-group
with-custom-hosts
with-custom-initgroups
with-custom-netgroup
with-custom-networks
with-custom-passwd
with-custom-protocols
with-custom-publickey
with-custom-rpc
with-custom-services
with-custom-shadow
with-ecryptfs
with-faillock
with-mkhomedir
with-pamaccess
with-pwhistory
with-silent-lastlog
without-nullokTo select a security profile, use the authselect select command.
The following example selects the minimal security profile:
[root@host ~]# authselect select minimal
Profile "minimal" was selected.
...output omitted...You can select additional features by appending them to the authselect select command.
The following example selects the minimal security profile with the with-pwhistory and with-mkhomedir additional features:
[root@host ~]# authselect select minimal with-pwhistory with-mkhomedir
Profile "minimal" was selected.
...output omitted...You can view the current authselect security profile and additional features by using the authselect current command.
[root@host ~]# authselect current
Profile ID: sssd
Enabled features:
- with-mkhomedir
- with-silent-lastlog
- with-mdns4Security features with additional options have configuration files in the /etc/security/ directory.
You can edit these configuration files to further customize the security options on a system.
Because each configuration file contains different options that are specific to the application or PAM module, Red Hat recommends reviewing the man page for a configuration file before editing it.
You can view the PAM configuration files that the authselect tool generates in the /etc/pam.d/ directory to see the exact configuration effects.
Application configuration files in the /etc/pam.d/ directory follow a standard format for their rules:
type control module [module arguments]
The following output shows the /etc/pam.d/system-auth file as an example.
[root@host ~]# cat /etc/pam.d/system-auth
# Generated by authselect
# Do not modify this file manually, use authselect instead. Any user changes will be overwritten.
# See authselect(8) for more details.
auth required pam_env.so
auth required pam_faildelay.so ...
auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular
auth [default=1 ignore=ignore success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok
auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_usertype.so issystem
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_pwquality.so ...
password sufficient pam_unix.so ...
password [success=1 default=ignore] pam_localuser.so
password sufficient pam_sss.so use_authtok
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
session [success=1 default=ignore] pam_succeed_if.so ...
session required pam_unix.so
session optional pam_sss.soThe first field is the type, and organizes the tests into four management groups: auth, account, password, and session.
The application invokes each group at a different time during a user authentication and authorization process.
Table 5.1. PAM Rule Types
| Type | Description |
|---|---|
auth
| The application verifies the rules in that management group when a user is authenticating.
Users must pass these rules to validate their identity.
In the previous output, one of the rules in this group calls the pam_unix module.
This module verifies the provided username and password against the /etc/shadow file. |
account
| The application uses the account management group to verify that an account is valid at this time, and that
passwords are not expired.
In other words, the application determines whether access by that account is authorized.
In the preceding example /etc/pam.d/system-auth file, a rule also calls the pam_unix module in the account management group.
In this group, the pam_unix module determines from the expiration information in the /etc/shadow file whether the password is still valid. |
password
| Modules in the password management group control password changes.
The rules in this management group do not involve authentication or authorization.
If the application provides a feature for users to change their password, then PAM calls these rules when a user attempts to change their password through the application.
In the previous /etc/pam.d/system-auth file, the pam_pwquality module is the first in this group.
This module verifies the quality of the new password from the user.
The pam_pwquality module is described in more detail in the following section.
The pam_unix module is called next.
In that password management group, the pam_unix module stores the new password in the /etc/shadow file. |
session
| The application calls the rules in this management group at the start and at the end of a user session. These rules manage tasks such as logging, and device or console ownership. |
The order of the rules in a management group is essential, because PAM rules are parsed and executed from top to bottom.
For a dash (-) character in front of a type, such as -session near the end of the /etc/pam.d/system-auth file, PAM silently skips the rule if the module file is missing.
Some modules, such as the pam_unix module, can be called in multiple management groups.
When PAM calls these modules, they know in which group they are running and adapt their behavior accordingly.
The next field, the control field, determines how the associated test affects the group's overall result. Of the many possible values for this field, the most common ones are included in the following table:
Table 5.2. Common PAM Controls
| Control | Description |
|---|---|
required
| The associated module must succeed.
If the associated module fails, then PAM sets the management group overall result to fail.
The other rules are still tested, to disguise the reason for the failure from a potential attacker. |
requisite
| This control is similar to required, but requisite stops testing on error.
PAM directly gives back the control to the application or to the calling file.
The substack control describes how to perform such a call. |
sufficient
| This control returns success immediately to the application or to the calling file if the associated module succeeds and no previous module failed. If the module fails, then PAM ignores the test and continues checking. |
optional
| PAM ignores the result of the test, even if it fails. |
include
| This control includes the rules from the provided PAM configuration file as if you directly entered them at that point. |
substack
| This control works like include, except that a failed test in the called file gives back the control to the current file instead of giving the control to the application. |
The next field is the PAM module itself.
Although you can give the full path to the module, usually you give only the relative path.
PAM looks for the modules in the /usr/lib64/security/ directory.
Modules return a code that PAM interprets as either success or error. PAM modules can also take options or arguments to alter their behavior. Not every module takes arguments, and options or arguments are usually unique to a specific module.
The sssd security profile allows user authentication against remote identity management services, such as LDAP and Kerberos.
When a remote user authenticates on the local system, SSSD stores their credentials and authentication parameters to a local cache.
This way, even if the remote authentication server is not reachable, the remote user can still log in to the local system.
This feature is particularly useful for laptops that are disconnected from the company network, and it also helps to reduce the load on the remote authentication services.
You can view documentation for authselect security profiles by using the authselect show command.
This documentation includes a description of the security profile, information about additional configuration, and information about each optional feature of the profile.
Documentation for configuration files for security features in the /etc/security/ directory can be found in the man pages.
Each configuration file has an associated man page with descriptions, options, defaults, and syntax information.
For example, the /etc/security/faillock.conf configuration file is documented by the faillock.conf (5) man page.
Additionally, PAM modules have documentation through the man pages. Most of the modules have a dedicated man page with the following information:
A description of the module.
The module groups in which you can use it: auth, account, password, or session.
Some modules can be used in several groups.
At runtime, the behavior of such modules depends on the module group that they are running in.
A list and description of the module parameters.
The return codes.
Some usage examples.
For example, the pam_unix module is documented by the pam_unix (8) man page.
The man page names do not include the .so module extension.
The pam.conf(5) man page describes the full syntax of the PAM configuration files.
The PAM man pages typically start with the pam_ prefix.
The man -k pam_ command returns a long list of related man pages.
The authselect (8), pam.conf (5), and pam_* (8) man pages.
For more information, refer to the Configuring User Authentication Using authselect chapter in the Red Hat Enterprise Linux 9 Configuring Authentication and Authorization in Red Hat Enterprise Linux guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/configuring_authentication_and_authorization_in_rhel/index#configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel