LDAP-Signierung und Channel Binding auf Domain Controllern erzwingen
Active Directory spricht LDAP auf Port 389, und ohne Signierung ist dieser Verkehr manipulierbar. Microsoft hat die Voreinstellungen mit Windows Server 2025 verschärft, doch bestehende Domänen laufen oft weiter auf dem alten, permissiven Stand. Wer nachzieht, muss vorher wissen, welche Anwendungen sich noch unsigniert anmelden. Dieser Leitfaden zeigt Prüfung, Umsetzung und Kontrolle.
Was die beiden Schutzschichten leisten
LDAP-Signierung signiert jede LDAP-Nachricht in SASL-Sitzungen ohne TLS. Der Server erkennt damit veränderte oder eingeschleuste Pakete und blockt Replay- sowie Man-in-the-Middle-Angriffe. Vertraulichkeit liefert sie nicht: Wer auf Port 389 mitschneidet, liest weiterhin mit. Dafür braucht es TLS (LDAPS oder STARTTLS) oder SASL-Sealing.
Channel Binding, also das Channel Binding Token (CBT), ist die LDAP-Variante von Extended Protection for Authentication. Der Client bindet seine SASL-Anmeldung kryptografisch an die TLS-Sitzung. Ein Angreifer, der NTLM-Anmeldedaten über eine eigene TLS-Verbindung weiterleitet, scheitert am fehlenden passenden Token. Genau das schließt die NTLM-Relay-Lücke von LDAPS ohne CBT.
Wichtig für die Praxis: Simple Binds sind durch keine der beiden Maßnahmen geschützt. Wer Anmeldedaten im Klartext über Port 389 schickt, bleibt angreifbar. Empfohlen ist SASL mit Kerberos über TLS plus Channel Binding.
Was Windows Server 2025 standardmäßig macht
Neue Active-Directory-Installationen auf Windows Server 2025 verlangen LDAP-Signierung per Default. Zusätzlich greift die Richtlinie „Domain controller: LDAP server signing requirements enforcement“, die die Signierungsstufe übersteuert. Channel Binding steht dort auf „When supported“ (1), und ungeschützte LDAPS-Binds werden protokolliert.
Windows Server 2022 und älter sind gegenteilig eingestellt: Signierung ist optional, Channel Binding steht auf „Never“ (0). Seit den Sicherheitsupdates vom März 2023 ist die CBT-Prüfung dort allerdings standardmäßig protokolliert. Die Ereignisse laufen also bereits, ohne dass sie jemand auswertet.
Beim Upgrade auf 2025 bleiben vorhandene Richtlinien erhalten. Ist in der Domäne aber keine Server-Richtlinie gesetzt, erzwingt 2025 die Signierung automatisch. Genau dieser Fall bricht alte Fachanwendungen über Nacht.
Schritt 1: Unsignierte Binds sichtbar machen
Vor dem Erzwingen wird gemessen. Auf jedem Domänencontroller die Diagnose-Stufe für LDAP-Ereignisse auf 2 setzen:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' `
-Name '16 LDAP Interface Events' -Value 2
Danach liefert das Directory-Service-Log die passenden Ereignisse:
- 2886 – Startwarnung, dass unsignierte Binds akzeptiert werden.
- 2887 – 24-Stunden-Zusammenfassung der erlaubten unsignierten Binds.
- 2888 – Zusammenfassung der abgelehnten Binds, also der Zustand nach der Umstellung.
- 2889 – Einzelereignis mit IP-Adresse und Identität des Clients.
- 3039, 3074, 3075 – fehlende oder fehlerhafte CBT-Tokens; 3040 und 3041 erinnern daran, dass CBT noch auf „Never“ steht.
Gesammelt auswerten lässt sich das per PowerShell:
Get-WinEvent -LogName 'Directory Service' -FilterHashtable @{
Id = 2887,2889,3039,3074,3075; StartTime = (Get-Date).AddDays(-7)
} | Group-Object Id | Select-Object Name, Count
Die 2889-Ereignisse nennen IP und Identität. Meist sind es NAS-Systeme, Monitoring-Sonden oder Fachverfahren, die per Simple Bind gegen Port 389 arbeiten.
Schritt 2: Richtlinien setzen
Die Server-Seite gehört in die „Default Domain Controllers Policy“, nicht in die Domänen-Standardrichtlinie. Nach dem Öffnen des Editors:
- Navigieren zu Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen.
- Domain controller: LDAP server signing requirements auf „Require signing“ stellen.
- Domain controller: LDAP server channel binding token requirements zunächst auf „When supported“ (1), nach der Pilotphase auf „Always“ (2).
Auf der Client-Seite setzt die Domänen-Standardrichtlinie Network security: LDAP client signing requirements auf „Require signing“. Registry-Äquivalent auf den DCs: LDAPServerIntegrity mit Wert 2 für „Require signing“ und LdapEnforceChannelBinding mit 0 (Never), 1 (When supported) oder 2 (Always), jeweils unter HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
Vor dem flächendeckenden Rollout eine Pilot-OU mit den kritischen Anwendungen bestücken, danach gpupdate /force ausführen und mit ldp.exe testen. Ein Simple Bind gegen Port 389 muss mit „Strong Authentication Required“ scheitern, dann greift die Signierung.
Schritt 3: Wirkung kontrollieren
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).Name -ScriptBlock {
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' |
Select-Object LDAPServerIntegrity, LdapEnforceChannelBinding
}
Nach dem Umschalten auf „Always“ sinkt die Zahl der 3075-Ereignisse gegen null. Bleiben sie stehen, fehlt den Clients ein CBT-fähiger LDAP-Stack. Das Diagnose-Logging danach wieder auf 0 setzen, sonst wächst das Directory-Service-Log unnötig.
Typische Stolperfallen
- NAS, Multifunktionsdrucker, Monitoring-Appliances und ältere Java-Anwendungen binden oft per Simple Bind an Port 389. Sie brauchen LDAPS auf Port 636 mit gültigem Zertifikat im lokalen Speicher.
- Ein abgelaufenes DC-Zertifikat lässt LDAPS und damit CBT stillschweigend ausfallen. Die Zertifikatsüberwachung gehört deshalb zur Maßnahme.
- Nach dem Start eines DC dauert es bis zu 24 Stunden, bis 2887 und 2888 aussagekräftig sind.
- Ist die Richtlinie nicht auf der Domänencontroller-OU verknüpft, wirkt sie nicht, obwohl sie im Editor sichtbar ist.
Für kommunale Netze mit Bestandsanwendungen lohnt diese Reihenfolge: erst CBT auf „When supported“ und Signierung beobachten, dann die Fachverfahren auf LDAPS umstellen, anschließend erzwingen. Wer beides gleichzeitig scharf schaltet, riskiert Ausfälle im Fachverfahren und damit den Rückfall in alte Einstellungen.
Quellen
- Microsoft Learn: LDAP signing overview for Active Directory Domain Services (aktualisiert 2. Oktober 2026)
- Microsoft Learn: LDAP channel binding overview for AD DS (aktualisiert 2. Oktober 2026)
- Microsoft Learn: LDAP session security settings and requirements after ADV190023
- Microsoft Learn: How to enable LDAP signing in Windows Server (KB935834) (aktualisiert 12. Februar 2026)
Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.
No responses yet