8.2.7. Troubleshooting

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.

Producing More Verbose 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.
  Important
  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.

NSS fails to return user information
- Ensure that NSS is running
  # service sssd status
  This command should return results similar to the following:
```
sssd (pid 21762) is running...
```
- Ensure that you have correctly configured the [nss] section of the /etc/sssd/sssd.conf file. For example, ensure that you have not misconfigured the filter_users or filter_groups attributes. Refer to the NSS configuration options section of the sssd.conf(5) manual page for information on how to configure these attributes.
- Ensure that you have included nss in the list of services that sssd should start
- Ensure that you have correctly configured the /etc/nsswitch.conf file. Refer to the section Section 8.2.3.2.1, “Configuring NSS” for information on how to correctly configure this file.

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.

Note

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

8.2.7.5.1. Manual Pages

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:

sssd.conf(5)
sssd-ipa(5)
sssd-krb5(5)
sssd-ldap(5)
sssd(8)
sssd_krb5_locator_plugin(8)
pam_sss(8)

You should refer to these manual pages for detailed information about all aspects of SSSD, its configuration, and associated tools and commands.

8.2.7.5.2. Mailing Lists

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.

Visit https://fedorahosted.org/mailman/listinfo/sssd-devel to subscribe to this mailing list.