Ereignisverfolgung in ADSI

Windows Server 2008 und Windows Vista führen die Ereignisverfolgung in Active Directory Service Interfaces (ADSI) ein. Bestimmte Bereiche des ADSI-LDAP-Providers haben eine zugrunde liegende Implementierung, die komplex ist oder eine Sequenz von Schritten umfasst, die die Diagnose von Problemen erschwert. Um Anwendungsentwickler*innen bei der Fehlerbehebung zu unterstützen, wurde die Ereignisverfolgung in den folgenden Bereichen hinzugefügt:

Schema-Parsing und Downloading

Die IADs-Schnittstelle in ADSI erfordert, dass das LDAP-Schema auf dem Client zwischenspeichert wird, damit die Attribute korrekt zugeordnet werden können (wie im ADSI-Schemamodel beschrieben). Um dies zu erreichen, lädt ADSI das Schema für jeden Prozess (und für jeden LDAP-Server/jede Domäne) in den Speicher, entweder aus einer Schema-Datei (.sch), die auf dem lokalen Datenträger gespeichert ist, oder durch Herunterladen vom LDAP-Server. Verschiedene Prozesse auf demselben Client Computer verwenden das zwischenspeichernde Schema auf der Festplatte, wenn es verfügbar und anwendbar ist.

Wenn das Schema nicht vom Datenträger oder vom Server abgerufen werden kann, verwendet ADSI ein fest kodiertes Standardschema. In diesem Fall können Attribute, die nicht Teil dieses Standardschemas sind, nicht zugeordnet werden und ADSI gibt beim Abrufen dieser Attribute einen Fehler zurück. Dies kann verschiedene Ursachen haben, z. B. Probleme beim Parsen des Schemas oder unzureichende Berechtigungen zum Herunterladen des Schemas. Es ist oft schwierig zu bestimmen, warum ein bestimmtes Standardschema verwendet wird. Wenn Sie die Ereignisverfolgung in diesem Bereich verwenden, können Sie das Problem schneller diagnostizieren und beheben.

Ändern und Festlegen des Kennworts

ChangePassword und SetPassword verwenden mehr als einen Mechanismus, um den angeforderten Vorgang auf der Grundlage der verfügbaren Konfiguration auszuführen (wie in Einstellen und Ändern von Benutzerkennwörtern mit dem LDAP-Provider beschrieben). Wenn ChangePassword und SetPassword fehlschlagen, kann es schwierig sein, die genaue Ursache zu ermitteln. Die Ereignisverfolgung hilft bei der Fehlerbehebung mit diesen Methoden.

ADSI Bind Cache

ADSI versucht intern, LDAP-Verbindungen wann immer möglich wiederzuverwenden (siehe Verbindungs-Caching). Bei der Fehlerbehebung ist es nützlich, zu verfolgen, ob eine neue Verbindung für die Kommunikation mit dem Server geöffnet wurde oder ob eine bestehende Verbindung verwendet wurde. Es kann auch nützlich sein, den Lebenszyklus des Verbindungs-Caches (manchmal auch als Bind-Cache bezeichnet) und seine Erstellung oder Schließung zu verfolgen und ob eine Verbindungsweiterleitung stattgefunden hat. Bei einer serverlosen Bindung ruft ADSI den DC-Locator auf, um einen Server für die Domäne des Benutzerkontextes auszuwählen. ADSI speichert dann die Zuordnung zwischen Domäne und Server für nachfolgende Verbindungen zwischen. Die Ereignisverfolgung hilft dabei, die Auswahl des DC nachzuvollziehen, und ist daher hilfreich bei der Fehlerbehebung von Verbindungsproblemen.

Aktivieren von Tracing und Starten einer Tracing-Sitzung

Um das ADSI-Tracing zu aktivieren, erstellen Sie den folgenden Registrierungsschlüssel:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\ProcessName

ProcessName ist der vollständige Name des Prozesses, den Sie verfolgen möchten, einschließlich seiner Erweiterung (z. B. „Svchost.exe“). Zusätzlich können Sie einen optionalen Wert vom Typ DWORD namens PID in diesen Schlüssel eintragen. Es wird dringend empfohlen, dass Sie diesen Wert festlegen und damit nur einen bestimmten Prozess verfolgen. Andernfalls werden alle Instanzen der durch ProcessName angegebenen Anwendung aufgezeichnet.

Führen Sie dann den folgenden Befehl aus:

tracelog.exe -start sessionname **-guid #**provider_guid -f filename -flag traceFlags -level traceLevel

SessionName ist einfach ein beliebiger Bezeichner, der zur Kennzeichnung der Tracing-Sitzung verwendet wird (Sie müssen später auf diesen Sitzungsnamen verweisen, wenn Sie die Tracing-Sitzung beenden). Die GUID für den ADSI-Tracking-Provider lautet „7288c9f8-d63c-4932-a345-89d6b060174d“. filename gibt die Protokolldatei an, in die die Ereignisse geschrieben werden sollen. traceFlags sollte einer der folgenden Werte sein:

Diese Flags bestimmen, welche ADSI-Methoden gemäß der folgenden Tabelle verfolgt werden:

Sie können Flags kombinieren, indem Sie die entsprechenden Bits in dem Argument traceFlags kombinieren. Um zum Beispiel die Flags DEBUG_SCHEMA und DEBUG_BINDCACHE anzugeben, wäre der entsprechende Wert für traceFlags 0x00000009.

