LDAP-Signierung deaktiviert: Wie unsignierte Bindungen Active Directory offenlegen

Was ist deaktivierte LDAP-Signierung?

LDAP-Signierung deaktiviert bedeutet, dass ein Active-Directory-Domänencontroller weiterhin LDAP-Datenverkehr ohne Integritätsschutz auf dem vom Client genutzten Bind-Pfad akzeptiert. Microsoft beschreibt klar, dass unsignierte SASL-LDAP-Bindungen und einfache LDAP-Bindungen über eine nicht durch SSL/TLS geschützte Verbindung abgelehnt werden sollten, weil sie das Verzeichnis für Replay-Angriffe und Man-in-the-Middle-Manipulationen öffnen. Bei einfachen Bindungen im Klartext können außerdem Anmeldeinformationen direkt im Netzwerk offengelegt werden.

In der Praxis entsteht die Schwachstelle, wenn Teams die Richtlinie auf Domänencontrollern in einem permissiven Zustand belassen, weil noch eine Altanwendung, ein Skript, eine Appliance oder eine Verzeichnisintegration schwaches LDAP-Verhalten verwendet. Das Verzeichnis bleibt verfügbar, aber das Vertrauen des Domänencontrollers in diesen Datenverkehr ist zu groß. LDAP ist in Active Directory kein Nebenthema, sondern ein zentraler Steuerkanal für Benutzer, Gruppen, Computer und privilegierte Objekte.

LDAP-Signierung deaktiviert taucht häufig im Rahmen einer größeren Active Directory-Sicherheitsaudit-Checkliste für interne Teams auf. Das Thema verdient aber einen eigenen Maßnahmenpfad, weil die Behebung oft genauso sehr bei Applikationsverantwortlichen liegt wie beim Verzeichnisbetrieb.

Wie es funktioniert

Microsoft nennt zwei riskante Muster, die durch LDAP-Signierung auf Domänencontrollern unterbunden werden sollen:

1. SASL-LDAP-Bindungen, die keine Signierung anfordern
2. einfache LDAP-Bindungen über eine Klartextverbindung statt über SSL/TLS

Wenn Signierung erzwungen wird, signieren Client und Server die LDAP-Sitzung kryptografisch, sodass ein Zwischenangreifer den Datenstrom nicht still verändern kann. Wenn einfache Bindungen weiterhin nötig sind, empfiehlt Microsoft, sie über SSL/TLS zu schützen statt sie im Klartext zuzulassen.

Wichtig ist außerdem die Abgrenzung zu LDAP Channel Binding. Signierung schützt die Integrität der LDAP-Sitzung. Channel Binding ist eine separate Härtungsmaßnahme für TLS-geschützte LDAP-Sitzungen und folgt einer anderen Ereignis- und Richtlinienlogik. In realen Umgebungen werden beide Themen oft gemeinsam angegangen, sind aber nicht identisch.

Microsoft weist auch auf eine aktuelle Standardänderung hin: Windows Server 2025 aktiviert LDAP-Signierung standardmäßig für neue Active-Directory-Bereitstellungen. Das zeigt, dass es sich nicht mehr um ein Nischen-Hardening handelt, sondern um eine Basiserwartung. Der Vorbehalt ist, dass dieser neue Standard nur für neue Bereitstellungen gilt: Microsoft gibt an, dass beim Upgrade eines älteren Windows Server auf Windows Server 2025 die bestehenden LDAP-Signierungsrichtlinien erhalten bleiben, um Unterbrechungen zu vermeiden, sodass ein aktualisierter Domänencontroller die bereits vorhandene permissive Einstellung behält.

Die Angriffskette

Schritt 1 - Den Altpfad finden, der noch schwaches LDAP nutzt

Angreifer brauchen keinen Domain-Admin-Startpunkt. Sie suchen zunächst nach dem System, Skript, Jump Host oder der Fachanwendung, die noch schwache LDAP-Bindungen zu einem Domänencontroller ausführt. In internen Audits fällt dieser Pfad oft mit derselben Arbeit auf wie AD-Sicherheitsüberwachung: relevante Event IDs und SIEM: Welche Clients erzeugen noch unsignierte SASL-Bindungen oder Klartext-Bindungen, und wem gehört der Prozess?

