Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 10. Restricting domains for PAM services using SSSD

The System Security Services Daemon (SSSD) restricts Pluggable Authentication Modules (PAMs) service access to specific identity domains based on the user running the service. With this evaluation mechanism, you can enforce granular control, ensuring services only interact with authorized identity providers.

10.1. Introduction to PAM
Copier lien

Pluggable Authentication Modules (PAM) provide a modular framework for system authentication. Applications offload identity verification to centrally configured PAM stacks, helping you to implement flexible policies involving Kerberos, SSSD, or local files.

PAM is pluggable because a PAM module exists for different types of authentication sources, such as Kerberos, SSSD, NIS, or the local file system. You can prioritize different authentication sources.

This modular architecture offers administrators a great deal of flexibility in setting authentication policies for the system. PAM is a useful system for developers and administrators for several reasons:

  • PAM provides a common authentication scheme, which can be used with a wide variety of applications.
  • PAM provides significant flexibility and control over authentication for system administrators.
  • PAM provides a single, fully-documented library, which allows developers to write programs without having to create their own authentication schemes.

10.1.1. PAM configuration file format
Copier lien

Pluggable Authentication Module (PAM) configuration files consist of directives that control module behavior. Each line specifies the interface type, a control flag, the module library name, and optional arguments, instructing the system on how to process specific authentication tasks. 

module_type	control_flag	<module_name> <module_arguments>

For example: 

auth	required	pam_unix.so

10.1.1.1. PAM module types
Copier lien

PAM defines four interface types: account, authentication, password, and session. These categories determine the specific task a module performs, such as verifying credentials, setting up the user environment, or enforcing password complexity policies.

An individual module can provide any or all types of authentication tasks. For example, pam_unix.so provides all four authentication tasks.

The module name, such as pam_unix.so, provides PAM with the name of the library containing the specified module type. The directory name is omitted because the application is linked to the appropriate version of libpam, which can locate the correct version of the module.

Module type directives can be stacked, or placed upon one another, so that multiple modules are used together for one purpose. The order of the modules is important, along with the control flags, it determines how significant the success or failure of a particular module is to the overall goal of authenticating the user to the service.

You can stack PAM modules to enforce specific conditions that must be met before a user is allowed to authenticate.

10.1.1.2. PAM control flags
Copier lien

Control flags dictate how PAM handles module results. Keywords like required, requisite, and sufficient determine whether the authentication stack continues processing or immediately returns a success or failure status to the application.

Simple flags use a keyword, more complex syntax follows [<value1>=<action1> <value2>=<action2> …​] format.

Note

When a module’s control flag uses the sufficient or requisite value, the order in which the modules are listed is important to the authentication process.

For a detailed description of PAM control flags, including a list of options, see the pam.conf(5) man page.

10.2. Domain-access restriction options
Copier lien

Manage control domain access by using pam_trusted_users and pam_public_domains in sssd.conf. Additionally, the domains option in PAM configuration files limits specific services to a defined list of authentication providers.

To restrict access to selected domains, you can use the following options:

pam_trusted_users in /etc/sssd/sssd.conf
Lists numerical UIDs or user names for PAM services that SSSD trusts. The default setting is all, which means all service users are trusted and can access any domain.
pam_public_domains in /etc/sssd/sssd.conf
Specifies public SSSD domains that are accessible by untrusted PAM service users. The option accepts the all and none values. The default value is none, which means no domains are public and untrusted service users cannot access any domain.
domains for PAM configuration files

Specifies a list of domains against which a PAM service can authenticate. If you use domains without specifying any domain, the PAM service cannot authenticate against any domain, for example: 

auth     required   pam_sss.so domains=

If the PAM configuration file uses domains, the PAM service is able to authenticate against all domains when that service is running under a trusted user.

The domains option in the /etc/sssd/sssd.conf SSSD configuration file also specifies a list of domains to which SSSD attempts to authenticate. Note that the domains option in a PAM configuration file cannot extend the list of domains in sssd.conf, it can only restrict the sssd.conf list of domains by specifying a shorter list. Therefore, if a domain is specified in the PAM file but not in sssd.conf, the PAM service cannot authenticate against the domain.

