13.2.31. Troubleshooting SSSD
Setting Debug Logs for SSSD Domains
debug_levelparameter for each section in the
sssd.conffile for which to produce extra logs. For example:
[domain/LDAP] cache_credentials = true
debug_level = 9
Table 13.13. Debug Log Levels
|0||Fatal failures. Anything that would prevent SSSD from starting up or causes it to cease running.|
|1||Critical failures. An error that doesn't kill the SSSD, but one that indicates that at least one major feature is not going to work properly.|
|2||Serious failures. An error announcing that a particular request or operation has failed.|
|3||Minor failures. These are the errors that would percolate down to cause the operation failure of 2.|
|6||Trace messages for operation functions.|
|7||Trace messages for internal control functions.|
|8||Contents of function-internal variables that may be interesting.|
|9||Extremely low-level tracing information.|
[sssd]section. Now, each domain and service must configure its own debug log level.
python -m SSSDConfig.sssd_update_debug_levels.py
Checking SSSD Log Files
/var/log/sssd/directory. SSSD produces a log file for each domain, as well as an
/var/log/securefile logs authentication failures and the reason for the failure.
Problems with SSSD Configuration
- Q: SSSD fails to start
- Q: I don't see any groups with 'id' or group members with 'getent group'.
- Q: Authentication fails against LDAP.
- Q: Connecting to LDAP servers on non-standard ports fail.
- Q: NSS fails to return user information
- Q: NSS returns incorrect user information
- Q: Setting the password for the local SSSD user prompts twice for the password
- Q: I am trying to use sudo rules with an Identity Management (IPA) provider, but no sudo rules are being found, even though sudo is properly configured.
- Q: Password lookups on large directories can take several seconds per request. How can this be improved?
- Q: An Active Directory identity provider is properly configured in my sssd.conf file, but SSSD fails to connect to it, with GSS-API errors.
- Q: I configured SSSD for central authentication, but now several of my applications (such as Firefox or Adobe) will not start.
- Q: SSSD is showing an automount location that I removed.
- SSSD requires at least one properly configured domain before the service will start. Without a domain, attempting to start SSSD returns an error that no domains are configured:
# 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.Edit the
/etc/sssd/sssd.conffile and create at least one domain.
- SSSD also requires at least one available service provider before it will start. If the problem is with the service provider configuration, the error message indicates that there are no services configured:
[sssd] [get_monitor_config] (0): No services configured!Edit the
/etc/sssd/sssd.conffile and configure at least one service provider.
ImportantSSSD requires that service providers be configured as a comma-separated list in a single
servicesentry in the
/etc/sssd/sssd.conffile. If services are listed in multiple entries, only the last entry is recognized by SSSD.
ldap_schemasetting in the
memberuidattribute, which contains the name of the users that are members. In an RFC2307bis server, group members are stored as the multi-valued
uniqueMemberattribute which contains the DN of the user or group that is a member of this group. RFC2307bis allows nested groups to be maintained as well.
- Restarting SSSD.
ldap_group_name = uniqueMember
sssd.confis configured to connect over a standard protocol (
ldap://), it attempts to encrypt the communication channel with Start TLS. If
sssd.confis configured to connect over a secure protocol (
ldaps://), then SSSD uses SSL.
syslogmessage is written, indicating that TLS encryption could not be started. The certificate configuration can be tested by checking if the LDAP server is accessible apart from SSSD. For example, this tests an anonymous bind over a TLS connection to
$ ldapsearch -x -ZZ -h test.example.com -b dc=example,dc=com
ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Unknown code ___f 13
- Obtain a copy of the public CA certificate for the certificate authority used to sign the LDAP server certificate and save it to the local system.
- Add a line to the
sssd.conffile that points to the CA certificate on the filesystem.
ldap_tls_cacert = /path/to/cacert
- If the LDAP server uses a self-signed certificate, remove the
ldap_tls_reqcertline from the
sssd.conffile.This parameter directs SSSD to trust any certificate issued by the CA certificate, which is a security risk with a self-signed CA certificate.
# semanage port -a -t ldap_port_t -p tcp 1389
- Ensure that NSS is running:
# service sssd status
- If NSS is running, make sure that the provider is properly configured in the
[nss]section of the
/etc/sssd/sssd.conffile. Especially check the
- Make sure that NSS is included in the list of services that SSSD uses.
- Check the configuration in the
/etc/sssd/sssd.conffile. This differentiates between different users in different domains with the same name.
[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.
use_authtokoption is correctly configured in your
(Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [sdap_sudo_load_sudoers_process] (0x0400): Receiving sudo rules with base [ou=sudoers,dc=ipa,dc=test]
(Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [sdap_sudo_load_sudoers_done] (0x0400): Received 0 rules(Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [sdap_sudo_purge_sudoers] (0x0400): Purging SUDOers cache of user's [admin] rules (Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [sysdb_sudo_purge_byfilter] (0x0400): No rules matched (Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [sysdb_sudo_purge_bysudouser] (0x0400): No rules matched (Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [sdap_sudo_load_sudoers_done] (0x0400): Sudoers is successfuly stored in cache (Thu Jun 21 10:37:47 2012) [sssd[be[ipa.test]]] [be_sudo_handler_reply] (0x0200): SUDO Backend returned: (0, 0, Success)
sssd.conf. For example:
[domain/ipa.example.com] id_provider = ipa ipa_server = ipa.example.com ldap_tls_cacert = /etc/ipa/ca.crt sudo_provider = ldap ldap_uri = ldap://ipa.example.com ldap_sudo_search_base = ou=sudoers,dc=ipa,dc=example,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/hostname.ipa.example.com ldap_sasl_realm = IPA.EXAMPLE.COM krb5_server = ipa.example.com
sssd.conffile, but SSSD fails to connect to it, with GSS-API errors.
[domain/ADEXAMPLE] debug_level = 0xFFF0 id_provider = ad
ad_server = 255.255.255.255ad_domain = example.com krb5_canonicalize = False
(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot determine realm for numeric host address)]
ad_serverto the name of the Active Directory host.
Failed to contact configuration server. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: IOR file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd located: Permission denied 2: IOR file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd located: Permission denied)
~]$ acroread (acroread:12739): GLib-WARNING **: getpwuid_r(): failed due to unknown user id (366)