Schließlich sollte das traceLevel-Flag einer der folgenden Werte sein:

TRACE_LEVEL_INFORMATION veranlasst den Tracing-Prozess, alle Ereignisse aufzuzeichnen, während TRACE_LEVEL_ERROR den Tracing-Prozess veranlasst, nur Fehlerereignisse aufzuzeichnen.

Um das Tracing zu beenden, führen Sie den folgenden Befehl aus:

tracelog.exe -stop sessionname

Im vorherigen Beispiel ist sessionname derselbe Name wie der, der mit dem Befehl angegeben wurde, mit dem der Tracing-Abschnitt gestartet wurde.

Hinweise

Es ist effektiver, nur bestimmte Prozesse zu verfolgen, indem Sie eine bestimmte PID angeben, als alle Prozesse auf einem Computer zu verfolgen. Wenn Sie mehrere Anwendungen auf demselben Computer verfolgen müssen, kann dies Auswirkungen auf die Leistung haben; in leistungsrelevanten Abschnitten des Codes gibt es umfangreiche Debugging-Ausgaben. Außerdem müssen Administrator*innen darauf achten, die Berechtigungen für die Log-Dateien richtig festzulegen, wenn sie mehrere Prozesse verfolgen. Andernfalls könnten alle Benutzer*innen in der Lage sein, die Tracing-Protokolle zu lesen, und andere Benutzer*innen könnten Prozesse verfolgen, die sichere Informationen enthalten.

Nehmen wir zum Beispiel an, der/die Administrator*in richtet die Verfolgung für eine Anwendung „Test.exe“ ein und gibt in der Registrierung keine PID an, um mehrere Instanzen des Prozesses zu verfolgen. Nun möchte ein/e andere/r Benutzer*in die Anwendung „Secure.exe“ verfolgen. Wenn die Log-Dateien für das Tracing nicht ordnungsgemäß eingeschränkt sind, braucht der/die Benutzer*in nur „Secure.exe“ in „Test.exe“ umzubenennen und schon wird der Prozess getrackt. Allgemein ist es am besten, bei der Fehlerbehebung nur bestimmte Prozesse zu verfolgen und den Registrierungsschlüssel für die Ereignisverfolgung zu entfernen, sobald die Fehlerbehebung abgeschlossen ist.

Da die Aktivierung der Ereignisverfolgung zusätzliche Log-Dateien erzeugt, sollten Administrator*innen die Größe der Log-Dateien sorgfältig überwachen; mangelnder Datenträgerplatz auf dem lokalen Computer kann zu einem Denial-of-Service führen.

Beispielszenarien

Szenario 1: Der/die Administrator*in stellt einen unerwarteten Fehler in einer Anwendung fest, die Kennwörter für Benutzerkonten festlegt. Er/sie würde also die folgenden Schritte unternehmen, um das Problem mit Hilfe der Ereignisverfolgung zu beheben.

1. Schreiben eines Skripts, das das Problem reproduziert, und Erstellen des Registrierungsschlüssels

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\cscript.exe

2. Starten einer Tracing-Sitzung und Festlegen von traceFlags auf 0x2 (DEBUG_CHANGEPASSWD) und traceLevel auf 0x4 (TRACE_LEVEL_INFORMATION) mit dem folgenden Befehl:

   tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\adsi.etl -flag 0x2 -level 0x4

3. Ausführen von cscript.exe mit ihrem Testskript, um das Problem zu reproduzieren, und dann Beenden der Tracing-Sitzung:

   tracelog.exe -stop scripttrace

4. Löschen des Registrierungsschlüssels

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\cscript.exe

5. Führen Sie das ETW-Tool tracerpt.exe aus, um die Tracing-Informationen aus den Log-Dateien zu analysieren:

   tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\adsi.etl -flag 0x2 -level 0x4

Szenario 2: Der/die Administrator*in möchte die Schema-Parsing- und Download-Vorgänge in einer ASP-Anwendung namens w3wp.exe verfolgen, die bereits ausgeführt wird. Dazu würde die/der Administrator*in die folgenden Schritte ausführen:

1. Erstellen des Registrierungsschlüssels

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\w3wp.exe

   und in diesem Schlüssel Erstellen eines Werts vom Typ DWORD mit dem Namen PID und Setzen des Werts auf die Prozess-ID der Instanz von w3wp.exe, die derzeit auf dem lokalen Computer ausgeführt wird.

2. Dann Erstellen einer Tracing-Sitzung und Festlegen von traceFlags auf 0x1 (DEBUG_SCHEMA) und traceLevel auf 0x4 (TRACE_LEVEL_INFORMATION):

   tracelog.exe -start w3wptrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\w3wp.etl -flag 0x1 -level 0x4

3. Reproduzieren des Vorgangs, der eine Fehlerbehebung erfordert.

4. Beenden der Tracing-Sitzung:

   tracelog.exe -stop w3wptrace

5. Löschen des Registrierungsschlüssels HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\w3wp.exe.

6. Führen Sie das ETW-Tool tracerpt.exe aus, um die Tracing-Informationen aus den Log-Dateien zu analysieren:

   tracerpt.exe .\w3wp.etl -o -report