Der Samba-Winbind-Dienst sorgt dafür, Linux-Systeme in eine Active-Directory-Domäne aufzunehmen, um so Benutzern aus den verschiedenen Domänen einer AD-Struktur Zugriff auf Ressourcen der Linux-Rechner zu geben. Der Dienst ist allerdings komplex und eine Fehlersuche gestaltet sich oft schwierig. Das Samba-Team hat sich dem angenommen und das Logging-System überarbeitet.
Der Winbind-Dienst stellt unterschiedliche Services für den Name Service Switch (NSS) und die Pluggable Authentication Modules (PAM) zur Verfügung. Auf der Windows-Seite kommuniziert Winbind mit der Local-Security-Authority (LSA), dem NETLOGON- und LDAP-Service eines Domänencontrollers, um Benutzerkonten zu lokalisieren, Benutzerdaten zu lesen und letztlich die User zu authentifizieren. Als Frontend, um einen Client in eine Domäne aufzunehmen, können Sie sowohl das Samba-eigene Tool net als auch realm [1] verwenden. Letzteres erfordert die Angabe der Option "--client-software=winbind", damit der Winbind-Dienst und nicht der SSSD für den Beitritt zu einer Domäne zum Einsatz kommt.
Unübersichtliche Logdateien
Für jede logische AD-Domäne, auf die der Dienst zugreifen möchte, erzeugt der primäre Winbind-Prozess jeweils einen eigenen Kindprozess. Jeder Prozess bekommt dabei auch eine eigene Logdatei zugewiesen in der, je nach eingestelltem Loglevel, mehr oder weniger Informationen zu finden sind. Sollte es zu Problemen mit der Integration in die Windows-Umgebung kommen, ist es grundsätzlich ratsam, den Loglevel auf einen hohen Wert zu stellen, um möglichst viele Informationen zum Debugging zur Verfügung zu haben.
Das Problem in diesem Fall ist, dass die Menge der Logdaten es nicht unbedingt erleichtert, die Kommunikation zwischen dem Winbind-Prozess und einem Domänencontroller komplett nachvollziehen zu können. Die einzelnen Einträge bestehen jeweils aus einem Header und der eigentlichen Meldung. Der Header enthält neben einem Zeitstempel auch diverse andere Informationen wie beispielsweise den eingestellten Loglevel, die Prozess-ID des Winbind-Prozesses, die Klasse der Logmeldung sowie die eingesetzte Winbind-Funktion. Das nachfolgende Beispiel verdeutlicht dies anhand einer Logmeldung der nss_winbind-Bibliothek:
Der Winbind-Dienst stellt unterschiedliche Services für den Name Service Switch (NSS) und die Pluggable Authentication Modules (PAM) zur Verfügung. Auf der Windows-Seite kommuniziert Winbind mit der Local-Security-Authority (LSA), dem NETLOGON- und LDAP-Service eines Domänencontrollers, um Benutzerkonten zu lokalisieren, Benutzerdaten zu lesen und letztlich die User zu authentifizieren. Als Frontend, um einen Client in eine Domäne aufzunehmen, können Sie sowohl das Samba-eigene Tool net als auch realm [1] verwenden. Letzteres erfordert die Angabe der Option "--client-software=winbind", damit der Winbind-Dienst und nicht der SSSD für den Beitritt zu einer Domäne zum Einsatz kommt.
Unübersichtliche Logdateien
Für jede logische AD-Domäne, auf die der Dienst zugreifen möchte, erzeugt der primäre Winbind-Prozess jeweils einen eigenen Kindprozess. Jeder Prozess bekommt dabei auch eine eigene Logdatei zugewiesen in der, je nach eingestelltem Loglevel, mehr oder weniger Informationen zu finden sind. Sollte es zu Problemen mit der Integration in die Windows-Umgebung kommen, ist es grundsätzlich ratsam, den Loglevel auf einen hohen Wert zu stellen, um möglichst viele Informationen zum Debugging zur Verfügung zu haben.
Das Problem in diesem Fall ist, dass die Menge der Logdaten es nicht unbedingt erleichtert, die Kommunikation zwischen dem Winbind-Prozess und einem Domänencontroller komplett nachvollziehen zu können. Die einzelnen Einträge bestehen jeweils aus einem Header und der eigentlichen Meldung. Der Header enthält neben einem Zeitstempel auch diverse andere Informationen wie beispielsweise den eingestellten Loglevel, die Prozess-ID des Winbind-Prozesses, die Klasse der Logmeldung sowie die eingesetzte Winbind-Funktion. Das nachfolgende Beispiel verdeutlicht dies anhand einer Logmeldung der nss_winbind-Bibliothek:
Die Tatsache, dass Winbind asynchrone Funktionsaufrufe durchführt, erhöht die Schwierigkeit, die Logdateien zu lesen. Die beispielhaften Logmeldungen in Bild 1 verdeutlichen dieses Problem. Der erste Eintrag gehört zu einer Abfrage für den Benutzernamen "JOE" aus der AD-Domäne "ADDOMAIN", um die SID des Benutzers in Erfahrung zu bringen. Die nächste Meldung gibt dann eine SID aus.
Führen Sie nun aber mithilfe des Tools wbinfo eine Validierung der Daten durch, sehen Sie, dass der Benutzer Joe eine SID besitzt, die auf 1110 endet, und die SID mit der Endung 1107 stattdessen der Benutzerin Alice gehört:
Das Problem besteht nun einfach darin, dass Sie durch die asynchronen Funktionsaufrufe keine Beziehung zwischen den einzelnen Logmeldungen herstellen können. Und genau dieses Problem haben die Entwickler in Samba 4.17 gelöst.
Winbind-Tracing
Hierfür wurde der Header der einzelnen Logmeldungen durch ein weiteres Feld mit dem Namen traceid erweitert. In Bild 1 ist dieses Feld bereits enthalten und wie Sie sehen, sind die Werte für das Feld zwischen den beiden Meldungen unterschiedlich. Im ersten Fall lautet die Trace-ID 92, im zweiten Fall jedoch 90. Somit ist sofort zu erkennen, dass die Meldungen zu unterschiedlichen Abfragen gehören. Suchen Sie nach den Einträgen, die zu einer bestimmten Abfrage gehören, können Sie nun also einfach die Trace-ID verwenden, um die zusammengehörigen Logmeldungen zu finden. Hierzu bietet sich sogar ein neues Tool an, das seit Samba 4.19 an Bord ist, dazu gleich mehr.
Bild 1: Wegen asynchroner Funktionsaufrufe von Winbind sind Logdateien nicht sequenziell lesbar.
Neben dem Feld "traceid" gibt es ein weiteres neues Feld namens "depth". Die Idee hierbei ist, den Nesting-Level eines einzelnen Requests einfach identifizieren zu können. Dies ist recht hilfreich, da eine einzelne Abfrage viele unterschiedliche Subrequests erzeugen kann. Durch die Depth-ID erkennen Sie nun ganz einfach, in welcher Beziehung die einzelnen Meldungen stehen und in welcher Reihenfolge die einzelnen Funktionen aufgerufen wurden.
Um den Nesting-Level auch optisch zu kennzeichnen, rückt Winbind die Subrequests, die zu einer Trace-ID gehören, sogar um jeweils vier Leerzeichen ein. Durch diese neue Art des Winbind Log-Tracing, ist es nun also sehr leicht möglich, die einzelnen Funktionsaufrufe, die zu einer Abfrage gehören, zu identifizieren, um somit die Kommunikationswege eindeutig nachzuvollziehen.
Konfiguration und neues Tool
Damit Winbind nun auch tatsächlich diese beiden neuen Header-Felder in den Log-Meldungen verwendet, ist in der Konfigurationsdatei "/etc/samba/smb.conf" eine neue Option zu setzen:
winbind debug traceid = yes
Um nun sämtliche Logmeldungen zu sehen, die zu einer bestimmten Trace-ID gehören, greifen Sie einfach auf das neue Tool samba-log-parser zurück:
samba-log-parser --traceid 92 /var/log/samba/
Das Schöne an dem Werkzeug ist, dass Sie neben der Trace-ID lediglich das Logverzeichnis angeben müssen und Sie dann sämtliche Meldungen zu dieser Trace-ID sehen – unabhängig davon, in welcher Logdatei diese Meldung hinterlegt ist. Das Tool zeigt jeweils an, aus welchem File die Meldungen stammen (Bild 2). Sie können zudem die vorhandenen Logs für eine bestimmte Trace-ID anhand von Zeitstempeln sortieren und daraus eine neue Logdatei generieren. Wie auch im letzten Beispiel zeigt Ihnen samba-log-parser dann jeweils an, aus welcher Datei die einzelnen Meldungen stammen:
Bild 2: Das neue Tool samba-log-parser zeigt Ihnen alle Meldungen zu einer Trace-ID aus unterschiedlichen Logdateien an.
Dies ist hilfreich, da Sie nun eine chronologische Reihenfolge sämtlicher Meldungen für die angegebene Trace-ID in der Datei "traces-82-by-timestamp.log" besitzen. Und schließlich zeigt Ihnen das Tool auch ein Flow-Tracing an. Hierbei sehen Sie lediglich die Funktionen ohne weitere Informationen, die eine bestimmte Anfrage verwendet. Dies kann bei komplexen Abfragen hilfreich sein, um sich einen Überblick zu verschaffen, welche Funktionen aufgerufen werden, ohne die eigentliche Logmeldung zu sehen. Der Aufruf von samba-log-parser sieht dann wie folgt aus:
Während die Header-Felder "traceid" und "depth" unabhängig vom eingestellten Log-level zur Verfügung stehen, benötigen Flow-Traces einen Loglevel von 20. Diesen stellen Sie ganz einfach mit smbcontrol all debug 20 ein.
Fazit
Die neuen Logging-Funktionen helfen, die Winbind-Logdateien besser zu lesen und Fehlern schneller auf die Spur zu kommen. So können Sie auf das Tool samba-log-parser zurückgreifen, um nur relevante Meldungen zu sehen.