Die Abschaltung von NTLM und RC4 war erst der Anfang. Mit LDAP Signing und Channel Binding erzwingt Microsoft die nächste Active Directory Härtung. Diesmal trifft es nahezu jede Umgebung, die noch mit unsigniertem LDAP arbeitet.
Für IT-Administratoren bedeutet das konkrete Handlungsbedarfe, laufende Fristen und potenzielle Ausfälle in Anwendungen, VPN-Systemen und Netzwerkgeräten, wenn jetzt nicht gehandelt wird.
Was ist LDAP und wo liegt das Problem?
LDAP (Lightweight Directory Access Protocol) ist das Protokoll, über das Clients, Anwendungen und Dienste mit dem Active Directory kommunizieren. Jede Benutzeranmeldung, jede Gruppenrichtlinienauswertung und jede Abfrage von Verzeichnisinformationen läuft im Hintergrund über LDAP.
Das Problem: Standardmäßig erlaubt Active Directory seit Jahrzehnten
unsigniertes LDAP über Port 389, also Verbindungen ohne kryptografische Integritätsprüfung. Ein Angreifer im Netzwerk kann diese Verbindungen abfangen, manipulieren oder für Relay-Angriffe missbrauchen.
⚠️ Wichtig: LDAP Relay ist einer der häufigsten Funde in Active Directory Pentests. Er erfordert kein Administratorrecht und ist in nahezu jeder ungehärteten Umgebung ausnutzbar.
Die zwei Schutzmaßnahmen im Überblick
LDAP Signing
LDAP Signing stellt sicher, dass jede LDAP-Nachricht mit einer digitalen Signatur versehen wird. Ohne Signierung kann ein Angreifer die Kommunikation zwischen Client und Domain Controller unbemerkt manipulieren. Mit aktiviertem Signing wird jede manipulierte Nachricht vom Domain Controller abgelehnt.
LDAP Channel Binding
Channel Binding geht einen Schritt weiter: Es bindet die LDAP-Authentifizierung an den zugrundeliegenden TLS-Kanal. Ein Angreifer, der eine Authentifizierung abfängt und weiterleitet, kann die gestohlenen Credentials nicht auf einem anderen Kanal wiederverwenden, weil die Bindung nicht übereinstimmt.
ℹ️ Kurz gefasst: Signing schützt die Integrität der Nachricht. Channel Binding schützt die Authentifizierung vor Weiterleitung. Beide Maßnahmen zusammen schließen den Angriffsvektor vollständig.
⚠️ Die offizielle Microsoft Zeitleiste
Oktober 2025
Abgeschlossen
Phase 1 – Audit Phase
Microsoft führt neue Event-IDs ein, die unsignierte LDAP-Verbindungen im Eventlog sichtbar machen. LDAP wird noch nicht blockiert.
Event ID 2886
Event ID 2887
Event ID 2888
Event ID 2889
Event ID 2887 zeigt die Anzahl unsignierter Binds, Event ID 2889 protokolliert Clients ohne Channel Binding.
März 2026
Aktuell aktiv
Phase 2 – Enforcement Phase
Microsoft setzt den Standardwert für LDAPServerIntegrity auf 2 (Require Signing) auf allen Domain Controllern.
- Clients ohne LDAP Signing werden vom Domain Controller abgewiesen
- Anwendungen, die plain LDAP ohne Signing nutzen, verlieren die Verbindung
- Ein manueller Rollback ist noch möglich, gilt aber als temporäre Maßnahme
September 2026
Bevorstehend
Phase 3 – Finale Durchsetzung
Der Rollback-Pfad wird vollständig entfernt. Kein Registry-Key zur Deaktivierung wird mehr ausgelesen.
- Unsignierte LDAP-Verbindungen werden vollständig blockiert
- Channel Binding Token wird für alle LDAP-Binds über TLS erzwungen
- Kein Rollback mehr möglich
⚠️ Wer auf seinen Domain Controllern Event ID 2887 oder 2889 sieht, hat aktive LDAP-Clients, die nach der Enforcement Phase keine Verbindung mehr aufbauen können.
Konkrete Auswirkungen
Anwendungen mit LDAP-Anbindung
Jede Software, die Benutzer gegen das Active Directory authentifiziert, nutzt LDAP im Hintergrund. Typischerweise betroffen sind VPN-Gateways und Firewalls mit AD-Authentifizierung (Cisco, Fortinet, Palo Alto), Webapplikationen mit LDAP-Bind (Confluence, Jira, GitLab, OTRS), Monitoring-Systeme und SIEM-Lösungen, HR- und ERP-Systeme mit AD-Integration sowie Drittanbieter-Tools mit hartkodierten LDAP-Konfigurationen.
Linux- und Unix-Systeme
Systeme, die per SSSD, nslcd oder pam_ldap gegen Active Directory authentifizieren, sind häufig ohne Signing konfiguriert. Die Standardkonfiguration vieler Linux-Distributionen nutzt schlichten LDAP auf Port 389.
Netzwerkgeräte und Drucker
Switches mit 802.1X-Authentifizierung über LDAP, NAS-Systeme mit AD-Integration sowie ältere Druckersysteme können oft kein Channel Binding unterstützen. Besonders betroffen sind Synology, QNAP sowie ältere Geräte von HP, Canon und Ricoh.
Zertifikatsinfrastruktur
⚠️ Oft übersehen: Channel Binding erfordert ein gültiges TLS-Zertifikat auf den Domain Controllern. Umgebungen ohne interne PKI oder mit abgelaufenen DC-Zertifikaten müssen diese Infrastruktur zuerst aufbauen.
Das Sicherheitsrisiko: Typische Angriffskette
1
Initialer Zugang
Angreifer kompromittiert einen Client im internen Netzwerk, etwa via Phishing oder einer ungepatchten Schwachstelle.
2
Responder starten
Tool wie Responder wird gestartet. Der Angreifer beantwortet LLMNR/NBT-NS-Anfragen im Netzwerk gefälscht.
3
Credentials abfangen
Ein Client versucht sich gegen einen vermeintlichen Dienst zu authentifizieren. Die Credentials landen beim Angreifer.
4
Relay gegen Domain Controller
Die gestohlene Authentifizierung wird direkt gegen den LDAP-Port des Domain Controllers weitergeleitet.
5
Domain Compromise
Ohne Signing oder Channel Binding wird die Verbindung akzeptiert. Admin-Accounts anlegen, Delegation oder vollständige Domain-Übernahme werden möglich.
ℹ️ Kein Administratorrecht erforderlich. Diese Angriffsmethode ist mit Toolkits wie Impacket und ntlmrelayx seit Jahren standardisiert und taucht in nahezu jedem Active Directory Pentest auf.
Was Administratoren jetzt tun müssen
01
Auditing aktivieren und auswerten
Auf allen Domain Controllern die Event-IDs 2886–2889 auswerten und betroffene Clients identifizieren.
02
Betroffene Systeme inventarisieren
Quell-IPs und Hostnamen aus den Audit-Events auflisten, Besitzer ermitteln und nach Migrationspfad kategorisieren.
03
Domain Controller mit TLS-Zertifikaten ausstatten
Channel Binding setzt gültige DC-Zertifikate voraus, entweder über Microsoft AD CS oder eine externe CA.
04
Anwendungen auf LDAPS migrieren
Applikationen von plain LDAP (Port 389) auf LDAPS (Port 636) oder LDAP mit StartTLS umstellen.
05
Enforcement testweise aktivieren
Registry-Key LDAPServerIntegrity = 2 auf einem Test-DC setzen und Auswirkungen beobachten, bevor Microsoft den Wert global erzwingt.
06
Security Audit und Pentesting durchführen
Erst durch einen gezielten LDAP-Relay-Test wird sichtbar, ob die Konfiguration greift und ob weitere Angriffspfade bestehen.
PowerShell-Abfrage zur Analyse
Get-WinEvent -LogName "Directory Service" |
Where-Object { $_.Id -in @(2887, 2889) } |
Select-Object TimeCreated, Id, Message |
Export-Csv ldap_audit.csv -NoTypeInformation
Wie Mint Secure GmbH Sie unterstützen kann
Als spezialisierter IT-Security-Dienstleister unterstützt Mint Secure Unternehmen bei der sicheren Migration und Absicherung ihrer Active Directory Infrastruktur.
Wir identifizieren alle Clients und Anwendungen, die noch unsignierte LDAP-Verbindungen nutzen, bevor Microsoft sie blockiert.
Wir simulieren LDAP Relay, NTLM Relay und Credential-Angriffe, um reale Angriffspfade in Ihrer Umgebung sichtbar zu machen.
Wir begleiten die Migration auf LDAPS, konfigurieren Channel Binding und validieren die Umsetzung anschließend im Test.
Ganzheitliche Prüfung von Delegierungen, Trust-Beziehungen, Privilegien und Protokollkonfiguration im gesamten Active Directory.
Fazit
LDAP Signing und Channel Binding sind keine neuen Konzepte. Microsoft empfiehlt sie seit 2020. Was sich geändert hat: Es ist keine Empfehlung mehr. Der Enforcement-Modus ist seit März 2026 aktiv, ab September 2026 gibt es keinen Weg zurück.
Unternehmen, die jetzt handeln, vermeiden ungeplante Ausfälle in Anwendungen, VPN-Systemen und Netzwerkgeräten, schließen einen der meistgenutzten Angriffsvektoren in Active Directory Umgebungen und reduzieren das Risiko einer Domain-Kompromittierung durch LDAP Relay erheblich.
Jetzt ist der richtige Zeitpunkt zu handeln, bevor Microsoft die Entscheidung abnimmt.
