pam.conf.4 (2010 09)

p
pam.conf(4) pam.conf(4)
compatibility to PA-RISC library naming convention, appropriate links are provided in
/usr/lib/security/
and /usr/lib/security/pa20_64
Example:
/usr/lib/security/libpam_unix.so.1 -> ./libpam_unix.1
If a user-
defined module is specified in
/etc/pam.conf or /etc/pam_user.conf
, the above
convention must be followed to create symbolic links pointing to PA-RISC modules. To
help reduce the impact of any future
/etc/pam.conf file format changes, the only sup-
ported way of parsing
/etc/pam.conf
is through the PAM library interfaces. These
interfaces will transparently do any necessary expansion of reserved tokens, such as
$ISA.
options 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. It can also be used to support unified login. The options supported
by the modules are documented in their respective manual pages. For example,
pam_unix (5) lists the options accepted by the UNIX module.
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 module_path for that service is then processed in the order that
it occurs in the configuration file. The control_flag field specifies the continuation and failure semantics
of the modules, and may contain one of the following values:
optional If the service module returns success, record the success 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 success 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 success 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. In other words, record this failure,
unless a previous required service module failed. If a previous required service module
failed, return the first of those values.
sufficient 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 an optional module failure, and continue to process the
PAM stack.
If no
requisite module fails and no sufficient module succeeds, the PAM stack runs to comple-
tion. In this case success is returned, providing no required module failed and at least one
required, requisite,oroptional module succeeded. If no module succeeded and a required
module failed, the first of those errors is returned.
If all modules return
PAM_IGNORE, a default error based on module type is returned.
If any entry in
/etc/pam.conf is incorrect, or if a module does not exist or cannot be opened, then all
PAM services fail and users are not be permitted access to the system. An error will be logged through
syslog (3C) at the LOG_CRIT level, and the PAM framework returns PAM_OPEN_ERR error to the appli-
cation.
Below is a sample configuration file that stacks the
login, and dtlogin services.
login auth required libpam_hpsec.so.1 debug
login auth required libpam_unix.so.1 debug
login auth optional libpam_inhouse.so.1
dtlogin auth required libpam_hpsec.so.1 debug
dtlogin auth sufficient libpam_unix.so.1 debug
dtlogin auth required libpam_inhouse.so.1
In the case of
login, the user is authenticated by the hpsec, the UNIX, and inhouse authentication
modules. The required keyword for control_flag requires that the user be allowed to login only if the
user is authenticated by the hpsec and the UNIX service modules. The 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, as long as hpsec and UNIX both successfully authenticate the user.
2 Hewlett-Packard Company − 2 − HP-UX 11i Version 3: September 2010