1pam.conf(4) File Formats pam.conf(4)
2
6 pam.conf - configuration file for pluggable authentication modules
7
9 /etc/pam.conf
10
13 pam.conf is the configuration file for the Pluggable Authentication
14 Module architecture, or PAM. A PAM module provides functionality for
15 one or more of four possible services: authentication, account manage‐
16 ment, session management, and password management.
17 authentication service module
19 Provides functionality to authenticate a user and set up user cre‐
21 dentials.
22 account management module
25 Provides functionality to determine if the current user's account
27 is valid. This includes checking for password and account expira‐
28 tion, as well as verifying access hour restrictions.
29 session management module
32 Provides functionality to set up and terminate login sessions.
34 password management module
37 Provides functionality to change a user's authentication token or
39 password.
40 Each of the four service modules can be implemented as a shared library
44 object which can be referenced in the pam.conf configuration file.
45 Simplified pam.conf Configuration File
47 The pam.conf file contains a listing of services. Each service is
48 paired with a corresponding service module. When a service is
49 requested, its associated module is invoked. Each entry may be a maxi‐
50 mum of 256 characters, including the end of line, and has the following
51 format:
52 service_name module_type control_flag module_path options
54 The following is an example of a pam.conf configuration file with sup‐
59 port for authentication, account management, session management and
60 password management modules (See the pam.conf file that is shipped with
61 your system for the contents of this file):
62 login auth requisite pam_authtok_get.so.1
64 login auth required pam_dhkeys.so.1
65 login auth required pam_unix_auth.so.1
66 login auth required pam_dial_auth.so.1
67 other account requisite pam_roles.so.1
69 other account required pam_unix_account.so.1
70 other session required pam_unix_session.so.1
72 other password required pam_dhkeys.so.1
74 other password requisite pam_authtok_get.so.1
75 other password requisite pam_authtok_check.so.1
76 other password required pam_authtok_store.so.1
77 service_name denotes the service (for example, login, dtlogin, or
81 rlogin).
82 The keyword, "other," indicates the module that all other applications
85 which have not been specified should use. The "other" keyword can also
86 be used if all services of the same module_type have the same require‐
87 ments.
88 In the example, since all of the services use the same session module,
91 they could have been replaced by a single other line.
92 module_type denotes the service module type: authentication (auth),
95 account management (account), session management (session), or password
96 management (password).
97 The control_flag field determines the behavior of stacking.
100 The module_path field specifies the relative pathname to a shared
103 library object, or an included PAM configuration file, which implements
104 the service functionality. If the pathname is not absolute, shared
105 library objects are assumed to be relative to /usr/lib/security/$ISA/,
106 and included PAM configuration files are assumed to be relative to
107 /usr/lib/security/.
108 The ISA token is replaced by an implementation defined directory name
111 which defines the path relative to the calling program's instruction
112 set architecture.
113 The options field is used by the PAM framework layer to pass module
116 specific options to the modules. It is up to the module to parse and
117 interpret the options.
118 This field can be used by the modules to turn on debugging or to pass
121 any module specific parameters such as a TIMEOUT value. The options
122 supported by the modules are documented in their respective manual
123 pages.
124 Integrating Multiple Authentication Services With Stacking
126 When a service_name of the same module_type is defined more than once,
127 the service is said to be stacked. Each module referenced in the mod‐
128 ule_path for that service is then processed in the order that it occurs
129 in the configuration file. The control_flag field specifies the contin‐
130 uation and failure semantics of the modules, and can contain one of the
131 following values:
132 binding If the service module returns success and no preceding
134 required modules returned failures, immediately return
135 success without calling any subsequent modules. If a
136 failure is returned, treat the failure as a required mod‐
137 ule failure, and continue to process the PAM stack.
138 include Process the lines from the PAM configuration file that
141 is specified in the module_path at this point in the PAM
142 stack. The ``other'' keyword is used if the specified
143 service_name is not found. 32 levels of included PAM con‐
144 figuration files are supported. Any options are ignored.
145 optional If the service module returns success, record the suc‐
148 cess, and continue to process the PAM stack. If a failure
149 is returned, and it is the first optional module failure,
150 save the failure code as an optional failure. Continue to
151 process the PAM stack.
152 required If the service module returns success, record the suc‐
155 cess, and continue to process the PAM stack. If a failure
156 is returned, and it is the first required failure, save
157 the failure code as a required failure. Continue to
158 process the PAM stack.
159 requisite If the service module returns success, record the suc‐
162 cess, and continue to process the PAM stack. If a failure
163 is returned, immediately return the first non-optional
164 failure value recorded without calling any subsequent
165 modules. That is, return this failure unless a previous
166 required service module failed. If a previous required
167 service module failed, then return the first of those
168 values.
169 sufficient If the service module return success and no preceding
172 required modules returned failures, immediately return
173 success without calling any subsequent modules. If a
174 failure is returned, treat the failure as an optional
175 module failure, and continue to process the PAM stack.
176 If the PAM stack runs to completion, that is, neither a requisite mod‐
180 ule failed, nor a binding or sufficient module success stops it, suc‐
181 cess is returned if no required modules failed and at least one
182 required, requisite, optional module succeeded. If no module succeeded
183 and a required or binding module failed, the first of those errors is
184 returned. If no required or binding module failed and an optional mod‐
185 ule failed, the first of the option module errors is returned. If no
186 module in the stack succeeded or failed, that is, all modules returned
187 an ignore status, a default error based on module type, for example,
188 "User account expired," is returned.
189 All errors in pam.conf entries are logged to syslog as LOG_AUTH |
192 LOG_ERR errors. The use of a service with an error noted in the
193 pam.conf entry for that service will fail. The system administrator
194 will need to correct the noted errors before that service may be used.
195 If no services are available or the pam.conf file is missing, the sys‐
196 tem administrator may enter system maintenance mode to correct or
197 restore the file.
198 The following is a sample configuration file that stacks the su, login,
201 and rlogin services.
202 su auth required pam_inhouse.so.1
204 su auth requisite pam_authtok_get.so.1
205 su auth required pam_dhkeys.so.1
206 su auth required pam_unix_auth.so.1
207 login auth requisite pam_authtok_get.so.1
209 login auth required pam_dhkeys.so.1
210 login auth required pam_unix_auth.so.1
211 login auth required pam_dial_auth.so.1
212 login auth optional pam_inhouse.so.1
213 rlogin auth sufficient pam_rhosts_auth.so.1
215 rlogin auth requisite pam_authtok_get.so.1
216 rlogin auth required pam_dhkeys.so.1
217 rlogin auth required pam_unix_auth.so.1
218 In the case of su, the user is authenticated by the inhouse and auth‐
222 tok_get, dhkeys, and unix_auth authentication modules. Because the
223 inhouse and the other authentication modules are required and requi‐
224 site, respectively, an error is returned back to the application if any
225 module fails. In addition, if the requisite authentication (pam_auth‐
226 tok_get authentication) fails, the other authentication modules are
227 never invoked, and the error is returned immediately back to the appli‐
228 cation.
229 In the case of login, the required keyword for control_flag requires
232 that the user be allowed to login only if the user is authenticated by
233 all the service modules. If pam_unix_auth authentication fails, control
234 continues to proceed down the stack, and the inhouse authentication
235 module is invoked. inhouse authentication is optional by virtue of the
236 optional keyword in the control_flag field. The user can still log in
237 even if inhouse authentication fails, assuming the modules stacked
238 above succeeded.
239 In the case of rlogin, the sufficient keyword for control_flag speci‐
242 fies that if the rhosts authentication check succeeds, then PAM should
243 return success to rlogin and rlogin should not prompt the user for a
244 password. The other authentication modules, which are in the stack,
245 will only be invoked if the rhosts check fails. This gives the system
246 administrator the flexibility to determine if rhosts alone is suffi‐
247 cient enough to authenticate a remote user.
248 Some modules return PAM_IGNORE in certain situations. In these cases
251 the PAM framework ignores the entire entry in pam.conf regardless of
252 whether or not it is binding, requisite, required, optional, or suffi‐
253 cient.
254 Utilities and Files
256 The specific service names and module types for each service should be
257 documented in the man page for that service. For instance, the sshd(1M)
258 man page lists all of the PAM service names and module types for the
259 sshd command.
260 The PAM configuration file does not dictate either the name or the
263 location of the service specific modules. The convention, however, is
264 the following:
265 pam_module_name.so.x File that implements various function of
267 specific authentication services. As the
268 relative pathname specified,
269 /usr/lib/security/$ISA is prepended to it.
270 /etc/pam.conf Configuration file
273 /usr/lib/$ISA/libpam.so.1 File that implements the PAM framework
276 library
277
280 Example 1 Using the include control flag
281 The following example collects the common Unix modules into a single
284 file to be included as needed in the example of a pam.conf file. The
285 common Unix module file is named unix_common and consists of:
286 OTHER auth requisite pam_authtok_get.so.1
289 OTHER auth required pam_dhkeys.so.1
290 OTHER auth required pam_unix_auth.so.1
291 OTHER auth required pam_unix_cred.so.1
292 OTHER account requisite pam_roles.so.1
293 OTHER account required pam_unix_account.so.1
294 OTHER session required pam_unix_session.so.1
295 OTHER password required pam_dhkeys.so.1
296 OTHER password requisite pam_authtok_get.so.1
297 OTHER password requisite pam_authtok_check.so.1
298 OTHER password required pam_authtok_store.so.1
299 The pam.conf file and consists of:
304 # Authentication management
307 #
308 # login service (explicit because of pam_dial_auth)
309 #
310 login auth include unix_common
311 login auth required pam_dial_auth.so.1
312 #
313 # rlogin service (explicit because of pam_rhost_auth)
314 #
315 rlogin auth sufficient pam_rhosts_auth.so.1
316 rlogin auth include unix_common
317 #
318 # Default definitions for Authentication management
319 # Used when service name is not explicitly mentioned
320 #
321 OTHER auth include unix_common
322 #
323 # Default definition for Account management
324 # Used when service name is not explicitly mentioned
325 #
326 OTHER account include unix_common
327 #
328 # Default definition for Session management
329 # Used when service name is not explicitly mentioned
330 #
331 OTHER session include unix_common
332 #
333 # Default definition for Password management
334 # Used when service name is not explicitly mentioned
335 #
336 OTHER password include unix_common
337
341 See attributes(5) for descriptions of the following attributes:
342 ┌─────────────────────────────┬─────────────────────────────┐
347 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
348 ├─────────────────────────────┼─────────────────────────────┤
349 │Interface Stability │See Below. │
350 └─────────────────────────────┴─────────────────────────────┘
351 The format is Stable. The contents has no stability attributes.
354
356 login(1), passwd(1), in.ftpd(1M), in.rlogind(1M), in.rshd(1M), in.tel‐
357 netd(1M), in.uucpd(1M), init(1M), rpc.rexd(1M), sac(1M), ttymon(1M),
358 su(1M), pam(3PAM), syslog(3C), libpam(3LIB), attributes(5), environ(5),
359 pam_authtok_check(5), pam_authtok_get(5), pam_authtok_store(5),
360 pam_dhkeys(5), pam_krb5(5), pam_passwd_auth(5), pam_unix_account(5),
361 pam_unix_auth(5), pam_unix_session(5)
362
364 The pam_unix module is no longer supported. Similar functionality is
365 provided by pam_authtok_check(5), pam_authtok_get(5), pam_auth‐
366 tok_store(5), pam_dhkeys(5), pam_passwd_auth(5), pam_unix_account(5),
367 pam_unix_auth(5), and pam_unix_session(5).
368 With the removal of the pam_unix module, the SunOS delivered PAM ser‐
371 vice modules no longer need or support the "use_first_pass" or
372 "try_first_pass" options. This functionality is provided by stacking
373 pam_authtok_get(5) above a module that requires a password.
374SunOS 5.11 19 June 2006 pam.conf(4)