unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Page:
Section:
Apropos / Subsearch:
optional field

pam.conf(4)                      File Formats                      pam.conf(4)



NAME
       pam.conf - configuration file for pluggable authentication modules

SYNOPSIS
       /etc/pam.conf

DESCRIPTION
       pam.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 credentials.



       account management module       Provides  functionality to determine if
                                       the current user's  account  is  valid.
                                       This includes checking for password and
                                       account expiration, as well as  verify-
                                       ing 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 pass-
                                       word.



       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 has the follow-
       ing 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  all  other  applica-
       tions  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
       requirements.

       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
                       module 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 fail-
                       ure  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 fail-
                       ure  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 fail-
                       ure  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  previ-
                       ous  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_CRIT 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:


       tab()     allbox;     cw(2.750000i)|    cw(2.750000i)    lw(2.750000i)|
       lw(2.750000i).  ATTRIBUTE TYPEATTRIBUTE  VALUE  Interface  StabilitySee
       Below.


       The format is Stable. The contents has no stability attributes.

SEE ALSO
       login(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)

NOTES
       The pam_unix module is no longer supported.  Similar  functionality  is
       provided   by   pam_authtok_check(5),   pam_authtok_get(5),   pam_auth-
       tok_store(5), pam_dhkeys(5),  pam_passwd_auth(5),  pam_unix_account(5),
       pam_unix_auth(5), and pam_unix_session(5).

       With  the  removal of the pam_unix module, the SunOS delivered PAM ser-
       vice  modules  no  longer  need  or  support  the  "use_first_pass"  or
       "try_first_pass"  options.  This  functionality is provided by stacking
       pam_authtok_get(5) above a module that requires a password.



SunOS 5.10                       21 July 2004                      pam.conf(4)