pam.conf(4) File Formats pam.conf(4)NAMEpam.conf - configuration file for pluggable authentication modules
SYNOPSIS
/etc/pam.conf
DESCRIPTIONpam.conf is the configuration file for the Pluggable Authentication
Module architecture, or PAM. A PAM module provides functionality for
one or more of four possible services: authentication, account manage‐
ment, session management, and password management.
authentication service module
Provides functionality to authenticate a user and set up user cre‐
dentials.
account management module
Provides functionality to determine if the current user's account
is valid. This includes checking for password and account expira‐
tion, as well as verifying access hour restrictions.
session management module
Provides functionality to set up and terminate login sessions.
password management module
Provides functionality to change a user's authentication token or
password.
Each of the four service modules can be implemented as a shared library
object which can be referenced in the pam.conf configuration file.
Simplified pam.conf Configuration File
The pam.conf file contains a listing of services. Each service is
paired with a corresponding service module. When a service is
requested, its associated module is invoked. Each entry may be a maxi‐
mum of 256 characters, including the end of line, and has the following
format:
service_name module_type control_flag module_path options
The following is an example of a pam.conf configuration file with sup‐
port for authentication, account management, session management and
password management modules (See the pam.conf file that is shipped with
your system for the contents of this file):
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
other account requisite pam_roles.so.1
other account required pam_unix_account.so.1
other session required pam_unix_session.so.1
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1
service_name denotes the service (for example, login, dtlogin, or
rlogin).
The keyword, "other," indicates the module that all other applications
which have not been specified should use. The "other" keyword can also
be used if all services of the same module_type have the same require‐
ments.
In the example, since all of the services use the same session module,
they could have been replaced by a single other line.
module_type denotes the service module type: authentication (auth),
account management (account), session management (session), or password
management (password).
The control_flag field determines the behavior of stacking.
The module_path field specifies the relative pathname to a shared
library object which implements the service functionality. If the path‐
name is not absolute, it is assumed to be relative to /usr/lib/secu‐
rity/$ISA/.
The ISA token is replaced by an implementation defined directory name
which defines the path relative to the calling program's instruction
set architecture.
The options field is used by the PAM framework layer to pass module
specific options to the modules. It is up to the module to parse and
interpret the options.
This field can be used by the modules to turn on debugging or to pass
any module specific parameters such as a TIMEOUT value. The options
supported by the modules are documented in their respective manual
pages.
Integrating Multiple Authentication Services With Stacking
When a service_name of the same module_type is defined more than once,
the service is said to be stacked. Each module referenced in the mod‐
ule_path for that service is then processed in the order that it occurs
in the configuration file. The control_flag field specifies the contin‐
uation and failure semantics of the modules, and can contain one of the
following values:
binding If the service module returns success and no preceding
required modules returned failures, immediately return
success without calling any subsequent modules. If a
failure is returned, treat the failure as a required mod‐
ule failure, and continue to process the PAM stack.
optional If the service module returns success, record the suc‐
cess, and continue to process the PAM stack. If a failure
is returned, and it is the first optional module failure,
save the failure code as an optional failure. Continue to
process the PAM stack.
required If the service module returns success, record the suc‐
cess, and continue to process the PAM stack. If a failure
is returned, and it is the first required failure, save
the failure code as a required failure. Continue to
process the PAM stack.
requisite If the service module returns success, record the suc‐
cess, and continue to process the PAM stack. If a failure
is returned, immediately return the first non-optional
failure value recorded without calling any subsequent
modules. That is, return this failure unless a previous
required service module failed. If a previous required
service module failed, then return the first of those
values.
sufficient If the service module return success and no preceding
required modules returned failures, immediately return
success without calling any subsequent modules. If a
failure is returned, treat the failure as an optional
module failure, and continue to process the PAM stack.
If the PAM stack runs to completion, that is, neither a requisite mod‐
ule failed, nor a binding or sufficient module success stops it, suc‐
cess is returned if no required modules failed and at least one
required, requisite, optional module succeeded. If no module succeeded
and a required or binding module failed, the first of those errors is
returned. If no required or binding module failed and an optional mod‐
ule failed, the first of the option module errors is returned. If no
module in the stack succeeded or failed, that is, all modules returned
an ignore status, a default error based on module type, for example,
"User account expired," is returned.
All errors in pam.conf entries are logged to syslog as LOG_AUTH |
LOG_ERR errors. The use of a service with an error noted in the
pam.conf entry for that service will fail. The system administrator
will need to correct the noted errors before that service may be used.
If no services are available or the pam.conf file is missing, the sys‐
tem administrator may enter system maintenance mode to correct or
restore the file.
The following is a sample configuration file that stacks the su, login,
and rlogin services.
su auth required pam_inhouse.so.1
su auth requisite pam_authtok_get.so.1
su auth required pam_dhkeys.so.1
su auth required pam_unix_auth.so.1
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
login auth optional pam_inhouse.so.1
rlogin auth sufficient pam_rhosts_auth.so.1
rlogin auth requisite pam_authtok_get.so.1
rlogin auth required pam_dhkeys.so.1
rlogin auth required pam_unix_auth.so.1
In the case of su, the user is authenticated by the inhouse and auth‐
tok_get, dhkeys, and unix_auth authentication modules. Because the
inhouse and the other authentication modules are required and requi‐
site, respectively, an error is returned back to the application if any
module fails. In addition, if the requisite authentication (pam_auth‐
tok_get authentication) fails, the other authentication modules are
never invoked, and the error is returned immediately back to the appli‐
cation.
In the case of login, the required keyword for control_flag requires
that the user be allowed to login only if the user is authenticated by
all the service modules. If pam_unix_auth authentication fails, control
continues to proceed down the stack, and the inhouse authentication
module is invoked. inhouse authentication is optional by virtue of the
optional keyword in the control_flag field. The user can still log in
even if inhouse authentication fails, assuming the modules stacked
above succeeded.
In the case of rlogin, the sufficient keyword for control_flag speci‐
fies that if the rhosts authentication check succeeds, then PAM should
return success to rlogin and rlogin should not prompt the user for a
password. The other authentication modules, which are in the stack,
will only be invoked if the rhosts check fails. This gives the system
administrator the flexibility to determine if rhosts alone is suffi‐
cient enough to authenticate a remote user.
Some modules return PAM_IGNORE in certain situations. In these cases
the PAM framework ignores the entire entry in pam.conf regardless of
whether or not it is binding, requisite, required, optional, or suffi‐
cient.
Utilities and Files
The specific service names and module types for each service should be
documented in the man page for that service. For instance, the sshd(1M)
man page lists all of the PAM service names and module types for the
sshd command.
The PAM configuration file does not dictate either the name or the
location of the service specific modules. The convention, however, is
the following:
pam_module_name.so.x File that implements various function of
specific authentication services. As the
relative pathname specified,
/usr/lib/security/$ISA is prepended to it.
/etc/pam.conf Configuration file
/usr/lib/$ISA/libpam.so.1 File that implements the PAM framework
library
ATTRIBUTES
See attributes(5) for descriptions of the following attributes:
┌─────────────────────────────┬─────────────────────────────┐
│ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
├─────────────────────────────┼─────────────────────────────┤
│Interface Stability │See Below. │
└─────────────────────────────┴─────────────────────────────┘
The format is Stable. The contents has no stability attributes.
SEE ALSOlogin(1), passwd(1), in.ftpd(1M), in.rlogind(1M), in.rshd(1M), in.tel‐
netd(1M), in.uucpd(1M), init(1M), rpc.rexd(1M), sac(1M), ttymon(1M),
su(1M), pam(3PAM), syslog(3C), libpam(3LIB), attributes(5), environ(5),
pam_authtok_check(5), pam_authtok_get(5), pam_authtok_store(5),
pam_dhkeys(5), pam_krb5(5), pam_passwd_auth(5), pam_unix_account(5),
pam_unix_auth(5), pam_unix_session(5)SunOS 5.10 1 Mar 2012 pam.conf(4)
