JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 11.1 Administration: Security Services     Oracle Solaris 11.1 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.  Verifying File Integrity by Using BART (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.  Using Pluggable Authentication Modules

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

How to Assign a Customized PAM Policy to a User

How to Assign a New Rights Policy to All Users

PAM Configuration (Reference)

PAM Configuration Search Order

PAM Configuration File Syntax

Per User Authentication Policy

How PAM Stacking Works

PAM Stacking Example

15.  Using Secure Shell

16.  Secure Shell (Reference)

17.  Using Simple Authentication and Security Layer

18.  Network Services Authentication (Tasks)

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)

System applications, like ssh, that use the PAM service are configured in the PAM configuration files. See the pam.conf(4) man page for more information. These configuration files include the /etc/pam.conf file, as well as service specific files placed in /etc/pam.d. Changes to these files affect all users on the system. The service specific PAM configuration files are the preferred mechanism for configuring PAM, since their granularity means a mistake in a file only affects that service. Also, adding new PAM services is simplified to copying a single file. The service specific files allow for better interoperability with other cross-platform PAM applications, since /etc/pam.d is the default configuration in most PAM implementations.

In addition, PAM policy files can be used to create authentication policies for individual services and assign those policies either to an individual, a group of individuals, or all users, as needed. The default PAM policy files are located in /etc/security/pam_policy. The PAM policy files provide the ability to set or change the authentication policy for one or more users in a safe and reliable manner.

The system administrator manages the PAM configuration files. An incorrect order of entries in these files can cause unforeseen side effects. For example, a badly configured file 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 Search Order

The PAM configuration information in the PAM configuration files is collected by the PAM library in the following order:

  1. The service name is looked for in /etc/pam.conf.

  2. /etc/pam.d/service is checked.

  3. The service name other is checked in /etc/pam.conf.

  4. The /etc/pam.d/other file is checked.

This order allows for an existing /etc/pam.conf file to work with the per-service PAM configuration files located in /etc/pam.d.

PAM Configuration File Syntax

The /etc/pam.conf file and the PAM policy files use a syntax that is different than the service specific files. The syntax of each of these files is described below.

The entries in /etc/pam.conf or in PAM policy files are in one of the following formats:

service-name module-type control-flag module-path module-options
service-name module-type include path-to-included-PAM-configuration

The case insensitive name of the service, for example, 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, definitive, 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.


Gives the full path to a separate PAM configuration file or a path name relative to the /usr/lib/security directory.

The per-service configuration files located in /etc/pam.d use the same syntax as pam.conf, but don't include the service name. When using the per-service configuration files, the name of the file is the service name. For instance, /etc/pam.d/cron includes the PAM configuration for the cron command.

Per User Authentication Policy

The pam_user_policy PAM module allows system administrators to specify PAM configurations on a per-user basis. The pam_policy key for the user needs to provide the path to a user-specific PAM configuration file. See the pam_user_policy(5) man page for more information.

Here are some ways to establish a per-user authentication policy:

How PAM Stacking Works

When an application calls one of the following functions, libpam reads the PAM configuration files to determine which modules participate in the operation for this service:

If the configuration files contain 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 /etc/pam.d/login contains the following entries:

auth definitive
auth requisite
auth required 
auth required 
auth required 

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 the file. 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 or definitive module might fail, or a sufficient, definitive, 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 14-2 PAM Stacking: Effect of Control Flags

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

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

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

PAM Stacking Example

This example shows the default definitions for authentication management in the /etc/pam.d/other file. These definitions are used if no service-specific definitions have been configured.

# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
auth definitive
auth requisite
auth required 
auth required 
auth required  

First, the security policy for the user is checked using the pam_user_policy module. The definitive control flag selects that if the evaluation of the security policy succeeds, the service returns success to the application, since no other modules have been checked at this point. If the request fails, then a failure message is sent to the application and no further checking is done. If no policy is set for the user, then the next module is executed.

If a per-user PAM policy isn't specified for this user, then the pam_authtok_get module 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 the service.

If pam_authtok_get does not fail, then the next three modules are executed. These modules are configured with the required control flag, so that the process continues regardless of whether an individual failure is returned. After pam_unix_cred is executed, no modules remain. At this point, if all the modules succeeded, the user is granted access. If either pam_dhkeys, pam_unix_auth, or pam_unix_cred has returned a failure, the user is denied access.