Updated: 2022/Sep/29

Please read Privacy Policy. It's for your privacy.

PAM.CONF(5)                   File Formats Manual                  PAM.CONF(5)

NAME
     pam.conf - PAM policy file format

DESCRIPTION
     The PAM library searches for policies in the following files, in
     decreasing order of preference:

     1.   /etc/pam.d/service-name

     2.   /etc/pam.conf

     If none of these locations contains a policy for the given service, the
     "other" policy is used instead, if it exists.

     Entries in per-service policy files must be of one of the two forms
     below:

           facility control-flag module-path [arguments ...]
           facility include other-service-name

     Entries in pam.conf-style policy files are of the same form, but are
     prefixed by an additional field specifying the name of the service they
     apply to.

     In both cases, blank lines and comments introduced by a `#' sign are
     ignored, and the normal shell quoting rules apply.  The precise details
     of how the file is tokenized are described in openpam_readword(3).

     The facility field specifies the facility the entry applies to, and is
     one of:

     auth          Authentication functions (pam_authenticate(3),
                   pam_setcred(3))

     account       Account management functions (pam_acct_mgmt(3))

     session       Session handling functions (pam_open_session(3),
                   pam_close_session(3))

     password      Password management functions (pam_chauthtok(3))

     The control-flag field determines how the result returned by the module
     affects the flow of control through (and the final result of) the rest of
     the chain, and is one of:

     required      If this module succeeds, the result of the chain will be
                   success unless a later module fails.  If it fails, the rest
                   of the chain still runs, but the final result will be
                   failure regardless of the success of later modules.

     requisite     If this module succeeds, the result of the chain will be
                   success unless a later module fails.  If the module fails,
                   the chain is broken and the result is failure.

     sufficient    If this module succeeds, the chain is broken and the result
                   is success.  If it fails, the rest of the chain still runs,
                   but the final result will be failure unless a later module
                   succeeds.

     binding       If this module succeeds, the chain is broken and the result
                   is success.  If it fails, the rest of the chain still runs,
                   but the final result will be failure regardless of the
                   success of later modules.

     optional      If this module succeeds, the result of the chain will be
                   success unless a later module fails.  If this module fails,
                   the result of the chain will be failure unless a later
                   module succeeds.

     There are two exceptions to the above: sufficient and binding modules are
     treated as optional by pam_setcred(3), and in the PAM_PRELIM_CHECK phase
     of pam_chauthtok(3).

     The module-path field specifies the name or full path of the module to
     call.  If only the name is specified, the PAM library will search for it
     in the following location:

     1.   /usr/lib/security

     The remaining fields, if any, are passed unmodified to the module if and
     when it is invoked.

     The include form of entry causes entries from a different chain
     (specified by other-system-name) to be included in the current one.  This
     allows one to define system-wide policies which are then included into
     service-specific policies.  The system-wide policy can then be modified
     without having to also modify each and every service-specific policy.

     Take care not to introduce loops when using include rules, as there is
     currently no loop detection in place.

MODULE OPTIONS
     Some PAM library functions may alter their behavior when called by a
     service module if certain module options were specified, regardless of
     whether the module itself accords them any importance.  One such option
     is debug, which causes the dispatcher to enable debugging messages before
     calling each service function, and disable them afterwards (unless they
     were already enabled).  Other special options include:

     authtok_prompt=prompt, oldauthtok_prompt=prompt, user_prompt=prompt
                   These options can be used to override the prompts used by
                   pam_get_authtok(3) and pam_get_user(3).

     echo_pass     This option controls whether pam_get_authtok(3) will allow
                   the user to see what they are typing.

     try_first_pass, use_first_pass
                   These options control pam_get_authtok(3)'s use of cached
                   authentication tokens.

SEE ALSO
     pam(3)

STANDARDS
     X/Open Single Sign-On Service (XSSO) - Pluggable Authentication Modules,
     June 1997.

AUTHORS
     The OpenPAM library was developed for the FreeBSD Project by ThinkSec AS
     and Network Associates Laboratories, the Security Research Division of
     Network Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035
     ("CBOSS"), as part of the DARPA CHATS research program.

     The OpenPAM library is maintained by Dag-Erling Sm/orgrav <des@des.no>.

NetBSD 10.99                     June 27, 2023                    NetBSD 10.99