|
 |
|
| |
|
|
Red Hat Enterprise Linux 9 Essentials Book now available.
Purchase a copy of Red Hat Enterprise Linux 9 (RHEL 9) Essentials Red Hat Enterprise Linux 9 Essentials Print and eBook (PDF) editions contain 34 chapters and 298 pages
|
This section lists some of the issues you may encounter when implementing SSSD, the possible causes of these issues, and how to resolve them. If you find further issues that are not covered here, refer to the We Need Feedback section in the Preface for information on how to file a bug report.
8.2.7.1. Using SSSD Log Files
SSSD uses a number of log files to report information about its operation, and this information can help to resolve issues in the event of SSSD failure or unexpected behavior. The default location for these log files on Red Hat Enterprise Linux—based systems is the /var/log/sssd/ directory.
SSSD produces a log file for each back end (that is, one log file for each domain specified in the /etc/sssd/sssd.conf file), as well as an sssd_pam.log and an sssd_nss.log file. This level of granularity can help you to quickly isolate and resolve any errors or issues you might experience with SSSD.
You should also examine the /var/log/secure file, which logs authentication failures and the reason for the failure. For example, if you see Reason 4: System Error reported against any failure, you should increase the debug level of the log files.
If you are unable to identify and resolve any problems with SSSD after inspection of the default log files, you can configure SSSD to produce more verbose files. You can set the debug_level option in the /etc/sssd/sssd.conf for the domain that is causing concern, and then restart SSSD. Refer to the sssd.conf(5) manual page for more information on how to set the debug_level for a specific domain.
All log files include timestamps on debug messages by default. This can make it easier to understand any errors that may occur, why they occurred, and how to address them. If necessary, you can disable these timestamps by setting the appropriate parameter to FALSE in the /etc/sssd/sssd.conf file:
--debug-timestamps=FALSE
8.2.7.2. Problems with SSSD Configuration
-
SSSD fails to start
-
SSSD requires at least one properly configured domain before the service will start. Without such a domain, you might see the following error message when trying to start SSSD with the following command:
# sssd -d4
[sssd] [ldb] (3): server_sort:Unable to register control with rootdse!
[sssd] [confdb_get_domains] (0): No domains configured, fatal error!
[sssd] [get_monitor_config] (0): No domains configured.
You can ignore the "Unable to register control with rootdse!" message, as it is erroneous. The other messages, however, indicate that SSSD is unable to locate any properly configured domains.
Edit your /etc/sssd/sssd.conf file and ensure you have at least one properly configured domain, and then try to start SSSD.
-
SSSD requires at least one available service provider before it will start. With no available service providers, you might see the following error message when trying to start SSSD with the following command:
# sssd -d4
[sssd] [ldb] (3): server_sort:Unable to register control with rootdse!
[sssd] [get_monitor_config] (0): No services configured!
You can ignore the "Unable to register control with rootdse!" message, as it is erroneous. The other message, however, indicates that SSSD is unable to locate any available service providers.
Edit your /etc/sssd/sssd.conf file and ensure you have at least one available service providers, and then try to start SSSD.
SSSD requires that service providers be configured as a comma-separated list in a single services entry in the /etc/sssd/sssd.conf file. If services are listed in multiple entries, only the last entry is recognized by SSSD.
-
Refer to the sssd.conf(5) manual page for more options that might assist in troubleshooting issues with SSSD.
8.2.7.3. Problems with SSSD Service Configuration
8.2.7.3.1. Problems with NSS
This section describes some common problems with NSS, their symptoms, and how to resolve them.
8.2.7.3.2. Problems with PAM
This section describes some common problems with PAM, their symptoms, and how to resolve them.
-
Setting the password for the local SSSD user prompts twice for the password
When attempting to change a local SSSD user's password, you might see output similar to the following:
[root@clientF11 tmp]# passwd user1000
Changing password for user user1000.
New password:
Retype new password:
New Password:
Reenter new Password:
passwd: all authentication tokens updated successfully.
This is the result of an incorrect PAM configuration. Refer to Section 8.2.3.2.2, “Configuring PAM”, and ensure that the use_authtok option is correctly configured in your /etc/pam.d/system-auth file.
8.2.7.3.3. Problems with NFS and NSCD
SSSD is not designed to be used with the nscd daemon, and will likely generate warnings in the SSSD log files. Even though SSSD does not directly conflict with nscd, the use of both at the same time can result in unexpected behavior (specifically with how long entries are being cached).
If you are using Network Manager to manage your network connections, it may take several minutes for the network interface to come up. During this time, various services will attempt to start. If these services start before the network is up (that is, the DNS servers cannot yet be reached) they will fail to identify the forward or reverse DNS entries they might need. These services will be reading an incorrect or possibly empty resolv.conf file. This file is typically only read once, and so any changes made to this file are not automatically applied.
This can result in the failure of some system services, and in particular can cause NFS locking to fail on the machine where the nscd service is running, unless that service is manually restarted.
One method of working around this problem is to enable caching for hosts and services in the /etc/nscd.conf file, and to rely on the SSSD cache for the passwd and group entries. With nscd answering hosts and services requests, these entries would have been cached and returned by nscd during the boot process.
Later versions of SSSD should negate any need for NSCD.
8.2.7.4. Problems with SSSD Domain Configuration
-
NSS returns incorrect user information
-
If your search for user information returns incorrect data, ensure that you do not have conflicting usernames in separate domains. If you use multiple domains, it is recommended that you set the use_fully_qualified_domains attribute to TRUE in the /etc/sssd/sssd.conf file.
8.2.7.5. Additional Resources
SSSD ships with a number of manual pages, all of which provide additional information about specific aspects of SSSD, such as configuration files, commands, and available options. SSSD currently provides the following manual pages:
You should refer to these manual pages for detailed information about all aspects of SSSD, its configuration, and associated tools and commands.
You can subscribe to the SSSD mailing list to follow and become involved in the development of SSSD, or to ask questions about any issues you may be experiencing with your SSSD deployment.
|
|
|
