Red Hat Certified System Administrator(RHCSA)
Manage Users and Groups
Configure PAM
Welcome to this detailed guide on configuring Pluggable Authentication Modules (PAM). In this article, you'll learn the fundamentals of authentication, explore the PAM configuration files, and see how to modify them for various authentication scenarios.
Understanding Authentication with su
When you run a command like su
, it prompts for the root user's password. Entering the correct password proves your identity and grants you the privileges of the root user. For example:
[aaron@LFCS-CentOS ~]$ su
Password:
[aaron@LFCS-CentOS ~]$
This simple interaction demonstrates how authentication works. Not only do humans authenticate, but programs also use authentication to verify and share confidential data with one another.
Introducing PAM
Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users. With PAM, you can plug in different authentication methods, customize utilities like su
, and even require specific actions like plugging in a USB security token for authentication.
PAM's configuration files can be found in the /etc/pam.d
directory. To inspect the directory contents, run:
[aaron@LFCS-CentOS ~]$ ls /etc/pam.d/
atd gdm-launch-environment remote
chfn gdm-password runuser
chsh gdm-pin runuser-l
cockpit gdm-smartcard smartcard-auth
config-util login smtp
crond other sssd
cups passwd sssd-shadowutils
fingerprint-auth password-auth su
gdm-autologin polkit-1 sudo
gdm-fingerprint postlogin sudo-i
system-auth su-l
Notice the su
file in the directory, which defines the PAM modules for the su
utility. Let’s take a closer look at its contents.
[aaron@LFCS-CentOS ~]$ ls /etc/pam.d/
atd gdm-launch-environment gdm-password gdm-pin
gdm-smartcard login other passwd
fingerprint-auth password-auth polkit-1 postlogin
gdm-autologin
In this demonstration, after providing the necessary password for authentication, we modify the configuration. Below is an example snippet from the PAM configuration file:
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
auth substack system-auth
auth include postlogin
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session include postlogin
session optional pam_xauth.so
By uncommenting the line containing pam_wheel.so trust use_uid
, an additional authentication module is activated. When you execute su
, the modules are processed in the specified order, each serving its distinct purpose.
Note
PAM modules are categorized into four types:
- auth modules: Verify the identity of a user.
- account modules: Manage tasks related to user accounts.
- password modules: Handle password updates.
- session modules: Prepare the user's session after authentication.
How PAM Modules Work
The control fields (e.g., required, sufficient, requisite) in the configuration determine how each module's result affects the overall authentication process:
- required: Every module marked as required runs, even if one fails. All must pass for authentication to succeed.
- requisite: If a module fails, the process halts immediately.
- sufficient: If a module passes, remaining modules may be skipped.
For example, the pam_rootok.so
module allows the root user to bypass password authentication if the module returns a success.
Here’s the improved configuration snippet with proper alignment for clarity:
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
auth substack system-auth
auth include postlogin
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session include postlogin
session optional pam_xauth.so
For more detailed information about these modules and their control flags, consult the PAM configuration manual:
man pam.conf
Choosing the Right Control Flags
Consider a scenario where you want the user to authenticate only if they provide both a personal USB security token and a password. In such a case, both modules should be set as required. If only one authentication method succeeds, the overall authentication will fail. Alternatively, if you wish to allow access when either method is successful, you would configure both modules as sufficient.
The difference between control flags like required, requisite, and sufficient can significantly alter the authentication flow. For instance, a failing requisite module halts the process immediately, whereas a failing required module still lets subsequent modules run to log the attempt or perform other tasks.
Below is another display of the detailed PAM configuration:
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
auth substack system-auth
auth include postlogin
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session include postlogin
session optional pam_xauth.so
Additional documentation on the PAM API and its control fields is available in the module manual pages.
Exploring PAM Modules with man
To see an overview of available PAM modules, execute:
[aaron@LFCS-CentOS ~]$ man pam
This command displays manual pages for modules such as pam_unix
, pam_wheel
, and others. For an in-depth look at the configuration details, try:
man pam.conf
This will list modules with their functionalities. A typical output might resemble:
[aaron@LFCS-CentOS ~]$ man pam.conf
pam
pam_access pam_keyinit pam_lastlog
pam.conf pam_limits pam_listfile
pam_console pam_localuser pam_loginit
pam_console_apply pam_loginuid pam_mail
pam.d pam_mkhomedir pam_motd
pam_debug pam_namespace pam_nologin
pam_env.conf pam_oddjob_mkhomedir pamon
pam_failedt pam_permit pam_postgresok
pam_faillock pam_pwistory pam_pwquality
pam_filter pam_rhosts pam_rootok
pam_exec pam_security pam_succeed_if
pam_deny pam_selinux pam_sepermit
pam_echo pam_shells pam_ssh_add
pam_env pam_sss pam_sss_gss
pam_issue pam_systemd pam_time
pam_exec pam_timestamp pam_timestamp_check
pam_failetd pam_tty_audit pam_umask
pam_unix pam_userdb pam_usertype
pam_warn pam_wheel pam_xauth
This command is an excellent way to explore and understand the numerous options available with each PAM module.
Testing the New PAM Configuration
After modifying your PAM configuration for the su
command, confirm that your user is a member of the wheel
group with:
[aaron@LFCS-CentOS ~]$ groups
aaron wheel family
Since the configuration now includes the pam_wheel.so trust use_uid
module, being part of the wheel
group should let you switch to the root user without needing a password:
[aaron@LFCS-CentOS ~]$ su
[root@LFCS-CentOS aaron]#
To exit the root session, simply type:
[aaron@LFCS-CentOS ~]$ exit
exit
[aaron@LFCS-CentOS ~]$
Summary
In this article, we explored how PAM allows you to configure authentication modules in a specific sequence, with diverse control flags that influence the authentication process. We reviewed the syntax of PAM configuration files, observed key modules like pam_rootok.so
and pam_wheel.so
, and tested the changes using the su
command.
For further information, remember to consult these resources:
Proceed to your next demo or lecture for more in-depth coverage of system authentication strategies.
Watch Video
Watch video content
Practice Lab
Practice lab