The PAM software consists of a library, several modules, and a configuration file. New versions of several system entry commands or daemons which take advantage of the PAM interfaces are also included.
The figure below illustrates the relationship between the applications, the PAM library, the pam.conf file, and the PAM modules.
The applications (ftp, telnet, and login) use the PAM library to access the appropriate module. The pam.conf file defines which modules to use, and in what order they are to be used with each application. Responses from the modules are passed back through the library to the application.
The following sections describe this relationship.
The PAM library, /usr/lib/libpam, provides the framework to load the appropriate modules and manage the stacking process. It provides a generic structure to which all of the modules can plug in.
Each PAM module implements a specific mechanism. When setting up PAM authentication, you need to specify both the module and the module type, which defines what the module will do. More than one module type (auth, account, session, or password) may be associated with each module.
The following list describes each of the PAM modules.
The pam_unix module, /usr/lib/security/pam_unix.so.1, provides support for authentication, account management, session management, and password management. Any of the four module type definitions can be used with this module. It uses UNIX passwords for authentication. In the Solaris environment, the selection of appropriate name services to get password records is controlled through the /etc/nsswitch.conf file. Seepam_unix(5) for more information.
The dial_auth module, /usr/lib/security/pam_dial_auth.so.1, can only be used for authentication. It uses data stored in the /etc/dialups and /etc/d_passwd files for authentication. This is mainly used by login. See pam_dial_auth(5) for more information.
The rhosts_auth module, /usr/lib/security/pam_rhosts_auth.so.1, can also only be used for authentication. It uses data stored in the ~/.rhosts and /etc/host.equiv files through ruserok(). This is mainly used by the rlogin and rsh commands. See pam_rhosts_auth(5) for more information.
The krb5 module, /usr/lib/security/pam_krb5_auth.so.1, provides support for authentication, account management, session management, and password management. Kerberos credentials are used for authentication.
For security reasons, these module files must be owned by root and must not be writable through group or other permissions. If the file is not owned by root, PAM will not load the module.
The PAM configuration file, /etc/pam.conf, determines the authentication services to be used, and in what order they are used. This file can be edited to select authentication mechanisms for each system-entry application.
The PAM configuration file consists of entries with the following syntax:
service_name module_type control_flag module_path module_options |
service_name |
Name of the service (for example, ftp, login, telnet). |
module_type |
Module type for the service. |
control_flag |
Determines the continuation or failure semantics for the module. |
module_path |
Path to the library object that implements the service functionality. |
module_options |
Specific options that are passed to the service modules. |
You can add comments to the pam.conf file by starting the line with a # (pound sign). Use white space to delimit the fields.
An entry in the PAM configuration file is ignored if one of the following conditions exist: the line has less than four fields, an invalid value is given for module_type or control_flag, or the named module is not found.
The table below lists some of the valid service names, the module types that can be used with that service, and the daemon or command associated with the service name.
There are several module types that are not appropriate for each service. For example, the password module type is only specified to go with the passwd command. There is no auth module type associated with this command since it is not concerned with authentication.
Table 20-1 Valid Service Names for /etc/pam.conf
Service Name |
Daemon or Command |
Module Type |
---|---|---|
dtlogin |
/usr/dt/bin/dtlogin |
auth, account, session |
ftp |
/usr/sbin/in.ftpd |
auth, account, session |
init |
/usr/sbin/init |
session |
login |
/usr/bin/login |
auth, account, session |
passwd |
/usr/bin/passwd |
password |
rexd |
/usr/sbin/rpc.rexd |
auth |
rlogin |
/usr/sbin/in.rlogind |
auth, account, session |
rsh |
/usr/sbin/in.rshd |
auth, account, session |
sac |
/usr/lib/saf/sac |
session |
su |
/usr/bin/su |
auth, account, session |
telnet |
/usr/sbin/in.telnetd |
auth, account, session |
ttymon |
/usr/lib/saf/ttymon |
session |
uucp |
/usr/sbin/in.uucpd |
auth, account, session |
To determine continuation or failure behavior from a module during the authentication process, you must select one of four control flags for each entry. The control flags indicate how a successful or a failed attempt through each module is handled. Even though these flags apply to all module types, the following explanation assumes that these flags are being used for authentication modules. The control flags are as follows:
required - This module must return success in order to have the overall result be successful.
If all of the modules are labeled as required, then authentication through all modules must succeed for the user to be authenticated.
If some of the modules fail, then an error value from the first failed module is reported.
If a failure occurs for a module flagged as required, all modules in the stack are still tried but failure is returned.
If none of the modules are flagged as required, then at least one of the entries for that service must succeed for the user to be authenticated.
requisite - This module must return success for additional authentication to occur.
If a failure occurs for a module flagged as requisite, an error is immediately returned to the application and no additional authentication is done. If the stack does not include prior modules labeled as required that failed, then the error from this module is returned. If a earlier module labeled as required has failed, the error message from the required module is returned.
optional - If this module fails, the overall result can be successful if another module in this stack returns success.
The optional flag should be used when one success in the stack is enough for a user to be authenticated. This flag should only be used if it is not important for this particular mechanism to succeed.
If your users need to have permission associated with a specific mechanism to get their work done, then you should not label it as optional.
sufficient - If this module is successful, skip the remaining modules in the stack, even if they are labeled as required.
The sufficient flag indicates that one successful authentication will be enough for the user to be granted access.
More information about these flags is provided in the section below, which describes the default /etc/pam.conf file.
The following is an example of a generic pam.conf file:
# PAM configuration # Authentication management # login auth required /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/security/pam_dial_auth.so.1 rlogin auth sufficient /usr/lib/security/pam_rhost_auth.so.1 rlogin auth required /usr/lib/security/pam_unix.so.1 dtlogin auth required /usr/lib/security/pam_unix.so.1 telnet auth required /usr/lib/security/pam_unix.so.1 su auth required /usr/lib/security/pam_unix.so.1 ftp auth required /usr/lib/security/pam_unix.so.1 uucp auth required /usr/lib/security/pam_unix.so.1 rsh auth required /usr/lib/security/pam_rhost_auth.so.1 OTHER auth required /usr/lib/security/pam_unix.so.1 # # Account management # login account required /usr/lib/security/pam_unix.so.1 rlogin account required /usr/lib/security/pam_unix.so.1 dtlogin account required /usr/lib/security/pam_unix.so.1 telnet account required /usr/lib/security/pam_unix.so.1 ftp account required /usr/lib/security/pam_unix.so.1 OTHER account required /usr/lib/security/pam_unix.so.1 # # Session management # login session required /usr/lib/security/pam_unix.so.1 rlogin session required /usr/lib/security/pam_unix.so.1 dtlogin session required /usr/lib/security/pam_unix.so.1 telnet session required /usr/lib/security/pam_unix.so.1 uucp session required /usr/lib/security/pam_unix.so.1 OTHER session required /usr/lib/security/pam_unix.so.1 # # Password management # passwd password required /usr/lib/security/pam_unix.so.1 OTHER password required /usr/lib/security/pam_unix.so.1 |
This generic pam.conf file specifies:
When running login, authentication must succeed for both the pam_unix and the pam_dial_auth modules.
For rlogin, authentication through the pam_unix module must succeed, if authentication through pam_rhost_auth fails.
The sufficient control flag indicates that for rlogin the successful authentication provided by the pam_rhost_auth module is sufficient and the next entry will be ignored.
Most of the other commands requiring authentication require successful authentication through the pam_unix module.
Authentication for rsh must succeed through the pam_rhost_auth module.
The OTHER service name allows a default to be set for any other commands requiring authentication that are not included in the file. The OTHER option makes it easier to administer the file, since many commands that are using the same module can be covered using only one entry. Also, the OTHER service name, when used as a "catch-all," can ensure that each access is covered by one module. By convention, the OTHER entry is included at the bottom of the section for each module type.
The rest of the entries in the file control the account, session, and password management.
With the use of the default service name, OTHER, the generic PAM configuration file is simplified to:
# PAM configuration # # Authentication management # login auth required /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/scurty/pam_dial_auth.so.1 rlogin auth sufficient /usr/lib/security/pam_unix.so.1 rlogin auth required /usr/lib/security/pam_rhost_auth.so.1 rsh auth required /usr/lib/security/pam_rhost_auth.so.1 OTHER auth required /usr/lib/security/pam_unix.so.1 # # Account management # OTHER account required /usr/lib/security/pam_unix.so.1 # # Session management # OTHER session required /usr/lib/security/pam_unix.so.1 # # Password management # OTHER password required /usr/lib/security/pam_unix.so.1 |
Normally, the entry for the module_path is "root-relative." If the file name you enter for module_path does not begin with a slash (/), the path /usr/lib/security/ is prepended to the file name. A full path name must be used for modules located in other directories.
The values for the module_options can be found in the man pages for the module. (For example, pam_unix(5)).
The use_first_pass and try_first_pass options, which are supported by the pam_unix module, let users reuse the same password for authentication without retyping it.
If login specifies authentication through both pam_local and pam_unix, then the user is prompted to enter a password for each module. In situations where the passwords are the same, the use_first_pass module option prompts for only one password and uses that password to authenticate the user for both modules. If the passwords are different, the authentication fails. In general, this option should be used with an optional control flag, as shown below, to make sure that the user can still log in.
# Authentication management # login auth required /usr/lib/security/pam_unix.so.1 login auth optional /usr/lib/security/pam_local.so.1 use_first_pass |
If the try_first_pass module option is used instead, the local module prompts for a second password if the passwords do not match or if an error is made. If both methods of authentication are necessary for a user to get access to all the needed tools, using this option could cause some confusion since the user could get access with only one type of authentication.