[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]

System Management Concepts: Operating System and Devices

Pluggable Authentication Module (PAM) Overview

The Pluggable Authentication Module (PAM) framework allows for new authentication technologies to be plugged-in without changing your application commands such as web_auth, file_copy, or screen_save. It can be used to integrate an AIX login with other security mechanisms sich as DCE or Kerberos. Mechanisms for account, session, and password management can also be plugged in using this framework.

PAM allows the system administrator to choose any combination of services to provide authentication. The list below includes some of the advantages of PAM to the system administrator.

PAM Terminology

PAM employs run-time pluggable modules that provide authentication-related services. These modules are broken into four different categories: authentication, account management, session management, and password management.

Authentication Modules
Authenticate users and set, refresh, or destroy credentials. These modules identify the user based on his or her authentication and credentials.

Account Modules
Check for password aging, account expiration, and access hour restrictions. After the user is identified using the authentication modules, account modules determine if the user is given access based on his or her account restrictions.

Session Modules
Manage the opening and closing of an authentication session. Optionally, they can log activity or provide for clean-up after the session is over.

Password Modules
Manage changes to the password and the password-related attributes.

PAM uses a concept called stacking to fully identify users through multiple authentication methods. Depending on the configuration, a user can be prompted for one or more passwords for each authentication method. The user does not need to remember to execute another command to get fully authenticated. The order in which methods are used is set in the/etc/pam.conf configuration file.

Stacking can require that a user must remember several passwords. However, if password mapping is supported by the underlying module, a primary password can be used to decrypt the other passwords, so the user only needs to remember the primary password. Alternatively, an administrator can synchronize the password across each authentication mechanism, but this method might increase the security risk because the security of each mechanism would be limited by the least secure password method used in the stack.

Administering a PAM Framework

The following figure illustrates the relationship between the applications, the PAM library, and the PAM modules. The applications (web_auth, file_copy, and screen_save) use the PAM library to access the appropriate module. The pam.conf file defines which modules are used with each application. Responses from the modules are passed back through the library to the application.

Figure 3-2. PAM Framework and Entities. This illustration shows ficticious application commands using the PAM library to access the appropriate PAM module.

Figure pam not displayed.

The PAM software consists of a library, several modules and a configuration file. The current release also includes new versions of several commands which use the PAM interfaces.

PAM Library

The PAM library, /usr/lib/libpam, provides the framework to load the appropriate modules and manage stacking. It provides a generic structure for all of the modules to plug into.

PAM Modules

Each PAM module provides the implementation of a specific mechanism. More than one module type (authentication, account, session, or password) can be associated with each module, but each module needs to manage at least one module type. Here is a description of some of the modules.

Because the pam_unix module, /usr/lib/security/pam_unix.so.1, provides support for authentication, account management, session management, and password management, any module type definition can be used with this module. The pam_unix module uses AIX passwords for authentication.

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 module is mainly used by the login command.

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 subroutine. Thismodule is mainly used by the rlogin and rsh command.

The pam_dce module, /usr/lib/security/pam_dce.so.1, provides support for authentication, account management, and password management. Any of these module type definitions can be used with this module. The module uses DCE registry for authentication.

For security reasons, these files must be owned by the root user and the permissions must be set so group or other cannot write to the files. If files are not owned by the root user, then PAM does not load the module.

PAM Configuration File

The /etc/pam.conf configuration file can be edited to select authentication mechanisms for each system-entry application. The file consists of entries that use the following syntax:

service_name module_type control_flag module_path module_options


Indicates the name of the service

Denotes the module type for the service

Selects the continuation and failure semantics for the module

Specifies the pathname to a library object which implements the service functionality

List specific options that can be passed to the service modules