The default settings pam_trusted_users = all and pam_public_domains = none specify that all PAM service users are trusted and can access any domain. Use the domains option in PAM configuration files to restrict domain access.

Specifying a domain using domains in the PAM configuration file while sssd.conf contains pam_public_domains also requires to specify the domain in pam_public_domains. The pam_public_domains option without including the required domain leads the PAM service to unsuccessful authentication against the domain in case this service is running under an untrusted user.

Note

Domain restrictions defined in a PAM configuration file apply to authentication actions only, not to user lookups.

10.3. Restricting domains for a PAM service
Copier lien

You can lock specific PAM services to a subset of available SSSD domains. This configuration forces the service to authenticate only against the specified providers, isolating critical applications from other identity sources.

Prerequisites

  • SSSD installed and running.

Procedure

  1. Configure SSSD to access the required domain or domains. Define the domains against which SSSD can authenticate in the domains option in the /etc/sssd/sssd.conf file: 

    [sssd]
domains = <idm.example.com>, <ad.example.com>, <ldap.example.com>

  2. Specify the domain or domains to which a PAM service can authenticate by setting the`domains` option in the PAM configuration file. For example: 

    auth        sufficient    pam_sss.so forward_pass domains=<idm.example.com>
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
password    sufficient    pam_sss.so use_authtok

    This configuration restricts the PAM service to authenticate against <idm.example.com> only.

Verification

  • Authenticate against <idm.example.com>. It must be successful.

10.4. About PAM configuration files
Copier lien

PAM configuration files in /etc/pam.d/ define policies for individual applications. Each file stacks specific modules to enforce security requirements, such as password quality checks or root access limits, for the service it controls.

For example, the login program has a corresponding PAM configuration file named /etc/pam.d/login.

Warning

Manual editing of PAM configuration files might lead to authentication and access issues. Configure PAMs using the authselect tool.

See an example of PAM configuration file with the detailed description.

Annotated PAM configuration example 

#%PAM-1.0
auth		required	pam_securetty.so
auth		required	pam_unix.so nullok
auth		required	pam_nologin.so
account		required	pam_unix.so
password	required	pam_pwquality.so retry=3
password	required	pam_unix.so shadow nullok use_authtok
session		required	pam_unix.so

where:

auth required pam_securetty.so
Ensures that the root login is allowed only from a terminal which is listed in the /etc/securetty file, if this file exists. If the terminal is not listed in the file, the login as root fails with a Login incorrect message.
auth required pam_unix.so nullok
Prompts the user for a password and checks it against the information stored in /etc/passwd and, if it exists, /etc/shadow. The nullok argument allows a blank password.
auth required pam_nologin.so

Checks if /etc/nologin file exists. If it exists, and the user is not root, authentication fails.

Note

In this example, all three auth modules are checked, even if the first auth module fails. This is a good security approach that prevents potential attacker from knowing at what stage their authentication failed.

account required pam_unix.so
Verifies the user’s account. For example, if shadow passwords have been enabled, the account type of the pam_unix.so module checks for expired accounts or if the user needs to change the password.
password required pam_pwquality.so retry=3
Prompts for a new password if the current one has expired or when the user manually requests a password change. Then it checks the strength of the newly created password to ensure it meets quality requirements and is not easily determined by a dictionary-based password cracking program. The argument retry=3 specifies that user has three attempts to create a strong password.
password required pam_unix.so shadow nullok use_authtok
The pam_unix.so module manages password changes. The shadow argument instructs the module to create shadow passwords when updating a user’s password. The nullok argument allows the user to change their password from a blank password, otherwise a null password is treated as an account lock. The use_authtok argument accepts any password that was entered previously without prompting the user again. In this way, all new passwords must pass the pam_pwquality.so check for secure passwords before being accepted.
session required pam_unix.so
The pam_unix.so module manages the session and logs the user name and service type at the beginning and end of each session. Logs are collected by the systemd-journald service and can be viewed by using the journalctl command. Logs are also stored in /var/log/secure. This module can be supplemented by stacking it with other session modules for additional functionality.
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début