LDAP-Signierung deaktiviert: Wie unsignierte Bindungen Active Directory offenlegen

What Is LDAP-Signierung deaktiviert?

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.

How LDAP-Signierung deaktiviert Works

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.

The Attack Chain

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.

Detection

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.

Welche Abhängigkeiten Sie vor dem Enforcing dokumentieren sollten

Viele Teams unterschätzen nicht die Richtlinie selbst, sondern die Zahl der Altpfade, die sich über Jahre um den Domänencontroller herum gebildet haben. Bevor Sie LDAP-Signierung verbindlich erzwingen, sollten Sie festhalten, welche Anwendungen noch einfache Bindungen nutzen, welche Integrationen von Appliances oder Migrationswerkzeugen betroffen sind, welche Dienstkonten beteiligt sind und welches Testfenster realistisch ist. Diese Dokumentation verhindert, dass die Maßnahme später als „AD-Ausfall“ wahrgenommen wird, obwohl in Wahrheit eine unsichere Altintegration blockiert wurde.

Für die Praxis heißt das: Nicht nur den technischen Pfad dokumentieren, sondern auch den fachlichen Eigentümer, das Betriebsfenster und die Fallback-Option. Wenn ein Hersteller oder internes Team behauptet, LDAP-Signierung verhindere eine kritische Business-Funktion, sollte die Ausnahme an einen konkreten Endpunkt, einen benannten Owner und ein klar definiertes Migrationsziel gebunden werden. Alles andere verlängert die Schwachstelle nur organisatorisch.

Gerade in großen Umgebungen lohnt sich außerdem ein Vergleich mit anderen Verzeichnis-Härtungen. Systeme, die noch unsigniertes LDAP verwenden, fallen oft auch bei Passwort-Hygiene, Delegationen oder GPO-Steuerung auf. Wer diese Abhängigkeiten früh sichtbar macht, reduziert späteren Abstimmungsaufwand und vermeidet hektische Rollbacks.

Remediation

💡 Quick Win: Nutzen Sie zunächst Event 2887 und 2889. Identifizieren Sie alle Clients, die noch unsignierte SASL- oder Klartext-LDAP-Bindungen verwenden, bevor Sie auf Domänencontrollern die vollständige Ablehnung erzwingen.

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.
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.

Validate Before You Close the Finding

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.

Was Sie im Pilot zwingend beweisen sollten

Bei LDAP-Signierung scheitern Rollouts selten an der Richtlinie selbst, sondern an unklaren Altpfaden. Ein belastbarer Pilot sollte drei Dinge nachweisen. Erstens müssen betroffene Clients entweder auf signierte SASL-Bindungen oder auf LDAPS umgestellt werden können, ohne dass der Fachprozess ausfällt. Zweitens sollten 2887 und 2889 nach Aktivierung detaillierter LDAP-Interface-Events sauber zeigen, welche Quell-IP, welches Konto und welche Anwendung noch schwache Bindungen versuchen. Drittens muss die Betriebsdokumentation Signierung und LDAP Channel Binding getrennt behandeln. Microsoft bewertet beide Kontrollen separat: Signierung adressiert unsignierte SASL-Bindungen und einfache Bindungen ohne SSL/TLS, Channel Binding schützt TLS-gebundene Sitzungen vor bestimmten MitM-Szenarien. Wer diese drei Nachweise im Pilot dokumentiert, reduziert Rollback-Druck und verhindert, dass eine einzige Legacy-Integration die Durchsetzung auf allen Domänencontrollern monatelang blockiert.

How EtcSec Detects This

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.

ℹ️ Note: EtcSec prüft LDAP-Signierungsprobleme automatisch bei jedem Active-Directory-Audit und hilft so, zwischen einer guten Richtlinie auf dem Papier und einer tatsächlich erzwungenen Kontrolle zu unterscheiden.

Official References

• 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 in Windows Server
• Microsoft Support KB4520412: LDAP channel binding and LDAP signing requirements for Windows

Related Reading

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.