Este contenido no está disponible en el idioma seleccionado.
13.2.31. Troubleshooting SSSD
Setting Debug Logs for SSSD Domains
Each domain sets its own debug log level. Increasing the log level can provide more information about problems with SSSD or with the domain configuration.
To change the log level, set the
debug_level parameter for each section in the sssd.conf file for which to produce extra logs. For example:
[domain/LDAP]
cache_credentials = true
debug_level = 9| Level | Description |
|---|---|
| 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. |
| 4 | Configuration settings. |
| 5 | Function data. |
| 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. |
Note
In versions of SSSD older than 1.8, debug log levels could be set globally in the
[sssd] section. Now, each domain and service must configure its own debug log level.
To copy the global SSSD debug log levels into each configuration area in the SSSD configuration file, use the
sssd_update_debug_levels.py script.
python -m SSSDConfig.sssd_update_debug_levels.py
Checking SSSD Log Files
SSSD uses a number of log files to report information about its operation, located in the
/var/log/sssd/ directory. SSSD produces a log file for each domain, as well as an sssd_pam.log and an sssd_nss.log file.
Additionally, the
/var/log/secure file 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.
Q:
SSSD fails to start
A:
SSSD requires that the configuration file be properly set up, with all the required entries, before the daemon will start.
- 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.Important
SSSD requires that service providers be configured as a comma-separated list in a singleservicesentry in the/etc/sssd/sssd.conffile. If services are listed in multiple entries, only the last entry is recognized by SSSD.
Q:
I don't see any groups with 'id' or group members with 'getent group'.
A:
This may be due to an incorrect
ldap_schema setting in the [domain/DOMAINNAME] section of sssd.conf.
SSSD supports RFC 2307 and RFC 2307bis schema types. By default, SSSD uses the more common RFC 2307 schema.
The difference between RFC 2307 and RFC 2307bis is the way which group membership is stored in the LDAP server. In an RFC 2307 server, group members are stored as the multi-valued
memberuid attribute, which contains the name of the users that are members. In an RFC2307bis server, group members are stored as the multi-valued member or uniqueMember attribute 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.
If group lookups are not returning any information:
- Set
ldap_schematorfc2307bis. - Delete
/var/lib/sss/db/cache_DOMAINNAME.ldb. - Restarting SSSD.
If that doesn't work, add this line to
sssd.conf:
ldap_group_name = uniqueMember
Then delete the cache and restart SSSD again.
Q:
Authentication fails against LDAP.
A:
To perform authentication, SSSD requires that the communication channel be encrypted. This means that if
sssd.conf is configured to connect over a standard protocol (ldap://), it attempts to encrypt the communication channel with Start TLS. If sssd.conf is configured to connect over a secure protocol (ldaps://), then SSSD uses SSL.
This means that the LDAP server must be configured to run in SSL or TLS. TLS must be enabled for the standard LDAP port (389) or SSL enabled on the secure LDAPS port (636). With either SSL or TLS, the LDAP server must also be configured with a valid certificate trust.
An invalid certificate trust is one of the most common issues with authenticating against LDAP. If the client does not have proper trust of the LDAP server certificate, it is unable to validate the connection, and SSSD refuses to send the password. The LDAP protocol requires that the password be sent in plaintext to the LDAP server. Sending the password in plaintext over an unencrypted connection is a security problem.
If the certificate is not trusted, a
syslog message 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 test.example.com:
$ ldapsearch -x -ZZ -h test.example.com -b dc=example,dc=com
If the certificate trust is not properly configured, the test fails with this error:
ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Unknown code ___f 13
To trust the certificate:
- 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 thesssd.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.
Q:
Connecting to LDAP servers on non-standard ports fail.
A:
When running SELinux in enforcing mode, the client's SELinux policy has to be modified to connect to the LDAP server over the non-standard port. For example:
# semanage port -a -t ldap_port_t -p tcp 1389
Q:
NSS fails to return user information
A:
This usually means that SSSD cannot connect to the NSS service.
- 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 thefilter_usersandfilter_groupsattributes. - Make sure that NSS is included in the list of services that SSSD uses.
- Check the configuration in the
/etc/nsswitch.conffile.
Q:
NSS returns incorrect user information
A:
If searches are returning the incorrect user information, check that there are not conflicting user names in separate domains. When there are multiple domains, set the
use_fully_qualified_domains attribute to true in the /etc/sssd/sssd.conf file. This differentiates between different users in different domains with the same name.
Q:
Setting the password for the local SSSD user prompts twice for the password
A:
When attempting to change a local SSSD user's password, it may prompt for the password twice:
[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. Ensure that the
use_authtok option is correctly configured in your /etc/pam.d/system-auth file.
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.
A:
The SSSD client can successfully authenticate to the Identity Management server, and it is properly searching the LDAP directory for sudo rules. However, it is showing that no rules exist. For example, in the logs:
(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)
When using an Identity Management provider for SSSD, SSSD attempts to connect to the underlying LDAP directory using Kerberos/GSS-API. However, by default, SSSD uses an anonymous connection to an LDAP server to retrieve sudo rules. This means that SSSD cannot retrieve the sudo rules from the Identity Management server with its default configuration.
To support retrieving sudo rules with a Kerberos/GSS-API connection, enable GSS-API as the authentication mechanism in the identity provider configuration in
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
Q:
Password lookups on large directories can take several seconds per request. How can this be improved?
A:
The initial user lookup is a call to the LDAP server. Unindexed searches are much more resource-intensive, and therefore take longer, than indexed searches because the server checks every entry in the directory for a match. To speed up user lookups, index the attributes that are searched for by SSSD:
- uid
- uidNumber
- gidNumber
- gecos
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.
A:
SSSD can only connect with an Active Directory provider using its host name. If the host name is not given, the SSSD client cannot resolve the IP address to the host, and authentication fails.
For example, with this configuration:
[domain/ADEXAMPLE]
debug_level = 0xFFF0
id_provider = ad
ad_server = 255.255.255.255
ad_domain = example.com
krb5_canonicalize = False
The SSSD client returns this GSS-API failure, and the authentication request fails:
(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)]
To avoid this error, set the
ad_server to the name of the Active Directory host.
Q:
I configured SSSD for central authentication, but now several of my applications (such as Firefox or Adobe) will not start.
A:
Even on 64-bit systems, 32-bit applications require a 32-bit version of SSSD to use to access the password and identity cache. If a 32-bit version of SSSD is not available, but the system is configured to use the SSSD cache, then 32-bit applications can fail to start.
For example, Firefox can fail with permission denied errors:
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)
For Adobe Reader, the error shows that the current system user is not recognized:
~]$ acroread (acroread:12739): GLib-WARNING **: getpwuid_r(): failed due to unknown user id (366)
Other applications may show similar user or permissions errors.
Q:
SSSD is showing an automount location that I removed.
A:
The SSSD cache for the automount location persists even if the location is subsequently changed or removed. To update the autofs information in SSSD:
- Remove the autofs cache, as described in the section called “Purging the SSSD Cache”.
- Restart SSSD, as in Section 13.2.3, “Starting and Stopping SSSD”.
