Chapter 25. PAM based Distributed Authentication

This chapter you should help you to deploy winbind based authentication on any PAM enabled Unix/Linux system. Winbind can be used to enable user level application access authentication from any MS Windows NT Domain, MS Windows 200x Active Directory based domain, or any Samba based domain environment. It will also help you to configure PAM based local host access controls that are appropriate to your Samba configuration.

-In addition to knowing how to configure winbind into PAM, you will learn generic PAM managment -possibilities and in particular how to deploy tools like pam_smbpass.so to your adavantage. +In addition to knowing how to configure winbind into PAM, you will learn generic PAM management +possibilities and in particular how to deploy tools like pam_smbpass.so to your advantage.

Note

The use of Winbind require more than PAM configuration alone. Please refer to the Winbind chapter. -

Features and Benefits

A number of Unix systems (eg: Sun Solaris), as well as the xxxxBSD family and Linux, now utilize the Pluggable Authentication Modules (PAM) facility to provide all authentication, authorization and resource control services. Prior to the introduction of PAM, a decision @@ -68,12 +67,12 @@ of distributed samba domain controllers that can provide wide are network bandwi efficient authentication services for PAM capable systems. In effect, this allows the deployment of centrally managed and maintained distributed authentication from a single user account database. -

Technical Discussion

PAM is designed to provide the system administrator with a great deal of flexibility in configuration of the privilege granting applications of their system. The local configuration of system security controlled by PAM is contained in one of two places: either the single system file, /etc/pam.conf; or the /etc/pam.d/ directory. -

PAM Configuration Syntax

In this section we discuss the correct syntax of and generic options respected by entries to these files. PAM specific tokens in the configuration file are case insensitive. The module paths, however, are case sensitive since they indicate a file's name and reflect the case dependence of typical file-systems. @@ -87,22 +86,22 @@ If the PAM authentication module (loadable link library file) is located in the default location then it is not necessary to specify the path. In the case of Linux, the default location is /lib/security. If the module is located outside the default then the path must be specified as: -

 auth  required  /other_path/pam_strange_module.so
-

Anatomy of `/etc/pam.d` Entries

The remaining information in this subsection was taken from the documentation of the Linux-PAM project. For more information on PAM, see http://ftp.kernel.org/pub/linux/libs/pam The Official Linux-PAM home page.

A general configuration line of the /etc/pam.conf file has the following form: -

 service-name   module-type   control-flag   module-path   args
-

