From Fedora Project Wiki

mNo edit summary
m (Update SSSD project's link)
 
Line 1: Line 1:
{{draft}}
{{draft}}


This page provides a few steps to self-diagnose problems encountered when using SSSD.  For additional information on using SSSD, see https://fedorahosted.org/sssd.
This page provides a few steps to self-diagnose problems encountered when using SSSD.  For additional information on using SSSD, see https://sssd.io.


# Using the {{command|ping}} command, confirm you can you can contact the servers used when configuring SSSD.
# Using the {{command|ping}} command, confirm you can you can contact the servers used when configuring SSSD.

Latest revision as of 20:43, 31 August 2024

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

This page provides a few steps to self-diagnose problems encountered when using SSSD. For additional information on using SSSD, see https://sssd.io.

  1. Using the ping command, confirm you can you can contact the servers used when configuring SSSD.
  2. Inspect the system logs /var/log/secure and /var/log/messages for suspicious log messages
  3. If using TLS, verify that ...
    1. The directory /etc/openldap/cacerts contains the certificate
    2. The directory /etc/openldap/cacerts contains a hash symlink to the certificate
  4. Enable SSSD debugging output
    1. Setting debug_level = 5 in /etc/sssd/sssd.conf.
    2. Next, restart SSSD by typing service sssd restart
    3. Finally, inspect the SSSD log files for any clues /var/log/sssd/*
  5. Verify that the services work when not called by SSSD.
    • For example, using a LDAP server IP of 10.1.0.7 and a base of dc=hurr,dc=org, you could search using a simple anonymous bind and with mandatory TLS to confirm LDAP server connectivity using ldapsearch.
      ldapsearch -x -ZZ -H ldap://10.1.0.7 -b dc=hurr,dc=org
    • Using the same information, now try communicating without TLS
      ldapsearch -x -H ldap://10.1.0.7 -b dc=hurr,dc=org