Managing Kerberos and Other Authentication Services in Oracle^® Solaris 11.3

About PAM

PAM provides a framework for applications to perform various authentication functions. It provides central authentication, session management, password management, and account limitations for users of applications, including system programs. PAM enables these programs, such as login, su, and ssh, to remain unchanged when user management details change. Site applications can use PAM to manage their own account, credential, session, and password requirements. PAM is "plugged in" to these applications.

Introduction to the PAM Framework

The PAM framework consists of four parts:

• Applications that use PAM

• PAM framework

• PAM service modules

• PAM configuration, including choice of modules and user assignment

The framework provides a uniform way for authentication-related activities to take place. This approach enables application developers to use PAM services without having to know the semantics of the authentication policy. With PAM, administrators can tailor the authentication process to the needs of a particular system without having to change any applications. Rather, administrators adjust the PAM configuration.

The following figure illustrates the PAM architecture.

Figure 1  PAM Architecture

The architecture works as follows:

• Applications communicate with the PAM framework through the PAM application programming interface (API).

  For information about using the API, see the pam(3PAM) man page and Chapter 3, Writing PAM Applications and Services in Developer’s Guide to Oracle Solaris 11.3 Security.

• PAM service modules communicate with the PAM framework through the PAM service provider interface (SPI). For more information, see the pam_sm(3PAM) man page.

  For a brief description of selected service modules, see PAM Service Modules and the pam.conf(4) and pam_user_policy(5) man pages.

Administrators can configure one or more series of modules to manage site requirements. This series of modules is called a PAM stack. The stack is evaluated in order. If an application requires more than one PAM stack, the application developer must create more than one service name. For example, the sshd daemon provides and requires several service names for PAM. For the list of PAM service names for the sshd daemon, search for the word PAM in the sshd(1M) man page. For details of the PAM stack, see PAM Stacking. PAM Stacking Example steps through a PAM authentication stack.

Benefits of Using PAM

The PAM framework enables you to configure the requirements that users must satisfy to use an application. The following are some of the benefits that PAM provides:

• Flexible PAM configuration policy

  • Per-service name authentication policy

  • Site-wide PAM policy and per-user PAM policy

  • Administrative choice of a default authentication policy

  • Enforcement of multiple user requirements on high-security systems

• Ease of use for the end user

  • No retyping of identical passwords for different authentication services

  • User prompting by multiple authentication services rather than requiring a user to type multiple commands

• Ease of configuration for the administrator

  • The ability to pass options to the PAM service module

  • The ability to implement a site-specific security policy without having to change the applications

Planning a Site-Specific PAM Configuration

As delivered, the PAM configuration implements a standard security policy that covers system services that require authentication, such as login and ssh. If you need to implement a different security policy for some system services or create a policy for third-party applications, consider the following issues:

• Determine that the provided configuration files do not satisfy your requirements.

  Test the default configuration. Test the per-user files in the /etc/security/pam_policy directory. Test whether the default service name other handles your requirements. PAM Stacking Example steps you through the other stack.

• Identify any service names whose stack needs modification. For an example of modifying a service name's PAM stack, see How to Create a Site-Specific PAM Configuration File.

• For any third-party application that is coded to use the PAM framework, determine the PAM service names that the application uses.

• For each service name, determine which PAM modules to use.

  Review the section 5 man pages for the PAM modules. These man pages describe how each module functions, what options are available, and the interactions between stacked modules. For a brief summary of selected modules, see PAM Service Modules. PAM modules are also available from outside sources.

• Per service name, decide the order in which to run the modules.

• Select the control flag for each module. For more information about control flags, see PAM Stacking. Note that the control flags can have security implications.

  For a visual representation, see PAM Stacking: Effect of Control Flags and PAM Stacking: How Integrated Value Is Determined.

• Choose the options that are necessary for each module. The man page for each module lists the options that are available for that module.

• Test the use of the application with the PAM configuration. Test as the root role, other roles, privileged users, and regular users. If some users are not permitted to use the application, test those users.

Assigning a Per-User PAM Policy

The pam_user_policy PAM module enables system administrators to assign specific PAM configurations on a per-user basis. When this module is the first module in a PAM stack, and the pam_policy security attribute for the user specifies a PAM configuration file, that file specifies the PAM policy for the user.

For more information, see the following:

• pam_user_policy(5) man page

• PAM Stacking

• How to Create a Site-Specific PAM Configuration File

• Example 4, Setting Per-User PAM Policy by Using a Rights Profile