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_users in /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_domains in /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 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 This option specifies a list of domains against which a PAM service can authenticate. If you use domains without specifying any domain, the PAM service will not be able to authenticate against any domain, for example: 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. 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. Note 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_users and pam_public_domains options, see the sssd.conf(5) man page on your system. For more details on the domains option used in PAM configuration files, see the pam_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 domains option in the /etc/sssd/sssd.conf file: Specify the domain or domains to which a PAM service can authenticate by setting the domains option in the PAM configuration file. For example: In this example, you allow the PAM service to authenticate against domain1 only. 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 . Warning 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. For example: 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. 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. 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 1 This line 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. 2 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. 3 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. 4 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. 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=3 specifies that user has three attempts to create a strong password. 6 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. 7 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.

Commands:
auth required pam_sss.so domains=
[sssd] domains = domain1, domain2, domain3
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_authtok
module_type control_flag module_name module_arguments
auth required pam_unix.so
#%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