Red Hat Enterprise Linux 9 Configuring Authentication and Authorization in Rhel
Red Hat Enterprise Linux 9 Configuring Authentication and Authorization in Rhel
Red Hat Enterprise Linux 9 Configuring Authentication and Authorization in Rhel
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons
Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is
available at
http://creativecommons.org/licenses/by-sa/3.0/
. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must
provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,
Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift,
Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States
and other countries.
Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.
XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and
other countries.
Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the
official Joyent Node.js open source or commercial project.
The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marks
or trademarks/service marks of the OpenStack Foundation, in the United States and other
countries and are used with the OpenStack Foundation's permission. We are not affiliated with,
endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
Abstract
You can configure Red Hat Enterprise Linux (RHEL) to authenticate and authorize users to
services, such as Red Hat Identity Management (IdM), Active Directory (AD), and LDAP directories.
For that, RHEL uses the System Security Services Daemon (SSSD) to communicate to these
services. Utilities, such as authselect and sssctl support you in configuring SSSD, Pluggable
Authentication Modules (PAM) and the Name Service Switch (NSS).
Table of Contents
Table of Contents
. . . . . . . . . .OPEN
MAKING . . . . . . SOURCE
. . . . . . . . . .MORE
. . . . . . .INCLUSIVE
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . . . . .
. . . . . . . . . . . . . FEEDBACK
PROVIDING . . . . . . . . . . . . ON
. . . .RED
. . . . .HAT
. . . . .DOCUMENTATION
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. . . . . . . . . . . . .
.CHAPTER
. . . . . . . . . . 1.. .CONFIGURING
. . . . . . . . . . . . . . . .USER
. . . . . .AUTHENTICATION
. . . . . . . . . . . . . . . . . . . .USING
. . . . . . . AUTHSELECT
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. . . . . . . . . . . . .
1.1. WHAT IS AUTHSELECT USED FOR 6
1.1.1. Files and directories authselect modifies 7
1.1.2. Data providers in /etc/nsswitch.conf 8
1.2. CHOOSING AN AUTHSELECT PROFILE 9
1.3. MODIFYING A READY-MADE AUTHSELECT PROFILE 10
1.4. CREATING AND DEPLOYING YOUR OWN AUTHSELECT PROFILE 11
1.5. CONVERTING YOUR SCRIPTS FROM AUTHCONFIG TO AUTHSELECT 12
1.6. ADDITIONAL RESOURCES 14
.CHAPTER
. . . . . . . . . . 2.
. . UNDERSTANDING
. . . . . . . . . . . . . . . . . . . .SSSD
. . . . . .AND
. . . . . ITS
. . . .BENEFITS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
..............
2.1. HOW SSSD WORKS 15
2.2. BENEFITS OF USING SSSD 15
2.3. MULTIPLE SSSD CONFIGURATION FILES ON A PER-CLIENT BASIS 16
How SSSD processes the configuration files 16
2.4. IDENTITY AND AUTHENTICATION PROVIDERS FOR SSSD 16
Identity and Authentication Providers as SSSD domains 17
Proxy Providers 17
Available Combinations of Identity and Authentication Providers 17
. . . . . . . . . . . 3.
CHAPTER . . ENABLING
. . . . . . . . . . . . THE
. . . . .LOCAL
. . . . . . . .FILES
. . . . . . PROVIDER
. . . . . . . . . . . .FOR
. . . . .SSSD
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
..............
.CHAPTER
. . . . . . . . . . 4.
. . .CONFIGURING
. . . . . . . . . . . . . . . .SSSD
. . . . . .TO
. . . USE
. . . . .LDAP
. . . . . . AND
. . . . . REQUIRE
. . . . . . . . . . TLS
. . . . .AUTHENTICATION
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
..............
4.1. AN OPENLDAP CLIENT USING SSSD TO RETRIEVE DATA FROM LDAP IN AN ENCRYPTED WAY 20
4.2. CONFIGURING SSSD TO USE LDAP AND REQUIRE TLS AUTHENTICATION 20
.CHAPTER
. . . . . . . . . . 5.
. . ADDITIONAL
. . . . . . . . . . . . . . CONFIGURATION
. . . . . . . . . . . . . . . . . . . FOR
. . . . . IDENTITY
. . . . . . . . . . .AND
. . . . .AUTHENTICATION
. . . . . . . . . . . . . . . . . . . PROVIDERS
. . . . . . . . . . . . . . . . . . . . . .24
..............
5.1. ADJUSTING HOW SSSD INTERPRETS FULL USER NAMES 24
5.2. ADJUSTING HOW SSSD PRINTS FULL USER NAMES 25
5.3. ENABLING OFFLINE AUTHENTICATION 26
5.4. CONFIGURING DNS SERVICE DISCOVERY 27
5.5. CONFIGURING SIMPLE ACCESS PROVIDER RULES 28
5.6. CONFIGURING SSSD TO APPLY AN LDAP ACCESS FILTER 29
.CHAPTER
. . . . . . . . . . 6.
. . .SSSD
. . . . . .CLIENT-SIDE
. . . . . . . . . . . . . .VIEW
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
..............
6.1. OVERRIDING THE LDAP USERNAME ATTRIBUTE 31
6.2. OVERRIDING THE LDAP UID ATTRIBUTE 32
6.3. OVERRIDING THE LDAP GID ATTRIBUTE 34
6.4. OVERRIDING THE LDAP HOME DIRECTORY ATTRIBUTE 35
6.5. OVERRIDING THE LDAP SHELL ATTRIBUTE 37
6.6. LISTING OVERRIDES ON A HOST 38
6.7. REMOVING A LOCAL OVERRIDE 39
6.8. EXPORTING AND IMPORTING LOCAL VIEW 39
. . . . . . . . . . . 7.
CHAPTER . . CONFIGURING
. . . . . . . . . . . . . . . .A
. . RHEL
. . . . . . .HOST
. . . . . .TO
. . . .USE
. . . . AD
. . . .AS
. . . AN
. . . .AUTHENTICATION
. . . . . . . . . . . . . . . . . . . .PROVIDER
. . . . . . . . . . . . . . . . . . . . . . . . .40
..............
.CHAPTER
. . . . . . . . . . 8.
. . .REPORTING
. . . . . . . . . . . . .ON
. . . .USER
. . . . . .ACCESS
. . . . . . . . .ON
. . . .HOSTS
. . . . . . . .USING
. . . . . . .SSSD
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
..............
8.1. THE SSSCTL COMMAND 44
8.2. GENERATING ACCESS CONTROL REPORTS USING SSSCTL 44
8.3. DISPLAYING USER AUTHORIZATION DETAILS USING SSSCTL 45
1
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
.CHAPTER
. . . . . . . . . . 9.
. . .QUERYING
. . . . . . . . . . . DOMAIN
. . . . . . . . . .INFORMATION
. . . . . . . . . . . . . . . .USING
. . . . . . . SSSD
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
..............
9.1. LISTING DOMAINS USING SSSCTL 46
9.2. VERIFYING THE DOMAIN STATUS USING SSSCTL 46
.CHAPTER
. . . . . . . . . . 10.
. . . RESTRICTING
. . . . . . . . . . . . . . . DOMAINS
. . . . . . . . . . .FOR
. . . . .PAM
. . . . . SERVICES
. . . . . . . . . . . USING
. . . . . . . .SSSD
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
..............
10.1. ABOUT PAM 48
10.2. DOMAIN-ACCESS RESTRICTION OPTIONS 48
10.3. RESTRICTING DOMAINS FOR A PAM SERVICE 49
. . . . . . . . . . . 11.
CHAPTER . . .ELIMINATING
. . . . . . . . . . . . . . TYPOGRAPHICAL
. . . . . . . . . . . . . . . . . . . ERRORS
. . . . . . . . . .IN
. . LOCAL
. . . . . . . . SSSD
. . . . . . CONFIGURATION
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
..............
.CHAPTER
. . . . . . . . . . 12.
. . . TROUBLESHOOTING
. . . . . . . . . . . . . . . . . . . . . . .AUTHENTICATION
. . . . . . . . . . . . . . . . . . . WITH
. . . . . . SSSD
. . . . . . IN
. . . IDM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
..............
12.1. DATA FLOW WHEN RETRIEVING IDM USER INFORMATION WITH SSSD 53
12.2. DATA FLOW WHEN RETRIEVING AD USER INFORMATION WITH SSSD 54
12.3. DATA FLOW WHEN AUTHENTICATING AS A USER WITH SSSD IN IDM 55
12.4. NARROWING THE SCOPE OF AUTHENTICATION ISSUES 58
12.5. SSSD LOG FILES AND LOGGING LEVELS 60
12.5.1. SSSD log file purposes 61
12.5.2. SSSD logging levels 62
12.6. ENABLING DETAILED LOGGING FOR SSSD IN THE SSSD.CONF FILE 62
12.7. ENABLING DETAILED LOGGING FOR SSSD WITH THE SSSCTL COMMAND 63
12.8. GATHERING DEBUGGING LOGS FROM THE SSSD SERVICE TO TROUBLESHOOT AUTHENTICATION
ISSUES WITH AN IDM SERVER 64
12.9. GATHERING DEBUGGING LOGS FROM THE SSSD SERVICE TO TROUBLESHOOT AUTHENTICATION
ISSUES WITH AN IDM CLIENT 65
12.10. TRACKING CLIENT REQUESTS IN THE SSSD BACKEND 67
12.11. TRACKING CLIENT REQUESTS USING THE LOG ANALYZER TOOL 69
12.11.1. How the log analyzer tool works 69
12.11.2. Running the log analyzer tool 69
12.12. ADDITIONAL RESOURCES 70
.CHAPTER
. . . . . . . . . . 13.
. . . CONFIGURING
. . . . . . . . . . . . . . . . APPLICATIONS
. . . . . . . . . . . . . . . . .FOR
. . . . .A. .SINGLE
. . . . . . . .SIGN-ON
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
..............
13.1. PREREQUISITES 71
13.2. CONFIGURING FIREFOX TO USE KERBEROS FOR SINGLE SIGN-ON 71
13.3. VIEWING CERTIFICATES IN FIREFOX 72
13.4. IMPORTING CA CERTIFICATES IN FIREFOX 74
13.5. EDITING CERTIFICATE TRUST SETTINGS IN FIREFOX 75
13.6. IMPORTING PERSONAL CERTIFICATE FOR AUTHENTICATION IN FIREFOX 76
13.7. VIEWING CERTIFICATES IN THUNDERBIRD 77
13.8. IMPORTING CERTIFICATES IN THUNDERBIRD 79
13.9. EDITING CERTIFICATE TRUST SETTINGS IN THUNDERBIRD 80
13.10. IMPORTING PERSONAL CERTIFICATE IN THUNDERBIRD 81
2
Table of Contents
3
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
The word master is being replaced with more precise language, depending on the context:
4
PROVIDING FEEDBACK ON RED HAT DOCUMENTATION
4. Enter your suggestion for improvement in the Description field. Include links to the relevant
parts of the documentation.
5
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
You can configure identity information and authentication sources and providers by selecting one of the
ready-made profiles:
The default sssd profile enables the System Security Services Daemon (SSSD) for systems
that use LDAP authentication.
The winbind profile enables the Winbind utility for systems directly integrated with Microsoft
Active Directory.
The minimal profile serves only local users and groups directly from system files, which allows
administrators to remove network authentication services that are no longer needed.
After selecting an authselect profile for a given host, the profile is applied to every user logging into the
host.
Red Hat recommends using authselect in semi-centralized identity management environments, for
example if your organization utilizes LDAP or Winbind databases to authenticate users to use services in
your domain.
6
CHAPTER 1. CONFIGURING USER AUTHENTICATION USING AUTHSELECT
WARNING
Your host is part of Red Hat Enterprise Linux Identity Management (IdM).
Joining your host to an IdM domain with the ipa-client-install command
automatically configures SSSD authentication on your host.
Your host is part of Active Directory via SSSD. Calling the realm join
command to join your host to an Active Directory domain automatically
configures SSSD authentication on your host.
Red Hat recommends against changing the authselect profiles configured by ipa-
client-install or realm join. If you need to modify them, display the current settings
before making any modifications, so you can revert back to them if necessary:
$ authselect current
Profile ID: sssd
Enabled features:
- with-sudo
- with-mkhomedir
- with-smartcard
/etc/nsswitch.conf The GNU C Library and other applications use this Name Service
Switch (NSS) configuration file to determine the sources from which
to obtain name-service information in a range of categories, and in
what order. Each category of information is identified by a database
name.
7
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
The configuration files in the /etc/pam.d/ directory list the PAMs that
will perform authentication tasks required by a service, and the
appropriate behavior of the PAM-API in the event that individual
PAMs fail.
/etc/dconf/db/distro.d/* files This directory holds configuration profiles for the dconf utility, which
you can use to manage settings for the GNOME Desktop Graphical
User Interface (GUI).
The default sssd profile establishes SSSD as a source of information by creating sss entries in
/etc/nsswitch.conf:
This means that the system first looks to SSSD if information concerning one of those items is
requested:
Only if the requested information is not found in the sssd cache and on the server providing
authentication, or if sssd is not running, the system looks at the local files, that is /etc/*.
For example, if information is requested about a user ID, the user ID is first searched in the sssd cache. If
it is not found there, the /etc/passwd file is consulted. Analogically, if a user’s group affiliation is
requested, it is first searched in the sssd cache and only if not found there, the /etc/group file is
consulted.
8
CHAPTER 1. CONFIGURING USER AUTHENTICATION USING AUTHSELECT
In practice, the local files database is not normally consulted. The most important exception is the case
of the root user, which is never handled by sssd but by files.
Prerequisites
Procedure
Select the authselect profile that is appropriate for your authentication provider. For example,
for logging into the network of a company that uses LDAP, choose sssd.
(Optional) You can modify the default profile settings by adding the following options to
the authselect select sssd or authselect select winbind command, for example:
with-faillock
with-smartcard
with-fingerprint
To see the full list of available options, see Converting your scripts from authconfig to
authselect
NOTE
Make sure that the configuration files that are relevant for your profile are configured
properly before finishing the authselect select procedure. For example, if the sssd
daemon is not configured correctly and active, running authselect select results in only
local users being able to authenticate, using pam_unix.
Verification Steps
9
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
Additional Resources
You can modify any of the items in the /etc/authselect/user-nsswitch.conf file with the exception of:
passwd
group
netgroup
automount
services
Running authselect select profile_name afterwards will result in transferring permissible changes from
/etc/authselect/user-nsswitch.conf to the /etc/nsswitch.conf file. Unacceptable changes are
overwritten by the default profile configuration.
IMPORTANT
Procedure
10
CHAPTER 1. CONFIGURING USER AUTHENTICATION USING AUTHSELECT
# authselect apply-changes
Verification steps
Review the /etc/nsswitch.conf file to verify that the changes from /etc/authselect/user-
nsswitch.conf have been propagated there.
Additional Resources
This is particularly useful if Modifying a ready-made authselect profile is not enough for your needs.
When you deploy a custom profile, the profile is applied to every user logging into the given host.
Procedure
1. Create your custom profile by using the authselect create-profile command. For example, to
create a custom profile called user-profile based on the ready-made sssd profile but one in
which you can configure the items in the /etc/nsswitch.conf file yourself:
WARNING
Including the --symlink-pam option in the command means that PAM templates will be
symbolic links to the origin profile files instead of their copy; including the --symlink-meta
option means that meta files, such as README and REQUIREMENTS will be symbolic links to
the origin profile files instead of their copy. This ensures that all future updates to the PAM
templates and meta files in the original profile will be reflected in your custom profile, too.
3. Select the custom profile by running the authselect select command, and adding
11
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
3. Select the custom profile by running the authselect select command, and adding
custom/name_of_the_profile as a parameter. For example, to select the user-profile profile:
Selecting the user-profile profile for your machine means that if the sssd profile is
subsequently updated by Red Hat, you will benefit from all the updates with the exception of
updates made to the /etc/nsswitch.conf file.
The following procedure shows how to create a profile based on the sssd profile which only
consults the local static table lookup for hostnames in the /etc/hosts file, not in the dns or
myhostname databases.
hosts: files
hosts: files
NOTE
Additional Resources
12
CHAPTER 1. CONFIGURING USER AUTHENTICATION USING AUTHSELECT
/etc/krb5.conf
/etc/sssd/sssd.conf (for the sssd profile) or /etc/samba/smb.conf (for the winbind profile)
Relation of authconfig options to authselect profiles and Authselect profile option equivalents of
authconfig options show the authselect equivalents of authconfig options.
--enablekrb5 sssd
--enablesmartcard with-smartcard
--enablefingerprint with-fingerprint
--enableecryptfs with-ecryptfs
--enablemkhomedir with-mkhomedir
--enablefaillock with-faillock
--enablepamaccess with-pamaccess
--enablewinbindkrb5 with-krb5
13
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
14
CHAPTER 2. UNDERSTANDING SSSD AND ITS BENEFITS
For example:
An LDAP directory
A Kerberos realm
1. It connects the client to a remote provider to retrieve identity and authentication information.
2. It uses the obtained authentication information to create a local cache of users and credentials
on the client.
Users on the local system are then able to authenticate using the user accounts stored in the remote
provider.
SSSD does not create user accounts on the local system. However, SSSD can be configured to create
home directories for IdM users. Once created, an IdM user home directory and its contents on the client
are not deleted when the user logs out.
SSSD can also provide caches for several system services, such as Name Service Switch (NSS) or
Pluggable Authentication Modules (PAM).
Using the System Security Services Daemon (SSSD) provides multiple benefits regarding user identity
15
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
Using the System Security Services Daemon (SSSD) provides multiple benefits regarding user identity
retrieval and user authentication.
Offline authentication
SSSD optionally keeps a cache of user identities and credentials retrieved from remote providers. In
this setup, a user - provided they have already authenticated once against the remote provider at
the start of the session - can successfully authenticate to resources even if the remote provider or
the client are offline.
A single user account: improved consistency of the authentication process
With SSSD, it is not necessary to maintain both a central account and a local user account for offline
authentication. The conditions are:
In a particular session, the user must have logged in at least once: the client must be
connected to the remote provider when the user logs in for the first time.
With SSSD, thanks to caching and offline authentication, remote users can connect to
network resources simply by authenticating to their local machine. SSSD then maintains their
network credentials.
This combination allows you to use the default /etc/sssd/sssd.conf file on all clients and add additional
settings in further configuration files to extend the functionality individually on a per-client basis.
If the same parameter appears in multiple configuration files, SSSD uses the last read parameter.
NOTE
SSSD does not read hidden files (files starting with .) in the conf.d directory.
16
CHAPTER 2. UNDERSTANDING SSSD AND ITS BENEFITS
You can connect an SSSD client to the external identity and authentication providers, for example an
LDAP directory, an Identity Management (IdM), Active Directory (AD) domain, or a Kerberos realm. The
SSSD client then get access to identity and authentication remote services using the SSSD provider.
You can configure SSSD to use different identity and authentication providers or a combination of
them.
An identity provider, which supplies user information such as UID and GID.
Specify a domain as the identity provider by using the id_provider option in the
[domain/name of the domain] section of the /etc/sssd/sssd.conf file.
Specify a domain as the authentication provider by using the auth_provider option in the
[domain/name of the domain] section of /etc/sssd/sssd.conf.
Specify a domain as the access control provider using the access_provider option in the
[domain/name of the domain] section of /etc/sssd/sssd.conf. By default, the option is set
to permit, which always allows all access. See the sssd.conf(5) man page for details.
A combination of these providers, for example if all the corresponding operations are performed
within a single server.
In this case, the id_provider, auth_provider, and access_provider options are all listed in
the same [domain/name of the domain] or [domain/default] section of
/etc/sssd/sssd.conf.
NOTE
You can configure multiple domains for SSSD. You must configure at least one domain,
otherwise SSSD will not start.
Proxy Providers
A proxy provider works as an intermediary relay between SSSD and resources that SSSD would
otherwise not be able to use. When using a proxy provider, SSSD connects to the proxy service, and the
proxy loads the specified libraries.
A local system account defined in the /etc/passwd file as an identity provider and a remote
authentication provider, for example Kerberos
17
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
LDAP LDAP
LDAP Kerberos
Proxy Proxy
Proxy LDAP
Proxy Kerberos
Additional resources
[1] To list and verify the status of the domains using the sssctl utility, your host should be enrolled in Identity
Management (IdM) that is in a trust agreement with an Active Directory (AD) forest.
18
CHAPTER 3. ENABLING THE LOCAL FILES PROVIDER FOR SSSD
Prerequisites
You need root permissions to edit the /etc/sssd/sssd.conf configuration file and run
authselect commands.
Procedure
a. Enable the files provider by setting the option enable_files_domain=true in the sssd
section of the sssd.conf configuration file.
[sssd]
enable_files_domain = true
b. Explicitly configure a new local domain in the sssd.conf configuration file and specify the
option id_provider=files.
[domain/local]
id_provider=files
...
19
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
NOTE
Ensure that your setup operates in a trusted environment and decide if it is safe to use
unencrypted communication for id_provider = ldap. Note id_provider = ad and
id_provider = ipa are not affected as they use encrypted connections protected by
SASL and GSSAPI.
If it is not safe to use unencrypted communication, you should enforce TLS by setting the
ldap_id_use_start_tls option to true in the /etc/sssd/sssd.conf file.
IMPORTANT
Configuring SSSD with LDAP is a complex procedure requiring a high level of expertise in
SSSD and LDAP. Consider using an integrated and automated solution such as Active
Directory or Red Hat Identity Management (IdM) instead. For details about IdM, see
Planning Identity Management.
The RHEL system authenticates users stored in an OpenLDAP user account database.
The RHEL system uses the System Security Services Daemon (SSSD) service to retrieve user
data.
The RHEL system communicates with the OpenLDAP server over a TLS-encrypted connection.
NOTE
20
CHAPTER 4. CONFIGURING SSSD TO USE LDAP AND REQUIRE TLS AUTHENTICATION
NOTE
You can alternatively use this procedure to configure your RHEL system as a client of a
Red Hat Directory Server.
Prerequisites
You have root permissions on the host you are configuring as the LDAP client.
On the host you are configuring as the LDAP client, the /etc/sssd/sssd.conf file has been
created and configured to specify ldap as the autofs_provider and the id_provider.
You have a PEM-formatted copy of the root CA signing certificate chain from the Certificate
Authority that issued the OpenLDAP server certificate, stored in a local file named core-
dirsrv.ca.pem.
Procedure
3. Copy the core-dirsrv.ca.pem file containing the root CA signing certificate chain from the
Certificate Authority that issued the OpenLDAP server’s SSL/TLS certificate into the
/etc/openldap/certs folder.
# cp core-dirsrv.ca.pem /etc/openldap/certs
4. Add the URL and suffix of your LDAP server to the /etc/openldap/ldap.conf file:
URI ldap://ldap-server.example.com/
BASE dc=example,dc=com
6. In the /etc/sssd/sssd.conf file, add your environment values to the ldap_uri and
ldap_search_base parameters and set the ldap_id_use_start_tls to True:
[domain/default]
id_provider = ldap
autofs_provider = ldap
auth_provider = ldap
21
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
chpass_provider = ldap
ldap_uri = ldap://ldap-server.example.com/
ldap_search_base = dc=example,dc=com
ldap_id_use_start_tls = True
cache_credentials = True
ldap_tls_cacertdir = /etc/openldap/certs
ldap_tls_reqcert = allow
[sssd]
services = nss, pam, autofs
domains = default
[nss]
homedir_substring = /home
…
…
cache_credentials = True
ldap_tls_cacert = /etc/openldap/certs/core-dirsrv.ca.pem
ldap_tls_reqcert = hard
…
9. Restart and enable the SSSD service and the oddjobd daemon:
10. (Optional) If your LDAP server uses the deprecated TLS 1.0 or TLS 1.1 protocols, switch the
system-wide cryptographic policy on the client system to the LEGACY level to allow RHEL to
communicate using these protocols:
For more details, see the Strong crypto defaults in RHEL 8 and deprecation of weak crypto
algorithms Knowledgebase article on the Red Hat Customer Portal and the update-crypto-
policies(8) man page.
Verification steps
Verify you can retrieve user data from your LDAP server by using the id command and
specifying an LDAP user:
# id ldap_user
uid=17388(ldap_user) gid=45367(sysadmins)
groups=45367(sysadmins),25395(engineers),10(wheel),1202200000(admins)
The system administrator can now query users from LDAP using the id command. The command
22
CHAPTER 4. CONFIGURING SSSD TO USE LDAP AND REQUIRE TLS AUTHENTICATION
The system administrator can now query users from LDAP using the id command. The command
returns a correct user ID and group membership.
23
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
Adjust how SSSD interprets and prints full user names to enable offline authentication.
Configure DNS Service Discovery, simple Access Provider Rules, and SSSD to apply an LDAP
Access Filter.
(?P<name>[^@]+)@?(?P<domain>[^@]*$)
NOTE
For Identity Management and Active Directory providers, the default user name format is
user_name@domain_name or NetBIOS_name\user_name.
You can adjust how SSSD interprets full user names by adding the re_expression option to the
/etc/sssd/sssd.conf file and defining a custom regular expression.
To define the regular expression globally, add the regular expression to the [sssd] section of
the sssd.conf file as shown in the Defining regular expressions globally example.
To define the regular expression for a particular domain, add the regular expression to the
corresponding domain section (for example, [domain/LDAP]) of the sssd.conf file as shown in
the Defining regular expressions a particular domain example.
Prerequisites
root access
Procedure
To define the regular expressions globally for all domains, add re_expression to the [sssd]
section of the sssd.conf file.
You can use the following global expression to define the username in the format of
domain\\username or domain@username:
24
CHAPTER 5. ADDITIONAL CONFIGURATION FOR IDENTITY AND AUTHENTICATION PROVIDERS
[sssd]
[... file truncated ...]
re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)
To define the regular expressions individually for a particular domain, add re_expression to
the corresponding domain section of the sssd.conf file.
You can use the following global expression to define the username in the format of
domain\\username or domain@username for the LDAP domain:
[domain/LDAP]
[... file truncated ...]
re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)
For more details, see the descriptions for re_expression in the SPECIAL SECTIONS and DOMAIN
SECTIONS parts of the sssd.conf(5) man page.
%1$s@%2$s
NOTE
You can adjust the format in which SSSD prints full user names by adding the full_name_format option
to the /etc/sssd/sssd.conf file and defining a custom expansion.
Prerequisites
root access
Procedure
2. To define the expansion globally for all domains, add full_name_format to the [sssd] section of
sssd.conf.
[sssd]
[... file truncated ...]
full_name_format = %1$s@%2$s
25
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
3. To define the user name printing format for a particular domain, add full_name_format to the
corresponding domain section of sssd.conf.
To configure the expansion for the Active Directory (AD) domain using %2$s\%1$s:
[domain/ad.domain]
[... file truncated ...]
full_name_format = %2$s\%1$s
To configure the expansion for the Active Directory (AD) domain using %3$s\%1$s:
[domain/ad.domain]
[... file truncated ...]
full_name_format = %3$s\%1$s
In this case the user name is displayed as AD\user if the flat domain name of the Active
Directory domain is set to AD.
For more details, see the descriptions for full_name_format in the SPECIAL SECTIONS and DOMAIN
SECTIONS parts of the sssd.conf(5) man page.
NOTE
SSSD can strip the domain component of the name in some name configurations, which
can cause authentication errors. If you set full_name_format to a non-standard value,
you will get a warning prompting you to change it to a standard format.
To ensure that users can authenticate even when the identity provider is unavailable, you can enable
credential caching by setting cache_credentials to true in the /etc/sssd/sssd.conf file.
IMPORTANT
SSSD never caches passwords in plain text. It stores only a hash of the password.
While credentials are stored as a salted SHA-512 hash, this potentially poses a security risk
in case an attacker manages to access the cache file and break a password using a brute
force attack. Accessing a cache file requires privileged access, which is the default on
RHEL.
Prerequisites
root access
Procedure
26
CHAPTER 5. ADDITIONAL CONFIGURATION FOR IDENTITY AND AUTHENTICATION PROVIDERS
[domain/your-domain-name]
cache_credentials = true
3. Optional, but recommended: Configure a time limit for how long SSSD allows offline
authentication if the identity provider is unavailable:
For example, to specify that users are able to authenticate offline for 3 days since the last
successful login, use:
[pam]
offline_credentials_expiration = 3
Additional resources
For example, if sssd.conf includes the id_provider = ldap setting, but the ldap_uri option does not
specify any host name or IP address, SSSD uses DNS service discovery to discover the server
dynamically.
NOTE
SSSD cannot dynamically discover backup servers, only the primary server.
Prerequisites
root access
Procedure
[domain/your-domain-name]
id_provider = ldap
ldap_uri = _srv_
27
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
3. Enable service discovery in the password change provider by setting a service type:
[domain/your-domain-name]
id_provider = ldap
ldap_uri = _srv_
chpass_provider = ldap
ldap_chpass_dns_service_name = ldap
4. Optional: By default, the service discovery uses the domain portion of the system host name as
the domain name. To use a different DNS domain, specify the domain name by using the
dns_discovery_domain option.
5. Optional: By default, the service discovery scans for the LDAP service type. To use a different
service type, specify the type by using the ldap_dns_service_name option.
6. Optional: By default, SSSD attempts to look up an IPv4 address. If the attempt fails, SSSD
attempts to look up an IPv6 address. To customize this behavior, use the lookup_family_order
option.
7. For every service with which you want to use service discovery, add a DNS record to the DNS
server:
Additional resources
For example, you can use the simple access provider to restrict access to a specific user or group.
Other users or groups will not be allowed to log in even if they authenticate successfully against the
configured authentication provider.
Prerequisites
root access
Procedure
[domain/your-domain-name]
access_provider = simple
IMPORTANT
4. Define the access control rules for groups. Choose one of the following:
IMPORTANT
The following example allows access to user1, user2, and members of group1, while
denying access to all other users:
[domain/your-domain-name]
access_provider = simple
simple_allow_users = user1, user2
simple_allow_groups = group1
IMPORTANT
Keeping the deny list empty can lead to allowing access to everyone.
Additional resources
For example, when using the Active Directory (AD) server as the access provider, you can restrict access
to the Linux system only to specified AD users. All other users that do not match the specified filter
have access denied.
NOTE
29
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
NOTE
The access filter is applied on the LDAP user entry only. Therefore, using this type of
access control on nested groups might not work. To apply access control on nested
groups, see Configuring simple Access Provider Rules .
IMPORTANT
When using offline caching, SSSD checks if the user’s most recent online login attempt
was successful. Users who logged in successfully during the most recent online login will
still be able to log in offline, even if they do not match the access filter.
Prerequisites
root access
Procedure
For an LDAP access provider, use the ldap_access_filter option. See the sssd-ldap(5)
man page for details.
For an AD access provider, use the ad_access_filter option. See the sssd-ad(5) man page
for details.
Example 5.4. Allowing access to specific AD users
For example, to allow access only to AD users who belong to the admins user group and
have a unixHomeDirectory attribute set, use:
[domain/your-AD-domain-name]
access provider = ad
[... file truncated ...]
ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)
(unixHomeDirectory=*))
SSSD can also check results by the authorizedService or host attribute in an entry. In fact, all options
MDASH LDAP filter, authorizedService, and host MDASH can be evaluated, depending on the user
entry and the configuration. The ldap_access_order parameter lists all access control methods to use,
ordered as how they should be evaluated.
[domain/example.com]
access_provider = ldap
ldap_access_filter = memberOf=cn=allowedusers,ou=Groups,dc=example,dc=com
ldap_access_order = filter, host, authorized_service
Additional resources
30
CHAPTER 6. SSSD CLIENT-SIDE VIEW
If you are using the ipa provider, define ID views centrally in IPA. For more information, see Using an ID
view to override a user attribute value on an IdM client.
For information about a potential negative impact on the SSSD performance, see Potential negative
impact of ID views on SSSD performance.
Prerequisites
root access
Installed sssd-tools
Procedure
# id username
Replace username with the name of the user and replace secondary-username with the new
username.
3. After creating the first override using the sss_override user-add command, restart SSSD for
the changes to take effect:
Verification steps
# id secondary-username
31
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
# id sjones
uid=1001(sjones) gid=6003 groups=6003,10(wheel)
3. Verify that the new username has been added and overrides for the user display
correctly:
# id sarah
uid=1001(sjones) gid=6003(sjones) groups=6003(sjones),10(wheel)
Additional resources
Prerequisites
root access
Installed sssd-tools
Procedure
# id -u user-name
32
CHAPTER 6. SSSD CLIENT-SIDE VIEW
Replace user-name with the name of the user and replace new-UID with the new UID number.
# sss_cache --users
4. After creating the first override using the sss_override user-add command, restart SSSD for
the changes to take effect:
Verification steps
# id -u user-name
# id -u sarah
1001
2. Override the UID of the user sarah's account with UID 6666:
# sss_cache --users
5. Verify that the new UID is applied and overrides for the user display correctly:
# id sarah
6666
33
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
Additional resources
Prerequisites
root access
Installed sssd-tools
Procedure
# id -g user-name
Replace user-name with the name of the user and replace new-GID with the new GID number.
# sss_cache --users
4. After creating the first override using the sss_override user-add command, restart SSSD for
the changes to take effect:
Verification steps
# id -g user-name
34
CHAPTER 6. SSSD CLIENT-SIDE VIEW
# id -g sarah
6003
2. Override the GID of the user sarah's account with GID 6666:
# sss_cache --users
4. If this is your first override, restart SSSD for the changes to take effect:
5. Verify that the new GID is applied and overrides for the user display correctly:
# id -g sarah
6666
Additional resources
Prerequisites
root access
Installed sssd-tools
Procedure
35
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
Replace user-name with the name of the user and replace new-home-directory with the new
home directory.
Verification steps
2. Override the home directory of the user sarah with new home directory admin:
4. Verify that the new home directory is defined and overrides for the user display correctly:
36
CHAPTER 6. SSSD CLIENT-SIDE VIEW
Additional resources
Prerequisites
root access
Installed sssd-tools
Procedure
Replace user-name with the name of the user and replace new-shell with the new shell.
Verification steps
37
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
2. Override the shell of the user sarah with new /sbin/nologin shell:
4. Verify that the new shell is defined and overrides for the user display correctly:
Additional resources
Prerequisites
root access
Installed sssd-tools
Procedure
# sss_override user-find
user1@ldap.example.com::8000::::/bin/zsh:
user2@ldap.example.com::8001::::/bin/bash:
...
# sss_override group-find
group1@ldap.example.com::7000
group2@ldap.example.com::7001
...
38
CHAPTER 6. SSSD CLIENT-SIDE VIEW
Prerequisites
root access
Installed sssd-tools
Procedure
Replace user-name with the name of the user. The changes take effect immediately.
After removing the first override using the sss_override user-del or sss_override group-del
command, restart SSSD for the changes to take effect:
When you remove overrides for a user or group, all overrides for this object are removed.
Prerequisites
root access
Installed sssd-tools
Procedure
39
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
You do not want to grant AD administrators the control over enabling and disabling the host.
The host, which can be a corporate PC, is only meant to be used by one user in your company.
IMPORTANT
Implement this procedure only in the rare cases where this approach is preferred.
Consider fully joining the system to AD or Red Hat Identity Management (IdM) instead.
Joining the RHEL host to a domain makes the setup easier to manage. If you are
concerned about client access licences related to joining clients into AD directly, consider
leveraging an IdM server that is in a trust agreement with AD. For more information about
an IdM-AD trust, see Planning a cross-forest trust between IdM and AD and Installing a
trust between IdM and AD.
This procedure enables the user named AD_user to log in to the rhel_host system using the password
set in the Active Directory (AD) user database in the example.com domain. In this example, the
EXAMPLE.COM Kerberos realm corresponds to the example.com domain.
Prerequisites
rhel_host has not been joined to AD using the realm join command.
Procedure
1. Create the AD_user user account locally without assigning a password to it:
# useradd AD_user
2. Open the /etc/nsswitch.conf file for editing, and make sure that it contains the following lines:
3. Open the /etc/krb5.conf file for editing, and make sure that it contains the following sections
and items:
40
CHAPTER 7. CONFIGURING A RHEL HOST TO USE AD AS AN AUTHENTICATION PROVIDER
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
spake_preauth_groups = edwards25519
default_realm = EXAMPLE.COM
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
EXAMPLE.COM = {
kdc = ad.example.com
admin_server = ad.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
4. Create the /etc/sssd/sssd.conf file and insert the following sections and lines into it:
[sssd]
services = nss, pam
domains = EXAMPLE.COM
[domain/EXAMPLE.COM]
id_provider = files
auth_provider = krb5
krb5_realm = EXAMPLE.COM
krb5_server = ad.example.com
7. Enable SSSD:
8. Open the /etc/pam.d/system-auth file, and modify it so that it contains the following sections
41
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
8. Open the /etc/pam.d/system-auth file, and modify it so that it contains the following sections
and lines:
9. Copy the contents of the /etc/pam.d/system-auth file into the /etc/pam.d/password-auth file.
Enter yes to confirm the overwriting of the current contents of the file:
# cp /etc/pam.d/system-auth /etc/pam.d/password-auth
cp: overwrite '/etc/pam.d/password-auth'? yes
Verification steps
1. Request a Kerberos ticket-granting ticket (TGT) for AD_user. Enter the password of AD_user
as requested:
# kinit AD_user
Password for AD_user@EXAMPLE.COM:
# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: AD_user@EXAMPLE.COM
42
CHAPTER 7. CONFIGURING A RHEL HOST TO USE AD AS AN AUTHENTICATION PROVIDER
AD_user has successfully logged in to rhel_host using the credentials from the EXAMPLE.COM
Kerberos domain.
43
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
Prerequisites
domain state
manage logs
NOTE
Additional resources
sssctl --help
NOTE
The access report is not accurate because the tool does not track users locked out by the
Key Distribution Center (KDC).
Prerequisites
44
CHAPTER 8. REPORTING ON USER ACCESS ON HOSTS USING SSSD
Procedure
The sssctl user-checks [USER_NAME] command displays user data available through Name Service
Switch (NSS) and the InfoPipe responder for the D-Bus interface. The displayed data shows whether
the user is authorized to log in using the system-auth Pluggable Authentication Module (PAM) service.
If you do not define -a and -s options, the sssctl tool uses default options: -a acct -s system-auth.
Prerequisites
Procedure
Additional resources
45
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
NOTE
The status might not be available immediately. If the domain is not visible, repeat the
command.
Prerequisites
Procedure
The list includes domains in the cross-forest trust between Active Directory and Identity Management.
NOTE
The status might not be available immediately. If the domain is not visible, repeat the
command.
Prerequisites
46
CHAPTER 9. QUERYING DOMAIN INFORMATION USING SSSD
Procedure
Active servers:
IPA: server.idm.example.com
The domain idm.example.com is online and visible from the client where you applied the command.
47
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
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.
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.
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
48
CHAPTER 10. RESTRICTING DOMAINS FOR PAM SERVICES USING SSSD
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
Additional resources
For more details on the pam_trusted_users and pam_public_domains options, see the
sssd.conf(5) man page.
For more details on the domains option used in PAM configuration files, see the pam_sss(8)
man page.
Prerequisites
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 = domain1, domain2, domain3
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:
In this example, you allow the PAM service to authenticate against domain1 only.
Verification steps
49
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
Verification steps
50
CHAPTER 11. ELIMINATING TYPOGRAPHICAL ERRORS IN LOCAL SSSD CONFIGURATION
Prerequisites
Procedure
# sssctl config-check
2. Open the /etc/sssd/sssd.conf file and correct the typo. If you, for example, received the error
message in the previous step, replace ldap_search with ldap_search_base:
[...]
[domain/example1]
ldap_search_base = dc=example,dc=com
[...]
4. Restart SSSD:
Verification steps
# sssctl config-check
51
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
To authenticate users, you must be able to perform the following functions with the SSSD service:
Prompt the user for their credentials, pass those credentials to the authentication server, and
process the outcome.
To learn more about how information flows between the SSSD service and servers that store user
information, so you can troubleshoot failing authentication attempts in your environment, see the
following:
8. Gathering debugging logs from the SSSD service to troubleshoot authentication issues with an
IdM server
9. Gathering debugging logs from the SSSD service to troubleshoot authentication issues with an
52
CHAPTER 12. TROUBLESHOOTING AUTHENTICATION WITH SSSD IN IDM
9. Gathering debugging logs from the SSSD service to troubleshoot authentication issues with an
IdM client
1. The getent command triggers the getpwnam call from the libc library.
2. The libc library references the /etc/nsswitch.conf configuration file to check which service is
responsible for providing user information, and discovers the entry sss for the SSSD service.
4. The nss_sss module checks the memory-mapped cache for the user information. If the data is
present in the cache, the nss_sss module returns it.
5. If the user information is not in the memory-mapped cache, the request is passed to the SSSD
sssd_nss responder process.
6. The SSSD service checks its cache. If the data is present in the cache and valid, the sssd_nss
53
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
6. The SSSD service checks its cache. If the data is present in the cache and valid, the sssd_nss
responder reads the data from the cache and returns it to the application.
7. If the data is not present in the cache or it is expired, the sssd_nss responder queries the
appropriate back-end process and waits for a reply. The SSSD service uses the IPA backend in
an IdM environment, enabled by the setting id_provider=ipa in the sssd.conf configuration file.
8. The sssd_be back-end process connects to the IdM server and requests the information from
the IdM LDAP Directory Server.
9. The SSSD back-end on the IdM server responds to the SSSD back-end process on the IdM
client.
10. The SSSD back-end on the client stores the resulting data in the SSSD cache and alerts the
responder process that the cache has been updated.
11. The sssd_nss front-end responder process retrieves the information from the SSSD cache.
12. The sssd_nss responder sends the user information to the nss_sss responder, completing the
request.
13. The libc library returns the user information to the application that requested it.
The following diagram is a simplification of the information flow when a user requests information about
an AD user with the command getent passwd <ad_user_name@ad.example.com>. This diagram does
not include the internal details discussed in the Data flow when retrieving IdM user information with
SSSD section. It focuses on the communication between the SSSD service on an IdM client, the SSSD
service on an IdM server, and the LDAP database on an AD Domain Controller.
54
CHAPTER 12. TROUBLESHOOTING AUTHENTICATION WITH SSSD IN IDM
1. The IdM client looks to its local SSSD cache for AD user information.
2. If the IdM client does not have the user information, or the information is stale, the SSSD service
on the client contacts the extdom_extop plugin on the IdM server to perform an LDAP
extended operation and requests the information.
3. The SSSD service on the IdM server looks for the AD user information in its local cache.
4. If the IdM server does not have the user information in its SSSD cache, or its information is stale,
it performs an LDAP search to request the user information from an AD Domain Controller.
5. The SSSD service on the IdM server receives the AD user information from the AD domain
controller and stores it in its cache.
6. The extdom_extop plugin receives the information from the SSSD service on the IdM server,
which completes the LDAP extended operation.
7. The SSSD service on the IdM client receives the AD user information from the LDAP extended
operation.
8. The IdM client stores the AD user information in its SSSD cache and returns the information to
the application that requested it.
The service that initiates the authentication request, such as the sshd service.
55
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
IdM users are authenticated against an IdM Kerberos Key Distribution Center (KDC).
Active Directory (AD) users are authenticated against an AD Domain Controller (DC).
The following diagram is a simplification of the information flow when a user needs to authenticate
during an attempt to log in locally to a host via the SSH service on the command line.
1. The authentication attempt with the ssh command triggers the libpam library.
2. The libpam library references the PAM file in the /etc/pam.d/ directory that corresponds to the
service requesting the authentication attempt. In this example involving authenticating via the
SSH service on the local host, the libpam library checks the /etc/pam.d/system-auth
configuration file and discovers the pam_sss.so entry for the SSSD PAM:
56
CHAPTER 12. TROUBLESHOOTING AUTHENTICATION WITH SSSD IN IDM
3. To determine which authentication methods are available, the libpam library opens the
pam_sss module and sends an SSS_PAM_PREAUTH request to the sssd_pam PAM
responder of the SSSD service.
4. If smart card authentication is configured, the SSSD service spawns a temporary p11_child
process to check for a smart card and retrieve certificates from it.
5. If smart card authentication is configured for the user, the sssd_pam responder attempts to
match the certificate from the smart card with the user. The sssd_pam responder also
performs a search for the groups that the user belongs to, since group membership might
affect access control.
8. The krb5_child process contacts the KDC on the IdM server and checks for available
authentication methods.
a. The krb5_child process evaluates the reply and sends the results back to the sssd_be
backend process.
10. If password authentication is configured for the user, the pam_sss module prompts the user
for their password. If smart card authentication is configured, the pam_sss module prompts the
user for their smart card PIN.
11. The module sends an SSS_PAM_AUTHENTICATE request with the user name and password,
which travels to:
12. The sssd_be process spawns a temporary krb5_child process to contact the KDC.
13. The krb5_child process attempts to retrieve a Kerberos Ticket Granting Ticket (TGT) from the
KDC with the user name and password the user provided.
14. The krb5_child process receives the result of the authentication attempt.
57
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
16. The authentication result travels from the sssd_be process to:
17. The pam_sss module sets an environment variable with the location of the user’s TGT so other
applications can reference it.
Procedure
1. Verify that the SSSD service and its processes are running.
2. Verify that the client can contact the user database server via the IP address.
If this step fails, check that your network and firewall settings allow direct communication
between IdM clients and servers. See Using and configuring firewalld .
3. Verify that the client can discover and contact the IdM LDAP server (for IdM users) or AD
domain controller (for AD users) via the fully qualified host name.
If this step fails, check your Dynamic Name Service (DNS) settings, including the
/etc/resolv.conf file. See Configuring the order of DNS servers .
NOTE
58
CHAPTER 12. TROUBLESHOOTING AUTHENTICATION WITH SSSD IN IDM
NOTE
ipa_server = <fully_qualified_host_name_of_the_server>
ad_server = <fully_qualified_host_name_of_the_server>
ldap_uri = <fully_qualified_host_name_of_the_server>
If you use these options, verify you can contact the servers listed in them.
4. Verify that the client can authenticate to the LDAP server and retrieve user information with
ldapsearch commands.
a. If your LDAP server is an IdM server, like server.example.com, retrieve a Kerberos ticket for
the host and perform the database search authenticating with the host Kerberos principal:
b. If your LDAP server is an Active Directory (AD) Domain Controller (DC), like
server.ad.example.com, retrieve a Kerberos ticket for the host and perform the database
search authenticating with the host Kerberos principal:
c. If your LDAP server is a plain LDAP server, and you have set the ldap_default_bind_dn and
ldap_default_authtok options in the sssd.conf file, authenticate as the same
ldap_default_bind_dn account:
If this step fails, verify that your database settings allow your host to search the LDAP server.
5. Since the SSSD service uses Kerberos encryption, verify you can obtain a Kerberos ticket as the
user that is unable to log in.
If this step fails, verify that your Kerberos server is operating properly, all servers have their
59
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
If this step fails, verify that your Kerberos server is operating properly, all servers have their
times synchronized, and that the user account is not locked.
6. Verify you can retrieve user information about the command line.
If this step fails, verify that the SSSD service on the client can receive information from the user
database:
b. Enable detailed logging in the SSSD service, collect debugging logs, and review the logs for
indications to the source of the issue.
c. (Optional) Open a Red Hat Technical Support case and provide the troubleshooting
information you have gathered.
7. If you are allowed to run sudo on the host, use the sssctl utility to verify the user is allowed to
log in.
If this step fails, verify your authorization settings, such as your PAM configuration, IdM HBAC
rules, and IdM RBAC rules:
a. Ensure that the user’s UID is equal to or higher than UID_MIN, which is defined in the
/etc/login.defs file.
c. Enable detailed logging in the SSSD service, collect debugging logs, and review the logs for
indications to the source of the issue.
d. (Optional) Open a Red Hat Technical Support case and provide the troubleshooting
information you have gathered.
Additional resources
Gathering debugging logs from the SSSD service to troubleshoot authentication issues with an
IdM server
Gathering debugging logs from the SSSD service to troubleshoot authentication issues with an
IdM client
60
CHAPTER 12. TROUBLESHOOTING AUTHENTICATION WITH SSSD IN IDM
total 620
-rw-------. 1 root root 0 Mar 29 09:21 krb5_child.log
-rw-------. 1 root root 14324 Mar 29 09:50 ldap_child.log
-rw-------. 1 root root 212870 Mar 29 09:50 sssd_example.com.log
-rw-------. 1 root root 0 Mar 29 09:21 sssd_ifp.log
-rw-------. 1 root root 0 Mar 29 09:21 sssd_implicit_files.log
-rw-------. 1 root root 0 Mar 29 09:21 sssd.log
-rw-------. 1 root root 219873 Mar 29 10:03 sssd_nss.log
-rw-------. 1 root root 0 Mar 29 09:21 sssd_pac.log
-rw-------. 1 root root 13105 Mar 29 09:21 sssd_pam.log
-rw-------. 1 root root 9390 Mar 29 09:21 sssd_ssh.log
-rw-------. 1 root root 0 Mar 29 09:21 sssd_sudo.log
NOTE
selinux_child.log
Log file for the short-lived helper process that retrieves and sets SELinux information.
sssd.log
Log file for SSSD monitoring and communicating with its responder and backend processes.
sssd_ifp.log
Log file for the InfoPipe responder, which provides a public D-Bus interface accessible over the
system bus.
sssd_nss.log
Log file for the Name Services Switch (NSS) responder that retrieves user and group information.
sssd_pac.log
Log file for the Microsoft Privilege Attribute Certificate (PAC) responder, which collects the PAC
from AD Kerberos tickets and derives information about AD users from the PAC, which avoids
requesting it directly from AD.
sssd_pam.log
61
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
Level Description
4 Configuration settings.
5 Function data.
To enable detailed logging persistently across SSSD service restarts, add the option
debug_level=<integer> in each section of the /etc/sssd/sssd.conf configuration file, where the
<integer> value is a number between 0 and 9. Debug levels up to 3 log larger failures, and levels 8 and
higher provide a large number of detailed log messages. Level 6 is a good starting point for debugging
authentication issues.
62
CHAPTER 12. TROUBLESHOOTING AUTHENTICATION WITH SSSD IN IDM
Prerequisites
You need the root password to edit the sssd.conf configuration file and restart the SSSD
service.
Procedure
2. Add the debug_level option to every section of the file, and set the debug level to the
verbosity of your choice.
[domain/example.com]
debug_level = 6
id_provider = ipa
...
[sssd]
debug_level = 6
services = nss, pam, ifp, ssh, sudo
domains = example.com
[nss]
debug_level = 6
[pam]
debug_level = 6
[sudo]
debug_level = 6
[ssh]
debug_level = 6
[pac]
debug_level = 6
[ifp]
debug_level = 6
Additional resources
By default, the SSSD service only logs serious failures (debug level 2), but it does not log at the level of
63
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
By default, the SSSD service only logs serious failures (debug level 2), but it does not log at the level of
detail necessary to troubleshoot authentication issues.
You can change the debug level of the SSSD service on the command line with the sssctl debug-level
<integer> command, where the <integer> value is a number between 0 and 9. Debug levels up to 3 log
larger failures, and levels 8 and higher provide a large number of detailed log messages. Level 6 is a
good starting point for debugging authentication issues.
Prerequisites
Procedure
Use the sssctl debug-level command to set the debug level of your choiceto your desired
verbosity.
Additional resources
Prerequisites
You need the root password to run the sssctl command and restart the SSSD service.
Procedure
2. Invalidate objects in the SSSD cache for the user that is experiencing authentication issues, so
you do not bypass the LDAP server and retrieve information SSSD has already cached.
64
CHAPTER 12. TROUBLESHOOTING AUTHENTICATION WITH SSSD IN IDM
5. (Optional) Lower the debug level if you do not wish to continue gathering detailed SSSD logs.
6. Review SSSD logs for information about the failed request. For example, reviewing the
/var/log/sssd/sssd_example.com.log file shows that the SSSD service did not find the user in
the cn=accounts,dc=example,dc=com LDAP subtree. This might indicate that the user does
not exist, or exists in another location.
ii. The console output, including the time stamps and user name, of the request that
corresponds to the logs:
65
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
If you experience issues when attempting to authenticate as an IdM user to an IdM client, verify that you
can retrieve user information about the IdM server. If you cannot retrieve the user information about an
IdM server, you will not be able to retrieve it on an IdM client (which retrieves information from the IdM
server).
After you have confirmed that authentication issues do not originate from the IdM server, gather SSSD
debugging logs from both the IdM server and IdM client.
Prerequisites
The user only has authentication issues on IdM clients, not IdM servers.
You need the root password to run the sssctl command and restart the SSSD service.
Procedure
2. On the client: Add the ipa_server option to the [domain] section of the file and set it to an IdM
server. This avoids the IdM client autodiscovering other IdM servers, thus limiting this test to just
one client and one server.
[domain/example.com]
ipa_server = server.example.com
...
4. On the client: Restart the SSSD service to load the configuration changes.
6. On the server and client:Invalidate objects in the SSSD cache for the user experiencing
authentication issues, so you do not bypass the LDAP database and retrieve information SSSD
has already cached.
7. On the server and client:Minimize the troubleshooting dataset by removing older SSSD logs.
8. On the client: Attempt to switch to the user experiencing authentication problems while
66
CHAPTER 12. TROUBLESHOOTING AUTHENTICATION WITH SSSD IN IDM
8. On the client: Attempt to switch to the user experiencing authentication problems while
gathering timestamps before and after the attempt. These timestamps further narrow the
scope of the dataset.
9. (Optional) On the server and client:Lower the debug level if you do not wish to continue
gathering detailed SSSD logs.
10. On the server and client:Review SSSD logs for information about the failed request.
d. Review the outcome of the client receiving the results of the request from the server.
11. If you are unable to determine the cause of the authentication issue:
a. Collect the SSSD logs you recently generated on the IdM server and IdM client. Label them
according to their hostname or role.
ii. The console output, including the time stamps and user name, of the request that
corresponds to the logs:
67
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
same log file, you can use the unique request identifier and client ID to track client requests in the back-
end logs. The unique request identifier is added to the debug logs in the form of RID#<integer> and the
client ID in the form [CID #<integer]. This allows you to isolate logs pertaining to an individual request,
and you can track requests from start to finish across log files from multiple SSSD components.
Prerequisites
You have enabled debug logging and a request has been submitted from an IdM client.
You must have root privileges to display the contents of the SSSD log files.
Procedure
1. To review your SSSD log file, open the log file using the less utility. For example, to view the
/var/log/sssd/sssd_example.com.log:
2. Review the SSSD logs for information about the client request.
This sample output from an SSSD log file shows the unique identifiers RID#3 and RID#4 for two
different requests.
However, a single client request to the SSSD client interface often triggers multiple requests in the
backend and as a result it is not a 1-to-1 correlation between client request and requests in the backend.
Though the multiple requests in the backend have different RID numbers, each initial backend request
includes the unique client ID so an administrator can track the multiple RID numbers to the single client
request.
The following example shows one client request [sssd.nss CID #1] and the multiple requests generated
in the backend, [RID#5] to [RID#13]:
68
CHAPTER 12. TROUBLESHOOTING AUTHENTICATION WITH SSSD IN IDM
The log analyzer tool helps you to troubleshoot NSS and PAM issues in SSSD and more easily review
SSSD debug logs. You can extract and print SSSD logs related only to certain client requests across
SSSD processes.
SSSD tracks user and group identity information (id, getent) separately from user authentication ( su,
ssh) information. The client ID (CID) in the NSS responder is independent of the CID in the PAM
responder and you see overlapping numbers when analyzing NSS and PAM requests. Use the --pam
option with the sssctl analyze command to review PAM requests.
NOTE
Requests returned from the SSSD memory cache are not logged and cannot be tracked
by the log analyzer tool.
Additional resources
Prerequisites
You must set debug_level to at least 7 in the [$responder] section, and [domain/$domain]
section of the /etc/sssd/sssd.conf file to enable log parsing functionality.
Logs to analyze must be from a compatible version of SSSD built with libtevent chain ID
support, that is SSSD in RHEL 8.5 and later.
Procedure
1. Run the log analyzer tool in list mode to determine the client ID of the request you are tracking,
69
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
1. Run the log analyzer tool in list mode to determine the client ID of the request you are tracking,
adding the -v option to display verbose output:
NOTE
If analyzing PAM requests, run the sssctl analyze request list command with
the --pam option.
2. Run the log analyzer tool with the show [unique client ID] option to display logs pertaining to
the specified client ID number:
3. If required, you can run the log analyzer tool against log files, for example:
Additional resources
70
CHAPTER 13. CONFIGURING APPLICATIONS FOR A SINGLE SIGN-ON
The configuration of different applications may vary. This chapter shows how to configure SSO
authentication schema for the Mozilla Thunderbird email client and Mozilla Firefox web browser as the
examples.
13.1. PREREQUISITES
You have installed the following applications:
NOTE
Even after Firefox is configured to pass Kerberos credentials, it still requires a valid
Kerberos ticket to use. To generate a Kerberos ticket, use the kinit command and supply
the user password for the user on the KDC.
[jsmith@host ~] $ kinit
Password for jsmith@EXAMPLE.COM:
Procedure
1. In the address bar of Firefox, type about:config to display the list of current configuration
options.
4. Enter the name of the domain against which to authenticate, including the preceding period (.).
If you want to add multiple domains, enter them in a comma separated list.
Additional resources
For information about configuring Firefox to use Kerberos in Identity Management, see the
corresponding section in the Linux Domain Identity, Authentication, and Policy Guide.
Procedure
72
CHAPTER 13. CONFIGURING APPLICATIONS FOR A SINGLE SIGN-ON
73
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
Prerequisites
To import a CA certificate:
74
CHAPTER 13. CONFIGURING APPLICATIONS FOR A SINGLE SIGN-ON
Procedure
Prerequisites
Procedure
2. Under the Authorities tab, select the appropriate certificate and click Edit Trust.
Prerequisites
Procedure
Procedure
Prerequisites
79
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
To import a CA certificate:
Procedure
Prerequisites
Procedure
2. Under the Authorities tab, select the appropriate certificate and click Edit Trust.
Prerequisites
Procedure
6. Select End-To-End Encryption in the left panel under your account email address.
Selecting end-to-end encryption section.
83
Red Hat Enterprise Linux 9 Configuring authentication and authorization in RHEL
7. Under S/MIME section click the first Select button to choose your personal certificate to use for
signing messages.
8. Under S/MIME section click the second Select button to choose your personal certificate to
encrypt and decrypt messages.
Choosing certificate for signing and encryption/decryption.
NOTE
In case you forgot to import valid certificate, you can open Certificate Manager directly
using the Manage S/MIME certificates.
84