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 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  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 the  pam.conf  configuration  file  with
       support	for authentication, account management,	and session management
       modules.

       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   session required	  pam_unix_session.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  mod-
       ule_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), 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. It can also  be
       used to support unified login. 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 be requisite,  re-
       quired, optional, or sufficient.

       The  PAM	 framework  processes each service module in the stack.	If all
       requisite and required modules in the stack succeed,  then  success  is
       returned,  and optional and sufficient error values are ignored.	If one
       or more requisite or required modules fail, then	the error  value  from
       the first requisite or required module that failed is returned.

       If none of the service modules in the stack are designated as requisite
       or required, then the PAM framework requires that at least one optional
       or sufficient module succeed.

       If  all	fail then the error value from the first service module	in the
       stack is	returned.

       The requisite and sufficient flags cause	two exceptions	to  the	 above
       semantics.  If  a service module	that is	designated as requisite	fails,
       then the	PAM framework immediately returns an error to the application,
       and all subsequent service modules in the stack are ignored. If a prior
       required	service	module has failed, then	that error is returned.	If  no
       prior  required	service	 module	failed,	then the error from the	failed
       requisite service module	is returned.

       If a service module that	is designated as sufficient succeeds, then the
       PAM  framework  immediately returns success to the application, and all
       subsequent services modules in the stack, even requisite	 and  required
       ones,  are ignored, given that all prior	requisite and required modules
       have also succeeded. If a prior required	module has  failed,  then  the
       error value from	that module is returned.

       If any entry in 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  per-
       mitted  access  to the system. An error is logged through syslog(3C) at
       the LOG_CRIT level. To fix incorrect entries in pam.conf, a system  ad-
       ministrator  can	 boot  the system in maintenance mode (single user) to
       edit the	file.

       The following is	a sample configuration file that stacks	the su,	login,
       and rlogin services.

       su     auth requisite	  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 inhouseand auth-
       tok_get,	dhkesys	and unix_auth authentication modules. Because the  in-
       house  and the other authentication modules are requisite and required,
       respectively, an	error is returned back to the application if any  mod-
       ule  fails.  In	addition, if the requisite authentication (inhouse au-
       thentication) fails, the	other authentication modules is	never invoked,
       and the error is	returned immediately back to the application.

       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 authtok_get 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 requisite, required, optional or sufficient.

   Utilities and Files
       The following is	a list of the utilities	that use PAM:  login,  passwd,
       su,  rlogind,  rshd,  telnetd,  ftpd, rpc.rexd, uucpd, init, sac, cron,
       ppp, dtsession, ssh and ttymon.

       The utility dtlogin also	uses PAM. dtlogin is the login service utility
       for the Common Desktop Environment (CDE).

       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/secu-
	     rity/$ISA is prepended to it.

       /etc/pam.conf
	     Configuration file.

       /usr/lib/$ISA/libpam.so.1
	     File that implements the PAM framework library.

EXAMPLES
       Example 1: A Sample pam.conf Configuration File

	The following is a sample pam.conf configuration file.

       Lines  that begin with the # symbol are treated as comments, and	there-
       fore ignored.

       # PAM configuration
       #
       # Unless	explicitly defined, all	services use the modules
       # defined in the	"other"	section.
       #
       # Modules are defined with relative pathnames, i.e., they are
       # relative to /usr/lib/security/$ISA. Absolute path names, as
       # present in this file in previous releases are still acceptable.
       #
       # Authentication	management
       #
       # login service (explicit because of pam_dial_auth)
       #
       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
       #
       # rlogin	service	(explicit because of pam_rhost_auth)
       #
       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
       #
       # rsh service (explicit because of pam_rhost_auth)
       # and pam_unix_auth for meaningful pam_setcred)
       #
       rsh     auth sufficient	       pam_rhosts_auth.so.1
       rsh     auth required	       pam_authtok_get.so.1
       #
       # ppp service (explicit because of pam_dial_auth)
       #
       ppp     auth requisite	       pam_authtok_get.so.1
       ppp     auth required	       pam_dhkeys.so.1
       ppp     auth required	       pam_unix_auth.so.1
       ppp     auth required	       pam_dial_auth.so.1
       #
       # Default definitions for Authentication	management
       # Used when service name	is not explicitly mentioned for	authenctication
       #
       other   auth requisite		pam_authtok_get.so.1
       other   auth required	       pam_dhkeys.so.1
       other   auth required	       pam_unix_auth.so.1
       #
       # passwd	command	(explicit because of a different authentication	module)
       #
       passwd  auth required	       pam_passwd_auth.so.1
       #
       # cron service (explicit	because	of non-usage of	pam_roles.so.1)
       #
       cron    account required	       pam_projects.so.1
       cron    account required	       pam_unix_account.so.1
       #
       # Default definition for	Account	management
       # Used when service name	is not explicitly mentioned for	account	management
       #
       other   account requisite       pam_roles.so.1
       other   account required	       pam_projects.so.1
       other   account required	       pam_unix_account.so.1
       #
       # Default definition for	Session	management
       # Used when service name	is not explicitly mentioned for	session	management
       #
       other   session required	       pam_unix_session.so.1
       #
       # Default definition for	 Password management
       # Used when service name	is not explicitly mentioned for	password management
       #
       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
       #
       # Support for Kerberos V5 authentication	(uncomment to use Kerberos)
       #
       #rlogin auth optional	       pam_krb5.so.1 try_first_pass
       #login  auth optional	       pam_krb5.so.1 try_first_pass
       #other  auth optional	       pam_krb5.so.1 try_first_pass
       #cron   account optional	       pam_krb5.so.1
       #other  account optional	       pam_krb5.so.1
       #other  session optional	       pam_krb5.so.1
       #other  password	optional       pam_krb5.so.1 try_first_pass

ATTRIBUTES
       See attributes(5) for descriptions of the following attributes:

       +-----------------------------+-----------------------------+
       |      ATTRIBUTE	TYPE	     |	    ATTRIBUTE VALUE	   |
       +-----------------------------+-----------------------------+
       |MT Level		     |MT-Safe with exceptions	   |
       +-----------------------------+-----------------------------+

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_passwd_auth(5),  pam_unix(5),  pam_unix_account(5),
       pam_unix_auth(5), pam_unix_session(5)

NOTES
       The pam_unix(5) module might not	be supported in	a future release. Sim-
       ilar  functionality  is	provided  by  pam_authtok_check(5),  pam_auth-
       tok_get(5),  pam_authtok_store(5),  pam_dhkeys(5),  pam_passwd_auth(5),
       pam_unix_account(5), pam_unix_auth(5), and pam_unix_session(5).

SunOS 5.9			  24 Jan 2002			   pam.conf(4)

NAME | SYNOPSIS | DESCRIPTION | EXAMPLES | 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.9>

home | help