Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 11. Restricting domains for PAM services using SSSD
Pluggable authentication modules (PAMs) are a common framework for authentication and authorization. Most system applications in Red Hat Enterprise Linux depend on underlying PAM configuration for authentication and authorization.
System Security Services Daemon (SSSD) enables you to restrict which domains PAM services can access. SSSD evaluates authentication requests from PAM services based on the user that runs the particular PAM service. This means, if the PAM service user can access an SSSD domain then the PAM service also can access that domain.
11.1. About PAM
Pluggable Authentication Modules (PAMs) provide a centralized authentication mechanism, which a system application can use to relay authentication to a centrally configured framework.
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.
11.2. Domain-access restriction options
The following options are available to restrict access to selected domains:
pam_trusted_usersin/etc/sssd/sssd.conf-
This option accepts a list of numerical UIDs or user names representing the PAM services that SSSD trusts. The default setting is
all, which means all service users are trusted and can access any domain. pam_public_domainsin/etc/sssd/sssd.conf-
This option accepts a list of public SSSD domains. Public domains are domains accessible even for untrusted PAM service users. The option also accepts the
allandnonevalues. The default value isnone, which means no domains are public and untrusted service users cannot access any domain. domainsfor PAM configuration filesThis option specifies a list of domains against which a PAM service can authenticate. If you use
domainswithout specifying any domain, the PAM service will not be able to 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
domainsoption in the/etc/sssd/sssd.confSSSD configuration file also specifies a list of domains to which SSSD attempts to authenticate. Note that thedomainsoption in a PAM configuration file cannot extend the list of domains insssd.conf, it can only restrict thesssd.conflist of domains by specifying a shorter list. Therefore, if a domain is specified in the PAM file but not insssd.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. Using the domains option for PAM configuration files restricts the access to the domains.
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.
Domain restrictions defined in a PAM configuration file apply to authentication actions only, not to user lookups.
Additional resources
-
For more details on the
pam_trusted_usersandpam_public_domainsoptions, see thesssd.conf(5)man page on your system. -
For more details on the
domainsoption used in PAM configuration files, see thepam_sss(8)man page on your system.
11.3. Restricting domains for a PAM service
This procedure shows how to restrict a PAM service authentication against the domains.
Prerequisites
- SSSD installed and running.
Procedure
Configure SSSD to access the required domain or domains. Define the domains against which SSSD can authenticate in the
domainsoption in the/etc/sssd/sssd.conffile:[sssd] domains = domain1, domain2, domain3Specify the domain or domains to which a PAM service can authenticate by setting the
domainsoption in the PAM configuration file. For example:auth sufficient pam_sss.so forward_pass domains=domain1 account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtokIn this example, you allow the PAM service to authenticate against
domain1only.
Verification
-
Authenticate against
domain1. It must be successful.
11.4. About PAM configuration files
PAM configuration files specify the authentication methods and policies for services in Red Hat Enterprise Linux. Each PAM aware application or service has a corresponding file in the /etc/pam.d/ directory. The file is named after the service it controls access to. For example, the login program has a corresponding PAM configuration file named /etc/pam.d/login.
Manual editing of PAM configuration files might lead to authentication and access issues. Configure PAMs using the authselect tool.
PAM configuration file format
Each PAM configuration file consists of directives that define settings for a specific module. PAM uses arguments to pass information to a pluggable module during authentication for some modules.
module_type control_flag module_name module_arguments
For example:
auth required pam_unix.so
PAM module types
A PAM module type specifies the type of authentication task that a module performs. The module can perform the following tasks:
- account management
- authentication management
- password management
- session management
An individual module can provide any or all module types. For example, pam_unix.so provides all four module types.
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.
PAM control flags
When a PAM module performs its function, it returns a success or failure result. Control flags instruct PAM on how to handle this result.
Simple flags use a keyword, more complex syntax follows [value1=action1 value2=action2 …] format.
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.
Additional resources
-
pam.conf(5)man page -
pam(8)man page
11.5. PAM configuration example
See an example of PAM configuration file with the detailed description.
Annotated PAM configuration example
#%PAM-1.0 auth required pam_securetty.so 1 auth required pam_unix.so nullok 2 auth required pam_nologin.so 3 account required pam_unix.so 4 password required pam_pwquality.so retry=3 5 password required pam_unix.so shadow nullok use_authtok 6 session required pam_unix.so 7
- 1
- This line ensures that the root login is allowed only from a terminal which is listed in the
/etc/securettyfile, if this file exists. If the terminal is not listed in the file, the login as root fails with aLogin incorrectmessage. - 2
- Prompts the user for a password and checks it against the information stored in
/etc/passwdand, if it exists,/etc/shadow. Thenullokargument allows a blank password. - 3
- Checks if
/etc/nologinfile exists. If it exists, and the user is not root, authentication fails.NoteIn this example, all three
authmodules are checked, even if the firstauthmodule fails. This is a good security approach that prevents potential attacker from knowing at what stage their authentication failed. - 4
- Verifies the user’s account. For example, if shadow passwords have been enabled, the account type of the
pam_unix.somodule checks for expired accounts or if the user needs to change the password. - 5
- 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=3specifies that user has three attempts to create a strong password. - 6
- The
pam_unix.somodule manages password changes. Theshadowargument instructs the module to create shadow passwords when updating a user’s password. Thenullokargument allows the user to change their password from a blank password, otherwise a null password is treated as an account lock. Theuse_authtokargument accepts any password that was entered previously without prompting the user again. In this way, all new passwords must pass thepam_pwquality.socheck for secure passwords before being accepted. - 7
- The
pam_unix.somodule manages the session and logs the user name and service type at the beginning and end of each session. Logs are collected by thesystemd-journaldservice and can be viewed by using thejournalctlcommand. Logs are also stored in/var/log/secure. This module can be supplemented by stacking it with other session modules for additional functionality.