Below, we explain the meaning of each of these tokens. The second (and more recently adopted) way of configuring Linux-PAM is via the contents of the /etc/pam.d/ directory. Once we have explained the meaning of the above tokens, we will describe this method. @@ -128,8 +127,8 @@ Once we have explained the meaning of the above tokens, we will describe this me user `root' login only on the console.

session: primarily, this module is associated with doing things that need - to be done for the user before/after they can be given service. Such things include the loggin - of information concerning the opening/closing of some data exchange with a user, mountin + to be done for the user before/after they can be given service. Such things include the logging + of information concerning the opening/closing of some data exchange with a user, mounting directories, etc.

password: this last module type is required for updating the authentication @@ -177,19 +176,19 @@ Once we have explained the meaning of the above tokens, we will describe this me this latter case, is when the other modules return something like PAM_IGNORE.

The more elaborate (newer) syntax is much more specific and gives the administrator a great deal of control - over how the user is authenticated. This form of the control flag is delimeted with square brackets and + over how the user is authenticated. This form of the control flag is delimited with square brackets and consists of a series of value=action tokens:

 		[value1=action1 value2=action2 ...]

- Here, valueI is one of the following return values: success; open_err; symbol_err; service_err; + Here, value1 is one of the following return values: success; open_err; symbol_err; service_err; system_err; buf_err; perm_denied; auth_err; cred_insufficient; authinfo_unavail; user_unknown; maxtries; new_authtok_reqd; acct_expired; session_err; cred_unavail; cred_expired; cred_err; no_module_data; conv_err; authtok_err; authtok_recover_err; authtok_lock_busy; authtok_disable_aging; try_again; ignore; abort; authtok_expired; module_unknown; bad_item; and default. The last of these (default) can be used to set the action for those return values that are not explicitly defined.

- The actionI can be a positive integer or one of the following tokens: ignore; ok; done; bad; die; and reset. + The action1 can be a positive integer or one of the following tokens: ignore; ok; done; bad; die; and reset. A positive integer, J, when specified as the action, can be used to indicate that the next J modules of the current module-type will be skipped. In this way, the administrator can develop a moderately sophisticated stack of modules with a number of different paths of execution. Which path is taken can be determined by the @@ -219,8 +218,8 @@ Once we have explained the meaning of the above tokens, we will describe this me

Each of the four keywords: required; requisite; sufficient; and optional, have an equivalent expression in terms of the [...] syntax. They are as follows: -

+
+
- required is equivalent to [success=ok new_authtok_reqd=ok ignore=ignore default=bad]
- requisite is equivalent to [success=ok new_authtok_reqd=ok ignore=ignore default=die] @@ -228,8 +227,8 @@ Once we have explained the meaning of the above tokens, we will describe this me sufficient is equivalent to [success=done new_authtok_reqd=done default=ignore]
- optional is equivalent to [success=ok new_authtok_reqd=ok default=ignore] -
-
+

Just to get a feel for the power of this new syntax, here is a taste of what you can do with it. With Linux-PAM-0.63, the notion of client plug-in agents was introduced. This is something that makes it possible for PAM to support machine-machine authentication using the transport protocol inherent to the client/server application. With the @@ -261,13 +260,13 @@ squid auth required pam_mysql.so user=passwd_query passwd=mada \ Any line in (one of) the configuration file(s), that is not formatted correctly, will generally tend (erring on the side of caution) to make the authentication process fail. A corresponding error is written to the system log files with a call to syslog(3). -

Example System Configurations

The following is an example /etc/pam.d/login configuration file. This example had all options been uncommented is probably not usable as it stacks many conditions before allowing successful completion of the login process. Essentially all conditions can be disabled by commenting them out except the calls to pam_pwdb.so. -

PAM: original login config

+
PAM: original login config
 #%PAM-1.0
 # The PAM configuration file for the `login' service
 #
@@ -282,10 +281,10 @@ session      required    pam_pwdb.so
 # session    optional    pam_lastlog.so
 # password   required    pam_cracklib.so retry=3
 password     required    pam_pwdb.so shadow md5
-
PAM: login using pam_smbpass

-PAM allows use of replacable modules. Those available on a sample system include:
-
$/bin/ls /lib/security
-+
PAM: login using pam_smbpass

+PAM allows use of replaceable modules. Those available on a sample system include:
+
$/bin/ls /lib/security
+
 pam_access.so    pam_ftp.so          pam_limits.so     
 pam_ncp_auth.so  pam_rhosts_auth.so  pam_stress.so     
 pam_cracklib.so  pam_group.so        pam_listfile.so   
@@ -354,14 +353,14 @@ password   required     pam_smbpass.so nodelay smbconf=/etc/samba.d/smb.conf
 also possible to pass information obtained within one PAM module through 
 to the next module in the PAM stack. Please refer to the documentation for 
 your particular system implementation for details regarding the specific 
-capabilities of PAM in this environment. Some Linux implmentations also 
+capabilities of PAM in this environment. Some Linux implementations also 
 provide the pam_stack.so module that allows all 
 authentication to be configured in a single central file. The 
 pam_stack.so method has some very devoted followers 
 on the basis that it allows for easier administration. As with all issues in 
 life though, every decision makes trade-offs, so you may want examine the 
 PAM documentation for further helpful information.
-

Password Synchronization using pam_smbpass.so

pam_smbpass is a PAM module which can be used on conforming systems to keep the smbpasswd (Samba password) database in sync with the unix password file. PAM (Pluggable Authentication Modules) is an API supported @@ -413,21 +412,21 @@ This module authenticates a local smbpasswd user database. If you require support for authenticating against a remote SMB server, or if you're concerned about the presence of suid root binaries on your system, it is recommended that you use pam_winbind instead. -

