You are on page 1of 18

Chapter 27

Pluggable Authentication
Modules (PAM)
Programs that give privileges to users
must properly authenticate (verify the identity of)
each user.
When you log in to a system, you
provide your username and password, and the
login process uses the username and password
to authenticate the login — to verify that you are
who you say you are.
Forms of authentication other than
passwords are possible, and the passwords can
be stored in different ways.
Pluggable Authentication Modules (PAM)
is a way of allowing the system
administrator to set an authentication policy
without having to recompile authentication
With PAM, you control how
particular authentication modules are
plugged into a program by editing that
program's PAM configuration file in
Most Red Hat Linux users will never
need to alter PAM configuration files for any of
their programs. When you use RPM to install
programs that require authentication, they
automatically make the changes necessary to do
normal password authentication using PAM.

However, if you need to customize your

configuration, you must understand the structure
of a PAM configuration file. More information can
be found in the section called PAM modules.
Advantages of PAM
When used correctly, PAM provides many advantages
for a system administrator, such as the following:
A common authentication scheme that can be used
with a wide variety of applications.
PAM can be implemented with various applications
without having to recompile the applications to
specifically support PAM.
Great flexibility and control over authentication for the
administrator and application developer.
Application developers do not need to develop their
program to use a particular authentication scheme.
Instead, they can focus purely on the details of their
PAM Configuration Files
The directory /etc/pam.d contains the PAM
configuration files. In earlier versions of PAM,
/etc/pam.conf was used. The pam.conf file is still
read if no /etc/pam.d/ entry is found, but its use is

Each application (or service, as applications

designed to be used by many users are commonly
known) has its own file. Each line in the file has five
elements: service name, module type, control flag,
module path, and arguments
PAM Service Names
The service name of every PAM-enabled
application is the name of its configuration file
in /etc/pam.d. Each program which uses PAM
defines its own service name.
For example, the login program defines
the service name login, ftpd defines the
service name ftp, and so on.
In general, the service name is the name
of the program used to access the service, not
the program used to provide the service.
PAM Modules
PAM includes four different types of modules
for controlling access to a particular service:
An auth module provides the actual
authentication (perhaps asking for and
checking a password) and sets credentials,
such as group membership or Kerberos tickets.
An account module checks to make sure that
access is allowed for the user (the account has
not expired, the user is allowed to log in at this
time of day, and so on).
A password module is used to set passwords.
A session module is used after a user has
been authenticated. A session module
performs additional tasks which are needed to
allow access.
These modules may be stacked, or placed
upon one another, so that multiple modules
are used.
The order of a module stack is very
important in the authentication process,
because it makes it very easy for an
administrator to require that several conditions
exist before allowing user authentication to
Before someone is allowed to
rlogin, PAM verifies that the /etc/nologin file
does not exist, that they are not trying to log
in remotely as root over an unencrypted
network connection, and that any
environmental variables can be loaded.
Then, a successful rhosts
authentication is performed before the
connection is allowed. If rhosts
authentication fails, then standard password
authentication is done.
New PAM modules can be added at any
time, and PAM-aware applications can then be made to
use them. For example, if you create a one-time-
password creation method and write a PAM module to
support it, PAM-aware programs can immediately use
the new module and password method without being
recompiled or otherwise modified in any way.

As you can imagine, this is very

beneficial, because it lets you mix-and-match, as well as
test, authentication methods very quickly with different
programs without having to recompile the programs.
Documentation on writing modules is included with the
system in /usr/share/doc/pam—<version-number>.
PAM Control Flags
All PAM modules generate a success or failure result
when checked. Control flags tell PAM what do with the
result. Since modules can be stacked in a particular
order, control flags give you the ability to set the
importance of a module in respect to the modules that
follow it.
auth required /lib/security/pam_nologin.soauth required
/lib/security/pam_securetty.soauth required
/lib/security/pam_env.soauth sufficient
/lib/security/pam_rhosts_auth.soauth required
/lib/security/ service=system-authaccount required
/lib/security/ service=system-authpassword required
/lib/security/ service=system-authsession required
/lib/security/ service=system-auth
PAM Module Paths
Module paths tell PAM where to find the
pluggable module to be used with the module
type specified. Usually, it is provided as the full
path to the module, such as
However, if the full path is not given (in other
words, the path does not start with a /), then the
module indicated is assumed to be in
/lib/security, the default location for PAM
PAM Arguments
PAM uses arguments to pass information to a
pluggable module during authentication for a particular
module type. These arguments allow the PAM
configuration files for particular programs to use a
common PAM module but in different ways.
The module takes a db argument, specifying the
Berkeley DB filename to use, which can be different for
different services.
So, the line in a PAM configuration
file look like this:
auth required /lib/security/
PAM Configuration File Samples
A sample PAM application configuration file looks like

auth required /lib/security/
auth required /lib/security/ shadow
auth required /lib/security/
account required /lib/security/
password required /lib/security/
password required /lib/security/
shadow nullok use_authtok
session required /lib/security/
The first line is a comment (any line starting with
a # character is a comment). Lines two through four
stack three modules to use for login authentication.
auth required /lib/security/
Line two makes sure that if the user is trying to
log in as root, the tty on which they are logging in is
listed in the /etc/securetty file, if that file exists.

auth required /lib/security/ nullok

Line three causes the user to be asked for a
password and the password to be checked, using the
information store in /etc/passwd, and if it exists,
auth required /lib/security/
If any requisite module returns failure, PAM fails
immediately without calling any other modules.
1.account required /lib/security/
2.password required /lib/security/
3.password required /lib/security/
4.shadow nullok use_authtok
5.session required /lib/security/
6.auth required /lib/security/
7.auth required /lib/security/pam_env.soauth
9. auth required /lib/security/
Shadow Passwords
If you are using shadow passwords, will automatically detect that they are in
use and will use them to authenticate users
Using rlogin, rsh, and rexec with PAM
For security reasons, rexec, rsh, and rlogin are not
enabled by default in Red Hat Linux 7.2. You should use
the OpenSSH suite of tools instead.
If you must use rexec, rsh, and rlogin, and
if you need to use them as root, you will need to make a
few modifications to the /etc/securetty file. All three of
these tools have PAM configuration files that require the PAM module, so you must edit
/etc/securetty to allow root access.