10.2. About PAM Configuration Files
/etc/pam.d/directory. Each file in this directory has the same name as the service to which it controls access. For example, the
loginprogram defines its service name as
loginand installs the
/etc/pam.d/loginPAM configuration file.
authconfigtool instead of manually editing the PAM configuration files.
10.2.1. PAM Configuration File Format
module_interface control_flag module_name module_arguments
auth required pam_unix.so
auth— This module interface authenticates users. For example, it requests and verifies the validity of a password. Modules with this interface can also set credentials, such as group memberships.
account— This module interface verifies that access is allowed. For example, it checks if a user account has expired or if a user is allowed to log in at a particular time of day.
password— This module interface is used for changing user passwords.
session— This module interface configures and manages user sessions. Modules with this interface can also perform additional tasks that are needed to allow access, like mounting a user's home directory and making the user's mailbox available.
pam_unix.soprovides all four module interfaces.
pam_unix.so, provides PAM with the name of the library containing the specified module interface. The directory name is omitted because the application is linked to the appropriate version of
libpam, which can locate the correct version of the module.
required— The module result must be successful for authentication to continue. If the test fails at this point, the user is not notified until the results of all module tests that reference that interface are complete.
requisite— The module result must be successful for authentication to continue. However, if a test fails at this point, the user is notified immediately with a message reflecting the first failed
sufficient— The module result is ignored if it fails. However, if the result of a module flagged
sufficientis successful and no previous modules flagged
requiredhave failed, then no other results are required and the user is authenticated to the service.
optional— The module result is ignored. A module flagged as
optionalonly becomes necessary for successful authentication when no other modules reference the interface.
include— Unlike the other controls, this does not relate to how the module result is handled. This flag pulls in all lines in the configuration file which match the given parameter and appends them as an argument to the module.
requisitevalue, then the order in which the modules are listed is important to the authentication process.
setuputility normally uses several stacked modules, as seen in its PAM configuration file:
[root@MyServer ~]# cat /etc/pam.d/setup auth sufficient pam_rootok.so auth include system-auth account required pam_permit.so session required pam_permit.so
auth sufficient pam_rootok.so— This line uses the
pam_rootok.somodule to check whether the current user is root, by verifying that their UID is 0. If this test succeeds, no other modules are consulted and the command is executed. If this test fails, the next module is consulted.
auth include system-auth— This line includes the content of the
/etc/pam.d/system-authmodule and processes this content for authentication.
account required pam_permit.so— This line uses the
pam_permit.somodule to allow the root user or anyone logged in at the console to reboot the system.
session required pam_permit.so— This line is related to the session setup. Using
pam_permit.so, it ensures that the
setuputility does not fail.
pam_pwquality.somodule checks how strong a password is and can take several arguments. In the following example,
enforce_for_rootspecifies that even password of the root user must successfully pass the strength check and
retrydefines that a user will receive three opportunities to enter a strong password.
password requisite pam_pwquality.so enforce_for_root retry=3
journaldservice. For information on how to use
journaldand the related
journalctltool, see the System Administrator's Guide.
journaldservice was introduced in Red Hat Enterprise Linux 7.1. In previous versions of Red Hat Enterprise Linux, most modules report errors to the
10.2.2. Annotated PAM Configuration Example
Example 10.1. Simple PAM Configuration
#%PAM-1.0 auth required pam_securetty.so auth required pam_unix.so nullok auth required pam_nologin.so account required pam_unix.so password required pam_pwquality.so retry=3 password required pam_unix.so shadow nullok use_authtok session required pam_unix.so
- The first line is a comment, indicated by the hash mark (
#) at the beginning of the line.
- Lines two through four stack three modules for login authentication.
auth required pam_securetty.so— This module ensures that if the user is trying to log in as root, the TTY on which the user is logging in is listed in the
/etc/securettyfile, if that file exists.If the TTY is not listed in the file, any attempt to log in as root fails with a
auth required pam_unix.so nullok— This module prompts the user for a password and then checks the password using the information stored in
/etc/passwdand, if it exists,
pam_unix.somodule to allow a blank password.
auth required pam_nologin.so— This is the final authentication step. It checks whether the
/etc/nologinfile exists. If it exists and the user is not root, authentication fails.
NoteIn this example, all three
authmodules are checked, even if the first
authmodule fails. This prevents the user from knowing at what stage their authentication failed. Such knowledge in the hands of an attacker could allow them to more easily deduce how to crack the system.
account required pam_unix.so— This module performs any necessary account verification. For example, if shadow passwords have been enabled, the account interface of the
pam_unix.somodule checks to see if the account has expired or if the user has not changed the password within the allowed grace period.
password required pam_pwquality.so retry=3— If a password has expired, the password component of the
pam_pwquality.somodule prompts for a new password. It then tests the newly created password to see whether it can easily be determined by a dictionary-based password cracking program.The argument
retry=3specifies that if the test fails the first time, the user has two more chances to create a strong password.
password required pam_unix.so shadow nullok use_authtok— This line specifies that if the program changes the user's password, using the
passwordinterface of the
- The argument
shadowinstructs the module to create shadow passwords when updating a user's password.
- The argument
nullokinstructs the module to allow the user to change their password from a blank password, otherwise a null password is treated as an account lock.
- The final argument on this line,
use_authtok, provides a good example of the importance of order when stacking PAM modules. This argument instructs the module not to prompt the user for a new password. Instead, it accepts any password that was recorded by a previous password module. In this way, all new passwords must pass the
pam_pwquality.sotest for secure passwords before being accepted.
session required pam_unix.so— The final line instructs the session interface of the
pam_unix.somodule to manage the session. This module logs the user name and the service type to
/var/log/secureat the beginning and end of each session. This module can be supplemented by stacking it with other session modules for additional functionality.