12.9. Gathering debugging logs from the SSSD service to troubleshoot authentication issues with an IdM client
If you experience issues when attempting to authenticate as an IdM user to an IdM client, verify that you can retrieve user information on the IdM server. If you cannot retrieve the user information on an IdM server, you will not be able to retrieve it on an IdM client (which retrieves information from the IdM server).
After you have confirmed that authentication issues do not originate from the IdM server, gather SSSD debugging logs from both the IdM server and IdM client.
Conditions préalables
- The user only has authentication issues on IdM clients, not IdM servers.
-
You need the root password to run the
sssctl
command and restart the SSSD service.
Procédure
-
On the client: Open the
/etc/sssd/sssd.conf
file in a text editor. On the client: Add the
ipa_server
option to the[domain]
section of the file and set it to an IdM server. This avoids the IdM client autodiscovering other IdM servers, thus limiting this test to just one client and one server.[domain/example.com] ipa_server = server.example.com ...
-
On the client: Save and close the
sssd.conf
file. On the client: Restart the SSSD service to load the configuration changes.
[root@client ~]# systemctl restart sssd
On the server and client: Enable detailed SSSD debug logging.
[root@server ~]# sssctl debug-level 6
[root@client ~]# sssctl debug-level 6
On the server and client: Invalidate objects in the SSSD cache for the user experiencing authentication issues, so you do not bypass the LDAP database and retrieve information SSSD has already cached.
[root@server ~]# sssctl cache-expire -u idmuser
[root@client ~]# sssctl cache-expire -u idmuser
On the server and client: Minimize the troubleshooting dataset by removing older SSSD logs.
[root@server ~]# sssctl logs-remove
[root@server ~]# sssctl logs-remove
On the client: Attempt to switch to the user experiencing authentication problems while gathering timestamps before and after the attempt. These timestamps further narrow the scope of the dataset.
[root@client sssd]# date; su idmuser; date Mon Mar 29 16:20:13 EDT 2021 su: user idmuser does not exist Mon Mar 29 16:20:14 EDT 2021
(Optional) On the server and client: Lower the debug level if you do not wish to continue gathering detailed SSSD logs.
[root@server ~]# sssctl debug-level 0
[root@client ~]# sssctl debug-level 0
On the server and client: Review SSSD logs for information about the failed request.
- Review the request from the client in the client logs.
- Review the request from the client in the server logs.
- Review the result of the request in the server logs.
- Review the outcome of the client receiving the results of the request from the server.
If you are unable to determine the cause of the authentication issue:
Collect the SSSD logs you recently generated on the IdM server and IdM client. Label them according to their hostname or role.
[root@server ~]# sssctl logs-fetch sssd-logs-server-Mar29.tar
[root@client ~]# sssctl logs-fetch sssd-logs-client-Mar29.tar
Open a Red Hat Technical Support case and provide:
The SSSD debug logs:
-
sssd-logs-server-Mar29.tar
from the server -
sssd-logs-client-Mar29.tar
from the client
-
The console output, including the time stamps and user name, of the request that corresponds to the logs:
[root@client sssd]# date; su idmuser; date Mon Mar 29 16:20:13 EDT 2021 su: user idmuser does not exist Mon Mar 29 16:20:14 EDT 2021