# Beispiel für eine einfache LDAP-Bindung im Klartext
ldapsearch -x -H ldap://dc01.corp.local -D 'CORP\svc_legacyapp' -W -b 'DC=corp,DC=local' '(objectClass=user)'

Wenn ein Applikationspfad noch auf Klartext-Bindungen angewiesen ist, liegt das eigentliche Problem nicht nur in der Abfrage. Entscheidend ist, dass der Domänencontroller noch permissiv genug ist, sie anzunehmen.

Schritt 2 - Schwachen LDAP-Traffic abfangen oder manipulieren

Microsoft nennt in der LDAP-Signierungsdokumentation explizit Replay- und Man-in-the-Middle-Risiken bei unsigniertem LDAP-Traffic. Wenn der Bind-Pfad keinen Integritätsschutz hat, kann ein Angreifer in passender Netzwerkposition LDAP-Anfragen verändern oder Authentifizierungsmaterial wiederverwenden.

Deshalb überschneidet sich LDAP-Signierung deaktiviert in der Praxis häufig mit NTLM-Relay-Angriffen in Active Directory. Die Schwachstellen sind nicht identisch, aber beide senken das Vertrauen in Verzeichnis- und Authentifizierungsverkehr im Netzwerk.

Schritt 3 - Verzeichniszugriff in Privilegpfade umwandeln

Sobald der Angreifer auf diesen schwachen LDAP-Pfad setzen kann, folgt nicht immer sofort die vollständige Domänenübernahme. Häufiger beginnt er mit Verzeichnisaufklärung und Privilegkartierung:

• privilegierte Gruppen und Delegationen enumerieren
• sensible Dienstkonten und Applikationsobjekte finden
• Pfade identifizieren, die später ACL-, GPO- oder Kontenmissbrauch erleichtern

Genau diese Logik steckt auch hinter Active Directory-Angriffspfaden zu Domain Admin: Eine Schwäche im Verzeichnis-Kontrollpfad wird besonders gefährlich, wenn sie bei der Suche nach dem kürzesten Weg zu privilegierten Objekten hilft.

Erkennung

Der sauberste First-Party-Erkennungsweg führt über die von Microsoft dokumentierten Directory-Service-Events zur LDAP-Signierung.

Für die erste Priorisierung sollten Sie mit Event 2887 beginnen. Wenn dort Aktivität sichtbar ist, erhöhen Sie die LDAP-Interface-Events, damit Event 2889 die konkrete Quell-IP und Identität liefert. So kann die Maßnahme dem tatsächlichen System- oder Applikationsverantwortlichen zugeordnet werden.

# Relevante LDAP-Signierungsereignisse auf einem DC auslesen
Get-WinEvent -LogName 'Directory Service' |
  Where-Object { $_.Id -in 2886,2887,2888,2889,3039,3040,3041,3074,3075 } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Während der Behebung lohnt sich die Einordnung in eine größere Review wie AD- und Azure-Compliance: NIS2, ISO 27001, CIS Controls. LDAP-Signierung gehört zu den Einstellungen, die in Richtlinien oft längst beschrieben sind, in der Produktion aber trotzdem nicht sauber durchgesetzt werden.

Remediation

Ein belastbarer Remediationspfad sieht typischerweise so aus:

