Logs strukturieren mit SSSD
Ordnung halten
Veröffentlicht in Ausgabe 04/2022 - PRAXIS
Im letzten Monat ging es an dieser Stelle um den Betrieb von Linux-Clients in einer Active-Directory-(AD)-Umgebung. Als Clientservice kommt auf Linux-Systemen hierfür oftmals der System Security Services Daemon (SSSD) zum Einsatz, wobei der Einsatzzweck nicht auf ein AD im Backend beschränkt ist. Dort könnte ebenso ein einfacher LDAP-Server oder auch ein FreeIPA-Server seine Arbeit verrichten. Und auch wenn die Anbindung eines Clients an solch ein Backend-System zumeist reibungslos funktioniert, können doch immer mal wieder Probleme auftreten, die es dann zu lösen gilt. Hierfür ist jedoch ein grundlegendes Verständnis des Clientservices, der einzelnen Komponenten und Logdateien notwendig.
SSSD-Architektur
Im Schaubild rechts sehen Sie die grundlegende Architektur des SSSD-Diensts und wie die einzelnen Komponenten sowohl intern als auch extern mit Systembibliotheken kommunizieren. Im Front-end stehen so unter anderem Responder als Schnittstelle für das NSS- und PAM-Subsystem zur Verfügung. Im Backend kümmern sich Data Provider um die Kommunikation mit dem jeweiligen
Backend-Systemen. So existieren beispielsweise Provider für das Active Directory, FreeIPA, LDAP und auch lokale Identity-Datenbanken.
Im letzten Monat ging es an dieser Stelle um den Betrieb von Linux-Clients in einer Active-Directory-(AD)-Umgebung. Als Clientservice kommt auf Linux-Systemen hierfür oftmals der System Security Services Daemon (SSSD) zum Einsatz, wobei der Einsatzzweck nicht auf ein AD im Backend beschränkt ist. Dort könnte ebenso ein einfacher LDAP-Server oder auch ein FreeIPA-Server seine Arbeit verrichten. Und auch wenn die Anbindung eines Clients an solch ein Backend-System zumeist reibungslos funktioniert, können doch immer mal wieder Probleme auftreten, die es dann zu lösen gilt. Hierfür ist jedoch ein grundlegendes Verständnis des Clientservices, der einzelnen Komponenten und Logdateien notwendig.
SSSD-Architektur
Im Schaubild rechts sehen Sie die grundlegende Architektur des SSSD-Diensts und wie die einzelnen Komponenten sowohl intern als auch extern mit Systembibliotheken kommunizieren. Im Front-end stehen so unter anderem Responder als Schnittstelle für das NSS- und PAM-Subsystem zur Verfügung. Im Backend kümmern sich Data Provider um die Kommunikation mit dem jeweiligen
Backend-Systemen. So existieren beispielsweise Provider für das Active Directory, FreeIPA, LDAP und auch lokale Identity-Datenbanken.
Da so viele unterschiedliche Komponenten involviert sind, gestaltet sich die Fehlersuche leider nicht immer ganz einfach. Besonders wenn sehr viele Clientanfragen parallel verarbeitet werden müssen. Dies ist unter anderem dem Umstand geschuldet, dass eine einzelne Anfrage an den SSSD-Service eine Vielzahl an Abfragen an interne SSSD-Komponenten auslösen kann. Je mehr Anfragen existieren, desto schwieriger wird es natürlich, diese durch die Logdateien zu verfolgen, um einem möglichen Fehler auf die Schliche zu kommen.
Clientanfragen erhalten eine ID
Seit der SSSD-Version 2.5 bekommen jedoch sowohl Clientanfragen als auch interne Abfragen eine eindeutige ID zugewiesen. Dies hilft dabei, sämtliche Logmeldungen einer Clientanfrage eindeutig zu identifizieren und auch sämtliche interne Kommunikation zu erkennen, die zu diesen Abfragen gehört. Mit der SSSD-Version 2.6 hat das Tool sssctl eine weitere "analyze"-Funktion spendiert bekommen, um alle IDs der Clientanfragen darzustellen und die Logeinträge dieser Abfragen anzuzeigen [1]. Um im SSSD das Debug-Logging zu aktivieren, können Sie ebenfalls das Tool sssctl verwenden:
sssctl debug-level 9. Rufen Sie dann beispielsweise das "id"-Kommando auf, um zu schauen, ob ein bestimmter Benutzer bekannt ist und die Auflösung des Benutzers problemfrei funktioniert:date; id tscherf
Tue Feb 1 10:01:57 EST 2022
uid=1557400003(tscherf) gid=1557400003(tscherf) groups=1557400003(tscherf)
Logfile-Analyse einfach gemacht
Um nun die Client-ID zu dieser id-Abfrage in Erfahrung zu bringen, rufen Sie
sssctl wie folgt auf:sssctl analyze request list
2022-02-01 10:01:57: [uid 0] CID #1: id
Interessieren Sie sich hingegen lediglich für Logmeldungen im Zusammenhang mit einer Authentifizierung, können Sie die Ausgabe mit einem PAM-Filter versehen:
sssctl analyze request list --pam
2022-02-01 14:09:08: [uid 0] CID #1: sshd: admin
Um die einzelnen Logmeldungen einer Clientanfrage aufzulisten, rufen Sie sssctl wie folgt auf:
sssctl analyze request show 1
Das Ergebnis kann natürlich sehr umfangreich sein. Das Listing zeigt einige der Meldungen an. Anhand dessen lässt sich sehr schön erkennen, wie leicht es mit dem Analysetool fällt, Struktur in die vielen Logmeldungen zu bringen. So zeigt das Listing zuerst die Meldungen des NSS-Responders an. Diesen ist zu entnehmen, dass eine interne Abfrage des SSSD-Caches erfolgt (CR #0). Die Abfrage liefert jedoch kein Ergebnis zurück, weshalb eine Anfrage an den Data Provider gesendet wird.
Listing: NSS-Responder-Kommunikation
### Mithilfe des SSSD-Loganalyse-Tools können Sie die Kommunikation des NSS-Responders genau verfolgen.
(2022-02-01 10:01:57): [nss] [accept_fd_handler] (0x0400): [CID#1] Client [cmd id] [uid 0][0x5556ad22e4a0][26] connected!
(2022-02-01 10:01:57): [nss] [nss_getby_name] (0x0400): [CID#1] Input name: tscherf
(2022-02-01 10:01:57): [nss] [cache_req_search_cache] (0x0400): [CID#1] CR #0: Looking up [tscherf@ipa.test] in cache
(2022-02-01 10:01:57): [nss] [cache_req_search_cache] (0x0400): [CID#1] CR #0: Object [tscherf@ipa.test] was not found in cache
(2022-02-01 10:01:57): [nss] [cache_req_search_dp] (0x0400): [CID#1] CR #0: Looking up [tscherf@ipa.test] in data provider
(2022-02-01 10:01:57): [nss] [sss_dp_get_account_send] (0x0400): [CID#1] Creating request for [ipa.test][0x1][BE_REQ_USER][name=tscherf@ipa.test:-]
(2022-02-01 10:01:57): [nss] [cache_req_search_done] (0x0400): [CID#1] CR #0: Returning updated object [tscherf@ipa.test]
(2022-02-01 10:01:57): [nss] [cache_req_create_and_add_result] (0x0400): [CID#1] CR #0: Found 1 entries in domain ipa.test
(2022-02-01 10:01:57): [nss] [cache_req_done] (0x0400): [CID#1] CR #0: Finished: Success
(2022-02-01 10:01:57): [nss] [nss_protocol_done] (0x4000): [CID#1] Sending reply: success
(2022-02-01 10:01:57): [nss] [client_recv] (0x0200): [CID#1] Client disconnected!
Der Provider kümmert sich dann darum, für die Clientanfrage mit der ID 1 (CID#1) die gewünschten Informationen über eine LDAP-Abfrage zur Verfügung zu stellen. Diese interne Kommunikation bekommt die Request-ID 2 (RID#2) zugewiesen. Die Antwort des LDAP-Servers wird dann im SSSD-Cache hinterlegt, sodass der NSS Re-sponder diese schließlich an das Tool id zurückliefern kann. Bei der Authentifizierung eines Benutzers können Sie für die entsprechenden Meldungen natürlich auch hier wieder den PAM-Filter verwenden:
sssctl analyze request show 1 --pam
Fazit
Das Analysieren von Logdateien stellt Administratoren vor Herausforderungen. Der System Security Services Daemon hilft bei der Strukturierung der Daten. Seit der SSSD-Version 2.5 bekommen Anfragen an den Dienst eine ID zugewiesen. Gleiches gilt auch für sämtliche interne Kommunikation. Mit dem Analysetool "sssctl analyse", das seit der Version 2.6 zur Verfügung steht, können Sie die einzelnen Meldungen einer Anfrage aus den SSSD-Debug-Logs herausfiltern. Somit ist es sehr leicht möglich, die komplette Anfrage an den Dienst über sämtliche internen Komponenten hinweg zu verfolgen.
(dr)
Link-Codes
[1] SSSD-Analysetool: https://sssd.io/troubleshooting/analyzer.html