Options recognized by this module are as follows: -

Table 25.1. Options recognized by pam_smbpass

debug	log more debugging info
audit	like debug, but also logs unknown usernames
use_first_pass	don't prompt the user for passwords; take them from PAM_ items instead
try_first_pass	try to get the password from a previous PAM module, fall back to prompting the user
use_authtok	like try_first_pass, but fail if the new PAM_AUTHTOK has not been previously set. (intended for stacking password modules only)
not_set_pass	don't make passwords used by this module available to other modules.
nodelay	don't insert ~1 second delays on authentication failure.
nullok	null passwords are allowed.
nonull	null passwords are not allowed. Used to override the Samba configuration.
migrate	only meaningful in an "auth" context; used to update smbpasswd file with a password used for successful authentication.
smbconf=`file`	specify an alternate path to the `smb.conf` file.

- +

Table 25.1. Options recognized by pam_smbpass

debug	log more debugging info
audit	like debug, but also logs unknown usernames
use_first_pass	don't prompt the user for passwords; take them from PAM_ items instead
try_first_pass	try to get the password from a previous PAM module, fall back to prompting the user
use_authtok	like try_first_pass, but fail if the new PAM_AUTHTOK has not been previously set. (intended for stacking password modules only)
not_set_pass	don't make passwords used by this module available to other modules.
nodelay	don't insert ~1 second delays on authentication failure.
nullok	null passwords are allowed.
nonull	null passwords are not allowed. Used to override the Samba configuration.
migrate	only meaningful in an "auth" context; used to update smbpasswd file with a password used for successful authentication.
smbconf=`file`	specify an alternate path to the `smb.conf` file.

Thanks go to the following people: -
Andrew Morgan, for providing the Linux-PAM +
Andrew Morgan, for providing the Linux-PAM framework, without which none of this would have happened
Christian Gafton and Andrew Morgan again, for the pam_pwdb module upon which pam_smbpass was originally based
Luke Leighton for being receptive to the idea, and for the occasional good-natured complaint about the project's status - that keep me working on it :)
. -
+ that keep me working on it :)

. +

The following are examples of the use of pam_smbpass.so in the format of Linux /etc/pam.d/ files structure. Those wishing to implement this tool on other platforms will need to adapt this appropriately. -

Password Synchronisation Configuration

A sample PAM configuration that shows the use of pam_smbpass to make sure private/smbpasswd is kept in sync when /etc/passwd (/etc/shadow) is changed. Useful when an expired password might be changed by an @@ -443,7 +442,7 @@ password requisite pam_cracklib.so retry=3 password requisite pam_unix.so shadow md5 use_authtok try_first_pass password required pam_smbpass.so nullok use_authtok try_first_pass session required pam_unix.so -

Password Migration Configuration

A sample PAM configuration that shows the use of pam_smbpass to migrate from plaintext to encrypted passwords for Samba. Unlike other methods, this can be used for users who have never connected to Samba shares: @@ -462,7 +461,7 @@ password requisite pam_cracklib.so retry=3 password requisite pam_unix.so shadow md5 use_authtok try_first_pass password optional pam_smbpass.so nullok use_authtok try_first_pass session required pam_unix.so -

Mature Password Configuration

A sample PAM configuration for a 'mature' smbpasswd installation. private/smbpasswd is fully populated, and we consider it an error if the smbpasswd doesn't exist or doesn't match the Unix password. @@ -477,7 +476,7 @@ password requisite pam_cracklib.so retry=3 password requisite pam_unix.so shadow md5 use_authtok try_first_pass password required pam_smbpass.so use_authtok use_first_pass session required pam_unix.so -

Kerberos Password Integration Configuration

A sample PAM configuration that shows pam_smbpass used together with pam_krb5. This could be useful on a Samba PDC that is also a member of a Kerberos realm. @@ -493,13 +492,13 @@ password requisite pam_cracklib.so retry=3 password optional pam_smbpass.so nullok use_authtok try_first_pass password required pam_krb5.so use_authtok try_first_pass session required pam_krb5.so -