210.2. PAM authentication
Weight: 3
Description: The candidate should be able to configure PAM to support authentication using various available methods. This includes basic SSSD functionality.
Key Knowledge Areas:
- PAM configuration files, terms and utilities
- passwd and shadow passwords
- Use sssd for LDAP authentication
Terms and Utilities:
- /etc/pam.d/
- pam.conf
- nsswitch.conf
- pam_unix, pam_cracklib, pam_limits, pam_listfile, pam_sss
- sssd.conf
Having Control over users and Authenticatios and auditing is so important. But there is not just one Authentication source which alway we use. There are different authentication sources like traditionamunix shadow file, LDAP servers, old Nis.
PAM is a kind of abstaraction layer which seats between programs and different kinds of Authentication sources, and handles the process of negotiating with authentication source and take the result back to the program.

This way developers do not need to find out how to design their programs to deal with different authentication sources and they just concentrate on their programs and use pam. From another perspective when a new authentication source implemented, there is no need to change programs, just implement a new pammodule and use it again and again, this way pam bring kind of mobilabilty for programs too.

Any program like passwd, or su which deal with username and password use pam. To do that, the program should work with pam library file pam_lib . PAM by itself is using configuration files /etc/pam.d. PAM is modular and uses differnt modules which are placed in /lib/security .
For example lets check login tool to findout if it uses pam or not(CentOS 7) :
[root@centos7-1 ~]# ldd $(which login)
linux-vdso.so.1 => (0x00007fff3cdfe000)
libpam.so.0 => /lib64/libpam.so.0 (0x00007f1b30124000)
libpam_misc.so.0 => /lib64/libpam_misc.so.0 (0x00007f1b2ff20000)
libaudit.so.1 => /lib64/libaudit.so.1 (0x00007f1b2fcf7000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f1b2fad0000)
libc.so.6 => /lib64/libc.so.6 (0x00007f1b2f703000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f1b2f4ff000)
libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00007f1b2f2f9000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f1b2f097000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1b30333000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1b2ee7b000)
libpam
andlibpam_misc
bring passwd tool to the pam.The /etc/pam.d/ directory contains the PAM configuration files for each PAM-aware application. In earlier versions of PAM, the /etc/pam.conf file was used, but this file is now deprecated and is only used if the /etc/pam.d/ directory does not exist:
[root@centos7-1 ~]# cd /etc/
[root@centos7-1 etc]# cat pam.conf
cat: pam.conf: No such file or directory
[root@centos7-1 ~]# cd
[root@centos7-1 ~]# cd /etc/pam.d/
[root@centos7-1 pam.d]# ls
atd gdm-pin postlogin-ac su
chfn gdm-smartcard ppp sudo
chsh ksu remote sudo-i
config-util liveinst runuser su-l
crond login runuser-l system-auth
cups other setup system-auth-ac
fingerprint-auth passwd smartcard-auth systemd-user
fingerprint-auth-ac password-auth smartcard-auth-ac vlock
gdm-autologin password-auth-ac smtp vmtoolsd
gdm-fingerprint pluto smtp.postfix xserver
gdm-launch-environment polkit-1 sshd
gdm-password postlogin sssd-shadowutils
Every binary which has some thing to do with pam need to have a configuration file.There are some generic configuration files also. Configuration files define what should exactly happen. PAM Configuration File Format is like this :
<service> <module-interface> <control-flag> <module-name> <module-arguments>
1-Service: It defines what service, this line of configuration is about. Like ssh, or FTP. This way /etc/pam.conf file becomes a one huge file with many lines, that doesn't seem so good which is why in many moder linux distrobutions each service has its own configuration file with its name inside /etc/pam.d directory, as you can see above. Lets take a look at one of them before countinue:
[root@centos7-1 pam.d]# cat login
#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth substack system-auth
auth include postlogin
account required pam_nologin.so
account include system-auth
password include system-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
session optional pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open
session required pam_namespace.so
session optional pam_keyinit.so force revoke
session include system-auth
session include postlogin
-session optional pam_ck_connector.so
system-auth is a generic configuration file that is included almost in every process that do some thing with authentication.
[root@centos7-1 pam.d]# cat system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth sufficient pam_fprintd.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
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 nullok try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
2- module-interface: Four types of PAM module interface are available. Each of these corresponds to a different aspect of the authorization process:
- auth: This module interface authenticates use. For example, it requests and verifies the validity of a password. Modules with this interface can also set credentials, such as group memberships or Kerberos tickets.
- account: This module interface verifies that access is allowed. For example, it may check 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. For better understandning take a look at control.
3- control-flag : All PAM modules generate a success or failure result when called. Control flags tell PAM what do with the result. Modules can be stacked in a particular order, and the control flags determine how important the success or failure of a particular module is to the overall goal of authenticating the user to the service.
There are several simple flags, which use only a keyword to set the configuration:
- 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
required
orrequisite
module test. - 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.
- sufficient : The module result is ignored if it fails. However, if the result of a module flagged
sufficient
is successfuland no previous modules flaggedrequired
have 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
optional
only 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.
4-pam module name : The module name provides PAM with the name of the pluggable module 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.5- module arguments : PAM uses _arguments _to pass information to a pluggable module during authentication for some modules. For example:
auth required pam_userdb.so db=/path/to/MyDB_file
Invalid arguments are generally ignored and do not otherwise affect the success or failure of the PAM module. Some modules, however, may fail on invalid arguments. Most modules report errors to the
/var/log/secure
file.Now that we now the format of PAM configuration file lets take a look at another one:
[root@centos7-1 pam.d]# cat sshd
#%PAM-1.0
auth required pam_sepermit.so
auth substack password-auth
auth include postlogin
# Used with polkit to reauthorize users in remote sessions
-auth optional pam_reauthorize.so prepare
account required pam_nologin.so
account include password-auth
password include password-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open env_params
session required pam_namespace.so
session optional pam_keyinit.so force revoke
session include password-auth
session include postlogin
# Used with polkit to reauthorize users in remote sessions
-session optional pam_reauthorize.so prepare
As you can see there are some generic configuration files like password-auth wich might be included and used in other configuration files again and again.
There is a place for pam modules itself:
[root@centos7-1 pam.d]# cd /lib64/security/
[root@centos7-1 security]# ls
pam_access.so pam_gdm.so pam_permit.so pam_time.so
pam_cap.so pam_gnome_keyring.so pam_postgresok.so pam_timestamp.so
pam_chroot.so pam_group.so pam_pwhistory.so pam_tty_audit.so
pam_console.so pam_issue.so pam_pwquality.so pam_umask.so
pam_cracklib.so pam_keyinit.so pam_rhosts.so pam_unix_acct.so
pam_debug.so pam_lastlog.so pam_rootok.so pam_unix_auth.so
pam_deny.so pam_limits.so pam_securetty.so pam_unix_passwd.so
pam_echo.so pam_listfile.so pam_selinux_permit.so pam_unix_session.so
pam_env.so pam_localuser.so pam_selinux.so pam_unix.so
pam_exec.so pam_loginuid.so pam_sepermit.so pam_userdb.so
pam_faildelay.so pam_mail.so pam_shells.so pam_warn.so
pam_faillock.so pam_mkhomedir.so pam_sss.so pam_wheel.so
pam_filter pam_motd.so pam_stress.so pam_xauth.so
pam_filter.so pam_namespace.so pam_succeed_if.so
pam_fprintd.so pam_nologin.so pam_systemd.so
pam_ftp.so pam_oddjob_mkhomedir.so pam_tally2.so
If new way of authentication has been invented(Like finger print reader), there is a place which requied module should be placed and integrated with pam configuration files.
For lPIC2 exam we are required to know some of these modules:
- pam_unix
- pam_cracklib
- pam_limits
- pam_listfile
- pam_sss
pam_unix: This module configures authentication via /etc/passwd and /etc/shadow.
The pam_unix.so module supports the following management groups:
account
The type “account” does not authenticate the user but checks other things such as the expiration date of the password and might force the user to change his password based on the contents of the files /etc/passwd and /etc/shadow.
The following options are supported:
debug
Log information using syslog.
audit
Also logs information, even more than debug does.
auth
The type “auth” checks the user's password against the password database(s). This component is configured in the file /etc/nsswitch.conf. Please consult the man page (man nsswitch.conf) for further details.
The following options are supported:
audit
Log information using syslog.
debug
Also logs information using syslog but less than audit.
nodelay
This argument sets the delay-on-failure, which has a default of a second, to nodelay.
nullok
Allows empty passwords. Normally authentication fails if the password is blank.
try_first_pass
Use the password from the previous stacked auth module and prompt for a new password if the retrieved password is blank or incorrect.
use_first_pass
Use the result from the previous stacked auth module, never prompt the user for a password and fails if the result was a fail.
password
The type “password” changes the user's password.
The following options are supported:
audit
Log information using syslog.
bigcrypt
Use the DEC “C2” extension to crypt().
debug
Also logs information using syslog but less than audit.
md5
Use md5 encryption instead of crypt().
nis
Use NIS (Network Information Service) passwords.
not_set_pass
Don't use the passwords from other stacked modules and do not give the new password to other stacked modules.
nullok
Allows empty passwords. Normally authentication fails if the password is blank.
remember
Remember the last n passwords to prevent the user from using one of the last n passwords again.
try_first_pass
Use the password from the previous stacked auth module, and prompt for a new password if the retrieved password is blank or incorrect.
use_authtok
Set the new password to the one provided by a previous module.
use_first_pass
Use the result from the previous stacked auth module, never prompt the user for a password and fails if the result was a fail.
session
The type “session” uses syslog to log the user's name and session type at the start and end of a session.