Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
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  re-
       quested,	its associated module is invoked. Each entry 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  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  re-
       quirements.

       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), ac-
       count  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  li-
       brary  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-op-
		       tional failure value recorded without calling any  sub-
		       sequent	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  re-
       quired,	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  re-
       store 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 in-
       house and the other authentication modules are required and  requisite,
       respectively,  an error is returned back	to the application if any mod-
       ule 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  lo-
       cation 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 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)

NAME | SYNOPSIS | DESCRIPTION | ATTRIBUTES | SEE ALSO | NOTES

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=pam.conf&sektion=4&manpath=SunOS+5.10>

home | help