The only optional component is module_options. The other values must be defined. Comments can be added to the file by starting a line with a pount sign (#). Whitespace delimits the fields.

An entry in this file is ignored if one of the following conditions exist:

One of three control_flags values must be selected for each entry to determine continuation or failure behavior from the module. These flags determine what the ultimate result (success or failure) will be. The values are defined below:

This module must return success for the overall result be successful.

If this module fails, the overall result can be successful if another module in this stack returns success.

If this module is successful, skip the remaining modules in the stack, even if any are flagged as required.

If all of the modules are flagged as required, then authentication through all modules must succeed for the user to be authenticated. If some of the modules fail, then a error value from the first failed module is reported. If a failure occurs for a required module, all modules in the stack are still tried but the access is denied.

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. The optional flag should be used when one success in the stack is enough. This flag should only be used when it is not important for this mechanism to succeed. For instance, if your users must have permission associated with a specific mechanism to get their work done, then that entry should not be flagged as optional.

The sufficient flag allows for one successful authentication to be enough for the user to get in.

Configuring PAM

The section below discusses some of the tasks that might be required for full PAM functionality. In particular, you should be note the security issues associated with each potential change to the configuration file.

When configuring PAM for your site, use the following general procedure:

  1. Determine what your authentication needs are and which modules fulfill your requirements.
  2. Identify which services need special attention.
  3. Decide on the sequence in which the modules should be run.
  4. Select a control flag for each module.
  5. Choose options, if necessary, for each module

Consider the following before changing the configuration file:

Disabling the ~/.rhosts Entries

To disable reading the ~/.rhosts files during an rlogin session, remove the rlogin auth rhosts_auth.so.1 entry from the configuration file. This action prevents unauthenticated access to the local system from remote systems and requires a password for any rlogin access, regardless of the presence or contents of any ~/.rhosts or /etc/hosts.equiv files.

To prevent other non-authenticated access using the ~/.rhosts files remember to disable the rsh service. The best way to disable a particular service is to remove the service entry from the /etc/inetd.conf file. Making changes to the PAM configuration file does not prevent the service from starting.

Adding the DCE PAM Module

To add the DEC PAM module, edit the /etc/pam.conf file to look like the following:

# # PAM configuration # # Authentication management # login auth sufficient 
/usr/lib/security/pam_dce.so.1 login auth required /usr/lib/security/pam_unix.so.1
rlogin auth required /usr/lib/security/pam_unix.so.1 rsh auth required 
OTHER auth required /usr/lib/security/pam_unix.so.1 # # Account management
# login account required /usr/lib/security/pam_dce.so.1 login account required
/usr/lib/security/pam_unix.so.1 OTHER account required 
# # Session management # OTHER session required /usr/lib/security/pam_unix.so.1
# # Password management # passwd password required /usr/lib/security/pam_dce.so.1
passwd password required /usr/lib/security/pam_unix.so.1

The sufficient flag on the login entry indicates that a user is authenticated if the pam_dce module suceeds, regardless of other modules, such as the pam_unix module. In this case, the pam_unix module is checked only when authentication through the pam_dce module fails.

The two entries for login authentication allow the root user to access the local system. This extra line is necessary because DCE does not grant root access by default. Because of these lines, non-root users without AIX password cannot get in, but a locally defined root account is able gain access.

The above example illustrates the DCE module's use only with the login command. However, the DCE module can be added for other services. If the pam_dce module is added as an auth module for login, it must also be added as an account module as well. The DCE entry for the passwd service ensures that the DCE password is also changed when the user runs the password command.

Changing /etc/pam.conf

Note: If the PAM configuration file is misconfigured or becomes corrupted, it is possible that even the root user could not be able to login. The root user could use the su command, since it does not use PAM, then reboot the machine as a single-user machine to fix the /etc/pam.conf configuration file.

You must be logged in as the root user to edit the /etc/pam.conf file. Whenever you change the /etc/pam.conf file, and while you are still logged in as root, test each command that might be affected by your changes to ensure the configuration file remains valid. For example, if you add a new module to the telnet service, use the telnet command to test your changes and verify that the /etc/pam.conf file performs as expected.

Adding a Module

Use the following procedure to add a PAM module:

  1. Study the documentation on the module and determine which control flags and other options should be used.
  2. Copy the new module to /usr/lib/security.
  3. Set the permissions so the module file is owned by root and permissions are 555.
  4. Edit the PAM configuration file, /etc/pam.conf, to add this module to the appropriate services.
  5. Test your changes.

Initiating Error Reporting

Add entries to /etc/syslog.conf to initiate error reporting. The syslogd daemon must be restarted or a SIGHUP signal sent to it for any changes to take effect. The following selections can be added to the file to gather information about PAM:

Messages about conditions that should be fixed now

Critical messages

Error messages

Informational messages

Debugging messages

The following entry prints all alert messages to the console. Critical messages are mailed to the root user. Informational and debug messages are added to /var/log/pamlog.

auth.alert /dev/console
auth.crit 'root'
auth.info;auth.debug /var/log/pamlog

Each line in the log contains a time stamp, the name of the system that generated it, and a message. The /var/log/pamlog file can log a large amount of information.

[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]