JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: Security Services     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information


Part I Security Overview

1.  Security Services (Overview)

Part II System, File, and Device Security

2.  Managing Machine Security (Overview)

3.  Controlling Access to Systems (Tasks)

4.  Virus Scanning Service (Tasks)

5.  Controlling Access to Devices (Tasks)

6.  Using the Basic Audit Reporting Tool (Tasks)

7.  Controlling Access to Files (Tasks)

Part III Roles, Rights Profiles, and Privileges

8.  Using Roles and Privileges (Overview)

9.  Using Role-Based Access Control (Tasks)

10.  Security Attributes in Oracle Solaris (Reference)

Part IV Cryptographic Services

11.  Cryptographic Framework (Overview)

12.  Cryptographic Framework (Tasks)

13.  Key Management Framework

Part V Authentication Services and Secure Communication

14.  Network Services Authentication (Tasks)

15.  Using PAM

PAM (Overview)

Benefits of Using PAM

Introduction to the PAM Framework

Changes to PAM for This Release

PAM (Tasks)

PAM (Task Map)

Planning for Your PAM Implementation

How to Add a PAM Module

How to Prevent Rhost-Style Access From Remote Systems With PAM

How to Log PAM Error Reports

PAM Configuration (Reference)

PAM Configuration File Syntax

How PAM Stacking Works

PAM Stacking Example

16.  Using SASL

17.  Using Secure Shell (Tasks)

18.  Secure Shell (Reference)

Part VI Kerberos Service

19.  Introduction to the Kerberos Service

20.  Planning for the Kerberos Service

21.  Configuring the Kerberos Service (Tasks)

22.  Kerberos Error Messages and Troubleshooting

23.  Administering Kerberos Principals and Policies (Tasks)

24.  Using Kerberos Applications (Tasks)

25.  The Kerberos Service (Reference)

Part VII Auditing in Oracle Solaris

26.  Auditing (Overview)

27.  Planning for Auditing

28.  Managing Auditing (Tasks)

29.  Auditing (Reference)



PAM Configuration (Reference)

The PAM configuration file, pam.conf(4), is used to configure PAM service modules for system services, such as login, rlogin, su, and cron. The system administrator manages this file. An incorrect order of entries in pam.conf can cause unforeseen side effects. For example, a badly configured pam.conf can lock out users so that single-user mode becomes necessary for repair. For a description of setting the order, see How PAM Stacking Works.

PAM Configuration File Syntax

The entries in the configuration file are in the format:

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

Name of the service, for example, ftp, login, or passwd. An application can use different service names for the services that the application provides. For example, the Oracle Solaris secure shell daemon uses these service names: sshd-none, sshd-password, sshd-kbdint, sshd-pubkey, and sshd-hostbased. The service-name other is a predefined name that is used as a wildcard service-name. If a particular service-name is not found in the configuration file, the configuration for other is used.


The type of service, that is, auth, account, session, or password.


Indicates the role of the module in determining the integrated success or failure value for the service. Valid control flags are binding, include, optional, required, requisite, and sufficient. See How PAM Stacking Works for information on the use of these flags.


The path to the library object that implements the service. If the pathname is not absolute, the pathname is assumed to be relative to /usr/lib/security/$ISA/. Use the architecture-dependent macro $ISA to cause libpam to look in the directory for the particular architecture of the application.


Options that are passed to the service modules. A module's man page describes the options that are accepted by that module. Typical module options include nowarn and debug.

How PAM Stacking Works

When an application calls on the following functions, libpam reads the configuration file /etc/pam.conf to determine which modules participate in the operation for this service:

If /etc/pam.conf contains only one module for an operation for this service such as authentication or account management, the result of that module determines the outcome of the operation. For example, the default authentication operation for the passwd application contains one module,

passwd  auth required 

If, on the other hand, there are multiple modules defined for the service's operation, those modules are said to be stacked and that a PAM stack exists for that service. For example, consider the case where pam.conf contains the following entries:

login   auth requisite
login   auth required 
login   auth required 
login   auth required 
login   auth required 

These entries represent a sample auth stack for the login service. To determine the outcome of this stack, the result codes of the individual modules require an integration process. In the integration process, the modules are executed in order as specified in /etc/pam.conf. Each success or failure code is integrated in the overall result depending on the module's control flag. The control flag can cause early termination of the stack. For example, a requisite module might fail, or a sufficient or binding module might succeed. After the stack has been processed, the individual results are combined into a single, overall result that is delivered to the application.

The control flag indicates the role that a PAM module plays in determining access to the service. The control flags and their effects are:

The following two diagrams shows how access is determined in the integration process. The first diagram indicates how success or failure is recorded for each type of control flag. The second diagram shows how the integrated value is determined.

Figure 15-2 PAM Stacking: Effect of Control Flags

image:Flow diagram shows how control flags affect PAM stacking.

Figure 15-3 PAM Stacking: How Integrated Value Is Determined

image:Flow diagram shows how integrated values are determined in PAM stacking.

PAM Stacking Example

Consider the following example of an rlogin service that requests authentication.

Example 15-1 Partial Contents of a Typical PAM Configuration File

The pam.conf file in this example has the following contents for rlogin services:

     # Authentication management
     # rlogin service 
     rlogin  auth sufficient
     rlogin  auth requisite
     rlogin  auth required 
     rlogin  auth required 

When the rlogin service requests authentication, libpam first executes the pam_rhosts_auth(5) module. The control flag is set to sufficient for the pam_rhosts_auth module. If the pam_rhosts_auth module is able to authenticate the user, then processing stops and success is returned to the application.

If the pam_rhosts_auth module fails to authenticate the user, then the next PAM module, pam_authtok_get(5) is executed. The control flag for this module is set to requisite. If pam_authtok_get fails, then the authentication process ends and the failure is returned to rlogin.

If pam_authtok_get succeeds, then the next two modules, pam_dhkeys(5) and pam_unix_auth(5), are executed. Both modules have the associated control flags that are set to required so that the process continues regardless of whether an individual failure is returned. After pam_unix_auth is executed, no modules for rlogin authentication remain. At this point, if either pam_dhkeys or pam_unix_auth has returned a failure, the user is denied access through rlogin.