1. Schwache Clients inventarisieren. Werten Sie 2887 aus und aktivieren Sie detaillierte LDAP-Interface-Events, damit 2889 die konkreten Quellsysteme benennt.
2. Clientverhalten korrigieren. Aktualisieren Sie Applikation, Treiber, Appliance oder Skript, sodass SASL-Bindungen signiert werden oder einfache Bindungen über SSL/TLS laufen.
3. Signierung auf Domänencontrollern erzwingen. Setzen Sie Domain controller: LDAP server signing requirements auf Require signing. Legen Sie unter Windows Server 2025 und höher zusätzlich Domain controller: LDAP server signing requirements enforcement fest: Microsoft dokumentiert, dass diese neuere Richtlinie Vorrang vor der älteren hat und sie ersetzt, sodass die alte Einstellung allein das Ergebnis nicht mehr bestimmt.
4. Clientrichtlinie prüfen. Verwenden Sie Network security: LDAP client signing requirements, damit verwaltete Windows-Clients keine schwachen LDAP-Sitzungen mehr initiieren.
5. Abhängige Anwendungen realitätsnah testen. Validieren Sie die Bind-Pfade dort, wo sie produktiv genutzt werden.
6. Restversuche überwachen. Beobachten Sie nach der Umstellung Event 2888 und 2889, um verbleibende Ausnahmen zu finden.

# Beispiel für eine Richtlinienprüfung auf einem Windows-Host
secedit /export /cfg C:\Temp\secpol.cfg
Select-String -Path C:\Temp\secpol.cfg -Pattern 'LDAP'

Die häufigste operative Falle ist nicht die Richtlinie selbst, sondern das Erzwingen ohne Abstimmung mit den Applikationsverantwortlichen. LDAP-Signierung sollte durchgesetzt werden, aber der stabile Weg führt über Inventarisierung, Migrationsplan und erneute Tests. Das gilt besonders, wenn die Umgebung zusätzlich GPO-Fehlkonfigurationen als Angriffsvektor oder andere Hygienemängel aufweist.

Validierung, bevor Sie den Befund schließen

Der Abschlussnachweis sollte mehr zeigen als nur eine geänderte Richtlinie. Führen Sie den ursprünglichen Testpfad erneut aus, bestätigen Sie, dass jetzt Signierung oder LDAPS genutzt wird, und lassen Sie den produktiven Ablauf durch den Applikationsverantwortlichen abnehmen. LDAP-Signierungsprobleme überleben oft in Form vergessener Ausnahmen, alter Dienstkonten oder Appliances, die nach einer GPO-Änderung nie erneut getestet wurden.

Wenn die Umgebung zusätzlich Relay-Risiken auf benachbarten Diensten zeigt, dokumentieren Sie diese Verbindung explizit. In vielen Audits nutzt dasselbe System, das noch schwaches LDAP spricht, auch Bedingungen, die zu NTLM_RELAY_OPPORTUNITY passen. Diese Verbindung hilft, Ausnahmen schneller zu beenden statt sie weiter zu verlängern.

Wie EtcSec das erkennt

EtcSec ordnet das Thema direkt LDAP_SIGNING_DISABLED zu. In der Praxis ist oft zusätzlich ein Blick auf NTLM_RELAY_OPPORTUNITY sinnvoll, wenn schwacher Verzeichnis-Traffic und relayfähige Netzpfade gemeinsam auftreten. Entscheidend ist nicht nur, ob die Einstellung schwach ist, sondern ob die Domänencontroller noch permissiv arbeiten, ob schwache Clients noch aktiv sind und ob die Behebung beim Verzeichnisbetrieb oder bei einem Applikationsteam liegt.

Offizielle Referenzen

• Microsoft Learn: LDAP signing for Active Directory Domain Services on Windows Server
• Microsoft Learn: Manage LDAP signing using Group Policy for Active Directory Domain Service
• Microsoft Learn: How to enable LDAP signing - Windows Server
• Microsoft Support: 2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements for Windows (KB4520412)

Weiterführende Lektüre

Wenn Sie LDAP-Signierung härten, prüfen Sie auch NTLM-Relay-Angriffe in Active Directory, AD-Sicherheitsüberwachung: relevante Event IDs und SIEM, Active Directory-Angriffspfade zu Domain Admin, GPO-Fehlkonfigurationen als Angriffsvektor und Active Directory-Passwortsicherheit: Fehlkonfigurationen mit echtem Risiko. LDAP-Härtung ist am stärksten, wenn Netzwerkvertrauen, Verzeichnisvertrauen und Privilegpfade gemeinsam betrachtet werden.