LDAP Tracing

Manchmal kommt man in die Verlegenheit zu prüfen, wie eine bestimmte Applikation mit LDAP-Abfragen arbeitet. Wenn die Applikation selbst aber keinen Trace anbietet, muss man andere Wege suchen. Es gibt hier mehrere Wege einen Einblick zu erhalten.

Beachten Sie, dass diverse Programme, z.B. Exchange, einen eigenen LDAP-Cache vorhalten und gewisse Antworten lokal bedienen und damit nicht über das LAN gehen oder beim DC ankommen.

Sysinternals ADInsight

Diese Windows-Tools ist mein erster Ansatzpunkt, wenn es um LDAP-Analysen auf einem Client geht. Das Programm wird direkt auf dem System gestartet, auf dem es die LDAP-Aufruf mitschreiben soll.

Bei meinen letzten Tests hat ADInsight leider nicht mehr protokolliert. Ich vermute mal, dass es an der "Wldap32.dll" und nur noch 32bit Prozesse analysiert werden können.

Insight for Active Directory v1.2
https://docs.microsoft.com/en-us/sysinternals/downloads/adinsight

Allerdings ist es hier wichtig die Funktionsweise zu verstehen.

ADInsight uses DLL injection techniques to intercept calls that applications make in the Wldap32.dll library, which is the standard library underlying Active Directory APIs such ldap and ADSI.
Quelle: https://docs.microsoft.com/en-us/sysinternals/downloads/adinsight

Der Client muss also die normalen LDAP-Schnittstellen oder ADSI nutzen. Das machen aber nicht alle und folgende Programme konnte ich bislang auf 64bit Windows nicht mitschneiden. Ich konnte auf einem 64bit Server nicht mehr mitschneiden.

Message Analyzer und LDAP ETW-Provider

Microsoft hat vor einigen Jahren schon das Ende des NetMon 3.4 eingeleitet und mit dem Microsoft Message Analyzer einen Nachfolger platziert, der über die ETW-Provider verschiedene Quellen anzapfen kann.

Microsoft Message Analyzer
https://www.microsoft.com/en-us/download/details.aspx?id=44226

Damit lassen sich auch LDAP-Zugriffe mitschneiden. Bei einer neuen Session wählen die den passenden Provider einfach aus:

Allerdings war ich bislang nur mäßig erfolgreich über diesen Weg mehr Informationen bezüglich LDAP-Anfragen zu erhalten.

Wireshark

Wenn die Kommunikation zwischen dem Programm und dem LDAP-Service über das Netzwerk erfolgt, dann ist natürlich ein "Schnüffler" hier eine gute Option. Wireshark ist hier mein Favorit, der sehr einfach solche Pakete mitschneiden kann. Ich starte mit einem "Capture Filter" auf "port 389", damit ich gezielt die LDAP-Pakete erwische um dann im Display-Filter auch noch LDAP einsetze, verschwinden die TCP-Handshake und der reine LDAP-Datenstrom bleibt übrig. Eine LDAP Suche können Sie über "ldap.protocolOp == 3" weiter einschränken.

Allerdings können Sie über den Weg natürlich keine verschlüsselten LDAP-Anfragen auswerten. LDAP über 389 ist zwar nicht TLS-Verschlüsselt (Anders als LDAPS auf Port 636) aber auch in LDAP muss die Authentifizierung nicht mit Klartext arbeiten (NTLM/Kerberos) und die übertragenen Daten können auch verschlüsselt werden.

DC Eventlog

Zuletzt habe ich noch einen Weg gefunden, wie ein Domain Controller selbst Anfragen im Eventlog protokollieren kann. Es gibt auf Windows Domain Controllern eine Funktion, über sie die gezielt "langsame" Anfragen ermitteln und debuggen können. Wenn Sie diese Funktion aktivieren, dann finden Sie im Eventlog "Directory Services" dann Einträge mit der EventiID 1644 wie der folgende:

Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Date:          27.09.2019 13:09:41
Event ID:      1644
Task Category: Field Engineering
Level:         Information
Keywords:      Classic
User:          UCLABOR\EX01$
Computer:      DC01.UCLABOR.DE
Description:
Internal event: A client issued a search operation with the following options. 
 
Client:
192.168.13.12:56550 
Starting node:
CN=Configuration,DC=UCLABOR,DC=DE 
Filter:
 ( &  (distinguishedName=) ( !  (msExchCU=*) ) )  
Search scope:
subtree 
Attribute selection:
nTSecurityDescriptor,msExchVersion,lastKnownParent,isDeleted 
Server controls:
SDflags:0x7; 
Visited entries:
1 
Returned entries:
1 
Used indexes:
idx_distinguishedName:1:N; 
Pages referenced:
32 
Pages read from disk:
0 
Pages preread from disk:
0 
Clean pages modified:
0 
Dirty pages modified:
0 
Search time (ms):
0 
Attributes Preventing Optimization:
none 
User:
UCLABOR\EX01$

Sie sehen hier insbesondere den Wert "Search time (ms)", welcher ein Maß für die Dauer der Bearbeitung ist. Wenn Sie also komische Performance-Probleme haben, dann können Sie diese Protokollierung einschalten. Der Trick dabei ist nun, dass Sie auch den Grenzwert konfigurieren können, ab dem eine Suche als zu langsam gemeldet wird. Wenn Sie den Wert dann sehr klein ansetzen, erhalten Sie nahezu alle Anfragen im Eventlog. Hier sind die Einstellungen im REG-Format. Nicht alle Werte sind "gesetzt", so dass ich ihnen drei Optionen vorbereitet habe. Die Zeiten sind in Millisekunden angegeben:

Funktion Reg-Datei

Einschalten

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics]
"15 Field Engineering"=dword:00000005

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Inefficient Search Results Threshold"=dword:00000001
"Expensive Search Results Threshold"=dword:00000001
"Search Time Threshold (msecs)"=dword:00000001

Defaults

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics]
"15 Field Engineering"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Inefficient Search Results Threshold"=10000
"Expensive Search Results Threshold"=10000
"Search Time Threshold (msecs)"=30000

Ausschalten

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics]
"15 Field Engineering"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Inefficient Search Results Threshold"=-
"Expensive Search Results Threshold"=-
"Search Time Threshold (msecs)"=-

Über diesen Weg bekommen Sie allerdings dann immer alle LDAP-Abfragen an diesen Domain Controller. Das Eventlog sollten Sie entsprechend groß machen.

Einschätzung

Schade, dass ADInsight nicht mehr funktioniert. Ein Mitschnitt auf dem fraglichen System wäre der einfachste Weg und erspart die Analyse auf dem Netzwerk oder besonders schützenswerte Systeme wie dem Domain Controller. Leider geht genau das wohl nicht mehr. Wenn die LDAP-Anfragen nicht verschlüsselt sind, dann ist Wireshark immer noch mein erstes Mittel der Wahl. Wenn die Pakete aber verschlüsselt sind und der Client selbst kein Debugging erlaubt, dann bleibt wohl oder übel nur der mühsame Weg über die Domain Controller

Weitere Links