LDAP Channel Binding, Domain Controller, NTLM Relay, LDAPS: Die Hälfte der Empfehlung von 2020, die niemand abgeschlossen hat

LDAP Channel Binding, Domain Controller, NTLM Relay, LDAPS — die vier Begriffe gehören in denselben Satz, denn Channel Binding ist die einzige Domain-Controller-Einstellung, die einen NTLM-Relay-Angriff daran hindert, in einer LDAPS-Sitzung auf Port 636 zu landen. Die meisten Active-Directory-Teams haben Microsofts Hardening-Empfehlung von 2020 als eine einzige Maßnahme gelesen, die LDAP-Signierung aktiviert und die Sache damit für erledigt gehalten. Die Channel-Binding-Hälfte ist ein separater Registrywert, der unter Windows Server 2022 und früher so lange nicht existiert, bis ein Administrator ihn anlegt — und Windows Server 2025 hat das nur für brandneue Bereitstellungen geändert.

LDAP Channel Binding, Domain Controller, NTLM Relay, LDAPS: So passen die Teile zusammen

LDAP Channel Binding verwendet ein Channel Binding Token (CBT), um die Authentifizierung, die innerhalb einer TLS-Sitzung stattfindet, an den TLS-Kanal zu binden, der sie transportiert. Microsoft beschreibt es so, dass CBTs verwendet werden, "um Sicherheit auf Anwendungsebene (etwa eine SSL/TLS-Sitzung) kryptografisch mit der zugrunde liegenden Netzwerkverbindung zu verknüpfen", damit ein Angreifer, der die verschlüsselte Sitzung abfängt, sie nicht kapern oder downgraden kann.

Das Token existiert nur an einer Stelle. Die Windows-Richtlinienreferenz für Domain controller: LDAP server channel binding token requirements ist eindeutig: "CBT oder EPA wird bei TLS-Sitzungen verwendet, wenn eine SASL-Authentifizierungsmethode zur Anmeldung des Benutzers eingesetzt wird. SASL bedeutet, dass NTLM oder Kerberos für die Benutzerauthentifizierung verwendet wird. LDAP Simple Bind über TLS bietet keinen Channel-Binding-Token-Schutz und wird deshalb nicht empfohlen."

Zwei Ports sind hier relevant. Klartext-LDAP läuft auf Port 389 — dem Port, auf dem unauthentifizierte Enumerationsprobleme wie anonymer LDAP-Zugriff über dsHeuristics existieren. LDAPS nutzt Port 636 und baut SSL/TLS auf, sobald ein Client sich verbindet. Channel Binding ist eine Kontrolle für den zweiten Port.

Die Fähigkeit selbst ist nicht neu. Laut KB4520412 wurde "die Unterstützung für LDAP Channel Binding durch CVE-2017-8563 unter Windows Server 2008 und späteren Versionen hinzugefügt", und Channel Binding Tokens werden ab Windows 10 Version 1709 unterstützt. Was CVE-2017-8563 tatsächlich lieferte, war die Unterstützung für Extended Protection for Authentication (EPA) plus einen Registrywert, den ein Administrator anlegen muss — nicht ein geänderter Standardwert.

Warum LDAP-Signierung Ihren LDAPS-Traffic nicht abdeckt

Das ist der Teil, der meistens übersprungen wird, und Microsofts eigener Schwachstellentext sagt es unmissverständlich. Die MSRC-Beschreibung von CVE-2017-8563 lautet:

Es besteht eine Sicherheitslücke bezüglich der Erhöhung von Berechtigungen in Microsoft Windows, wenn es einem Man-in-the-Middle-Angreifer gelingt, eine Authentifizierungsanfrage erfolgreich an einen Windows-LDAP-Server weiterzuleiten, etwa ein System, auf dem Active Directory Domain Services (AD DS) oder Active Directory Lightweight Directory Services (AD LDS) läuft, das so konfiguriert wurde, dass es Signierung oder Sealing bei eingehenden Verbindungen erfordert.

Lesen Sie diesen letzten Nebensatz zweimal. Der Domain Controller in diesem Satz verlangt bereits Signierung. Er lässt sich trotzdem relayen. Die Abhilfe, die Microsoft lieferte, war EPA, und die FAQ zu derselben Empfehlung sagt Administratoren, dass die Installation des Updates nicht ausreicht — sie müssen zusätzlich den Registrywert LdapEnforceChannelBinding anlegen.

Der Geltungsbereich der Signierungskontrolle erklärt, warum. Wenn LDAP-Signierung erzwungen wird, "lehnt ein Domain Controller einfache LDAP-Bindungen über Nicht-SSL/TLS-Verbindungen sowie SASL-Bindungen ab, die keine Signierung anfordern". Beide Hälften dieser Regel betreffen Traffic, der sich nicht bereits innerhalb von TLS befindet. Eine einfache Bindung über LDAPS ist nicht das, was die Signierungskontrolle ablehnt, und laut der oben zitierten Richtlinienreferenz erhält sie auch keinen Channel-Binding-Token-Schutz: CBT greift, wenn eine SASL-Methode — NTLM oder Kerberos — die Authentifizierung übernimmt. Deshalb kennzeichnet Microsoft LDAP Simple Bind über TLS als "nicht empfohlen" statt als etwas, das Channel Binding behebt.

Wenn Sie noch an der Signierungsseite arbeiten: Diese Kontrolle wird separat behandelt in LDAP-Signierung deaktiviert: Wie unsignierte Bindungen Active Directory offenlegen. Dieser Artikel behandelt den anderen Wert, auf dem anderen Port.

Der Standardwert, der sich nie geändert hat

Microsofts Empfehlung ADV190023, Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing, ist ungewöhnlich deutlich bei der Beschreibung des Ausgangszustands: "Auf Active-Directory-Domain-Controllern existiert eine Reihe unsicherer Standardkonfigurationen für LDAP Channel Binding und LDAP-Signierung, die es LDAP-Clients erlauben, mit ihnen zu kommunizieren, ohne LDAP Channel Binding und LDAP-Signierung durchzusetzen."

Die Updates vom 10. März 2020, an die sich alle erinnern, fügten die Gruppenrichtlinieneinstellung und die Event-IDs hinzu. Sie haben nichts umgeschaltet. KB4520412 wiederholt die Warnung viermal — in der Einleitung und einmal in jedem Update-Abschnitt: "Die Updates vom 10. März 2020 und zukünftige Updates werden die Standardrichtlinien für LDAP-Signierung oder LDAP Channel Binding oder deren Registry-Äquivalent auf neuen oder bestehenden Active-Directory-Domain-Controllern nicht ändern." Die Auditing-Updates vom 8. August 2023 und 10. Oktober 2023 wiederholen das jeweils für ihr eigenes Release.

Auf der Registry-Seite ist KB4034879 ebenso eindeutig: "Standardmäßig ist diese Einstellung deaktiviert" und "der Registrywert LdapEnforceChannelBindings muss explizit angelegt werden."

Windows Server 2025 ist der Punkt, an dem sich die Geschichte endlich ändert — teilweise.

Microsofts Dokumentation besagt, dass Windows Server 2025 und höher Channel Binding standardmäßig auf "When supported" setzen, mit standardmäßig aktiviertem Channel-Binding-Auditing, und dass diese stärkeren Standardwerte für neue Active-Directory-Bereitstellungen gelten — während "Upgrade-Installationen ihre aktuellen LDAP-Sicherheitseinstellungen beibehalten, um Betriebsstörungen zu vermeiden". Ein Windows-Server-2025-Domain-Controller, der einer Domäne beitritt, die Sie 2016 aufgebaut haben, ist also nicht automatisch der gehärtete aus dem Marketing-Bullet-Point. Wenn eine Domain-Controller-Ablösung ohnehin ansteht, ist dieser Unterschied relevant: siehe Windows Server 2016 Support-Ende: Active-Directory-Domain-Controller-Upgrade.

Und "When supported" ist auch nicht das Ziel. Nach Microsofts eigener Definition werden auf dieser Stufe "nur inkorrekte Channel Bindings blockiert, und Clients, die Channel Binding nicht unterstützen, können weiterhin über LDAP over TLS verbinden". Die dokumentierte Best Practice ist Always.

Die Angriffskette

Schritt 1 - Eine Authentifizierung zum Weiterleiten beschaffen

Der Angreifer benötigt eine Windows-Maschine oder ein Benutzerkonto, das sich gegenüber einem von ihm kontrollierten Host authentifiziert. Die Mechanik dieses Schritts — Coercion, Namensauflösungs-Poisoning, ein bösartiger Freigabepfad — sind dieselben, die in NTLM-Relay-Angriffe: Authentifizierung in AD kapern behandelt werden, und sie ändern sich nicht durch irgendetwas auf dem Domain Controller.

Schritt 2 - In LDAPS auf Port 636 relayen

Statt die Authentifizierung zu terminieren, öffnet der Angreifer eine eigene TLS-Sitzung zu einem Domain Controller auf Port 636 und leitet die Authentifizierungsnachrichten des Opfers dorthin weiter. Genau dieses Szenario beschreibt ADV190023: "ein Man-in-the-Middle-Angreifer, dem es gelingt, eine Authentifizierungsanfrage erfolgreich an einen Windows-LDAP-Server weiterzuleiten ... der nicht so konfiguriert ist, dass er Channel Binding sowie Signierung oder Sealing bei eingehenden Verbindungen erfordert."

Schritt 3 - Binden und als der relayte Principal agieren

Wenn LdapEnforceChannelBinding fehlt oder auf 0 gesetzt ist, hat der Domain Controller keine Möglichkeit zu erkennen, dass die Authentifizierung für einen anderen TLS-Kanal ausgestellt wurde als den, über den sie ankam, und die Bindung gelingt. Der Angreifer verfügt nun über eine authentifizierte LDAP-Sitzung mit den Verzeichnisrechten des relayten Kontos — was, wenn der relayte Principal ein Domain-Controller-Computerkonto oder ein privilegierter Benutzer ist, ein sehr kurzer Weg zum Rest der Domäne ist. Eine authentifizierte LDAP-Sitzung ist auch der Ort, an dem Verzeichnisobjekte geschrieben werden, und Standardwerte wie die Machine Account Quota bestimmen, wie viel ein niedrig privilegiertes Konto damit noch anrichten kann.

Mit CBT-Erzwingung auf Always trägt dieselbe relayte Authentifizierung keine gültige Bindung für den Kanal des Angreifers, und der Domain Controller lehnt sie ab.

Erkennung

Beginnen Sie damit, was jeder Domain Controller aktuell tatsächlich tut — nicht mit dem, was der GPO-Editor behauptet.

$dcs = (Get-ADDomainController -Filter *).HostName

Invoke-Command -ComputerName $dcs -ScriptBlock {
    $params = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
    $diag   = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics'
    [pscustomobject]@{
        DC          = $env:COMPUTERNAME
        OS          = (Get-CimInstance Win32_OperatingSystem).Caption
        CBT         = (Get-ItemProperty $params -Name LdapEnforceChannelBinding -ErrorAction SilentlyContinue).LdapEnforceChannelBinding
        Signing     = (Get-ItemProperty $params -Name LDAPServerIntegrity -ErrorAction SilentlyContinue).LDAPServerIntegrity
        LdapLogging = (Get-ItemProperty $diag -Name '16 LDAP Interface Events' -ErrorAction SilentlyContinue).'16 LDAP Interface Events'
    }
} | Format-Table -AutoSize

Eine leere CBT-Spalte bedeutet, dass der Wert nie angelegt wurde. Unter Windows Server 2022 und früher ist das gleichbedeutend mit 0 — Never.

Beide Einstellungen liegen unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, und KB4520412 ordnet sie den Richtliniennamen wie folgt zu.

Als Nächstes die Events. Alle landen im Directory Service-Log mit der Quelle Microsoft-Windows-ActiveDirectory_DomainService.

🚨 Gefahr: In dieser Tabelle steckt eine Falle. KB4520412 stellt fest, dass "die Events 3039, 3074 und 3075 nur erzeugt werden können, wenn Channel Binding auf When Supported oder Always gesetzt ist". Ein Domain Controller, der auf dem Standardwert steht, erzeugt daher kein Client-Inventar — die Audit-Events, die zeigen, welche Clients ausfallen würden, existieren erst, wenn Sie bereits von Never weggegangen sind. Der übliche Reflex "erst auditieren, dann aktivieren" funktioniert hier umgekehrt: Der Wechsel auf 1 ist der Audit-Schritt.

Die Events 3040 und 3041 sind die Ausnahme und Ihr Baseline-Orakel. Sie werden bei Protokollierungsstufe 0 ohne jede Konfiguration erzeugt, aber nur, wenn die Richtlinie Never ist. Wenn ein Domain Controller 3041 protokolliert, ist Channel Binding auf diesem Domain Controller deaktiviert — unabhängig davon, was die Eigenschaftenseite anzeigte.

Get-WinEvent -FilterHashtable @{
    LogName   = 'Directory Service'
    Id        = 3039, 3040, 3041, 3074, 3075
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Select-Object Name, Count |
    Sort-Object Name

Um die Client-Details zu erfassen, erhöhen Sie die LDAP-Diagnosestufe. KB4520412 gibt den Befehl wörtlich an:

Reg Add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2

Auf Stufe 2 enthalten die Events 3074 und 3075 die Felder, die Sie brauchen, um einen Client nachzuverfolgen: die IP-Adresse und den Port des Clients, die Identität, mit der sich der Client zu authentifizieren versuchte, ob der Client Channel Binding unterstützt, ob er im When-Supported-Modus zugelassen wurde, und einen Wert für das Audit-Ergebnis-Flag.

Get-WinEvent -FilterHashtable @{ LogName = 'Directory Service'; Id = 3074, 3075 } -ErrorAction SilentlyContinue |
    ForEach-Object {
        if ($_.Message -match 'Client IP address:\s*(\d{1,3}(?:\.\d{1,3}){3}):\d+') { $Matches[1] }
    } |
    Group-Object |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Passen Sie das Muster an, falls Clients den Domain Controller über IPv6 erreichen.

Die Audit-Ergebnis-Flags entschlüsseln sich laut KB4520412 wie folgt.

Bits innerhalb von 0x30 zeigen ein gültiges CBT an; Bits innerhalb von 0x0C zeigen ein fehlgeschlagenes an.

Die Audit-Events benötigen zudem den passenden Patch-Stand: laut ADV190023 wurden die Channel-Binding-Audit-Events 3074 und 3075 ohne manuellen Aktivierungsschritt mit den Updates vom 14. November 2023 unter Windows Server 2022 und den Updates vom 9. Januar 2024 unter Windows Server 2019 verfügbar.

Remediation

1. Zuerst die Grundlagen absichern. Channel Binding ist eine Kontrolle für LDAPS, also muss LDAPS gesund sein, bevor Sie irgendetwas erzwingen: ein gültiges Zertifikat auf jedem Domain Controller und eine moderne TLS-Konfiguration. Wenn das nicht verifiziert ist, beginnen Sie mit Domain Controller LDAPS: Schwaches TLS, Print Spooler, Zeitsynchronisations-Audit.

2. Auf When Supported wechseln (Wert 1).

$params = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
New-ItemProperty -Path $params -Name 'LdapEnforceChannelBinding' -PropertyType DWord -Value 1 -Force

KB4034879 bestätigt, dass die operativen Kosten nahe null liegen: "Der LDAP-Server reagiert dynamisch auf Änderungen an diesem Registrywert. Sie müssen den Computer nach der Registry-Änderung daher nicht neu starten." Microsoft empfiehlt außerdem speziell den Wert 1, um die Kompatibilität mit älteren Betriebssystemen zu maximieren.

3. Das Inventar über einen vollständigen Geschäftszyklus hinweg auslesen. Erfassen Sie mit Diagnoseprotokollierung auf Stufe 2 die Events 3074 und 3075 über alle Domain Controller hinweg, lange genug, um monatliche und quartalsweise Jobs zu erfassen. KB4520412 empfiehlt, jede Quell-IP in eine von drei Kategorien einzuordnen: Appliance oder Router (Hersteller kontaktieren), Nicht-Windows-Gerät (mit Betriebssystem- und Anwendungshersteller klären, ob sowohl Signierung als auch Channel Binding unterstützt werden) und Windows-Gerät (prüfen, ob die Anwendung Channel Binding tatsächlich verwendet).

4. Mit bestimmten Ausfallklassen rechnen. Microsofts LDAP-FAQ weist darauf hin, dass Clients, die sich über SSL/TLS ohne CBT verbinden, ausfallen, sobald der Server es erfordert, und dass "SSL/TLS-Verbindungen, die von einem Zwischenserver terminiert werden, der wiederum eine neue Verbindung zu einem Active-Directory-Domain-Controller aufbaut, fehlschlagen werden" — ein Load Balancer, der die TLS-Terminierung vor Ihren Domain Controllern übernimmt, ist ein garantierter Ausfallkandidat. Dieselbe FAQ merkt an, dass "die Unterstützung für Channel Binding bei Drittanbieter-Betriebssystemen und -Anwendungen möglicherweise seltener verbreitet ist als bei LDAP-Signierung", was genau erklärt, warum so viele Umgebungen die Signierung abgeschlossen haben und hier ins Stocken geraten sind. KB4520412 nennt zwei weitere Ausfallmodi. Windows XP "unterstützt LDAP Channel Binding nicht und würde fehlschlagen, wenn LDAP Channel Binding mit dem Wert Always konfiguriert ist, würde aber mit DCs zusammenarbeiten, die auf die entspanntere Einstellung When Supported konfiguriert sind" — es übersteht Schritt 2 und scheitert bei Schritt 5. Und ein Client kann EPA lokal über die Registry-Einstellung SuppressExtendedProtection deaktiviert haben; da KB4520412 einen channel-binding-fähigen Client als einen definiert, bei dem EPA "im Betriebssystem installiert oder verfügbar und nicht über die Registry-Einstellung SuppressExtendedProtection deaktiviert" ist, taucht ein solcher Client auch nie in Ihrem 3075-Inventar auf.

5. Mit Always (Wert 2) per Richtlinie erzwingen. Sobald das Inventar sauber ist, setzen Sie die Gruppenrichtlinie Domain controller: LDAP server channel binding token requirements auf Always unter Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options in der Default Domain Controllers Policy, damit neue Domain Controller die Einstellung erben, statt darauf angewiesen zu sein, dass sich jemand an den Registrywert erinnert. Microsofts erklärte Best Practice für diese Einstellung ist Always; der dokumentierte Nebeneffekt ist, dass Clients, die Channel Binding nicht unterstützen, keine LDAP-Abfragen mehr gegen die Domain Controller ausführen können.

6. Durch Abwesenheit verifizieren. Event 3041 wird nur ausgelöst, solange die Richtlinie Never ist. Wenn ein Domain Controller aufhört, 3040 und 3041 zu protokollieren, und stattdessen 3039 für echte Fehlschläge protokolliert, ist die Erzwingung auf diesem Host aktiv. Führen Sie das Registry-Inventar aus dem Detection-Abschnitt erneut über alle Domain Controller aus — einschließlich aller, die nach der Änderung befördert wurden.

7. Die benachbarten Relay-Pfade schließen. Channel Binding schließt ein Relay-Ziel. Die relayten Anmeldeinformationen stammen meist von irgendwo mit unsigniertem SMB, also kombinieren Sie diese Arbeit mit SMB-Signierung deaktiviert: Warum es weiterhin NTLM-Relay ermöglicht — und Zertifikatregistrierungs-Endpunkte sind ein separates Ziel, das in derselben Kampagne geprüft werden sollte, behandelt in ADCS-Angriffspfade erklärt.

Wie EtcSec Dies Erkennt

EtcSec liest bei jedem Active-Directory-Audit die effektive LDAP-Konfiguration jedes Domain Controllers aus. LDAP_CHANNEL_BINDING_DISABLED kennzeichnet Domain Controller, die keine Channel Binding Tokens erfordern, und LDAP_SIGNING_DISABLED kennzeichnet die Signierungshälfte derselben Empfehlung — bewusst als zwei getrennte Findings, weil das Schließen des einen das andere nicht schließt. NTLM_RELAY_OPPORTUNITY meldet die Relay-Exposition, die diese Standardwerte schaffen, und DC_LDAPS_WEAK_TLS prüft, ob die TLS-Schicht, von der Channel Binding abhängt, selbst solide ist.

Offizielle Referenzen

• KB4520412: 2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements for Windows — Registry-Zuordnungen, vollständige Event-Tabellen und Auslöser, Audit-Ergebnis-Flags
• KB4034879: Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over SSL/TLS more secure — Wertsemantik, Standardzustand, kein Neustart erforderlich
• ADV190023: Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing — die Aussage zu den unsicheren Standardwerten und der Patch-Zeitplan
• CVE-2017-8563 — Windows Elevation of Privilege Vulnerability — der Relay gegen einen signierungspflichtigen LDAP-Server, CVSS-3.0-Basiswert 7.5
• Domain controller: LDAP server channel binding token requirements — Wertdefinitionen, effektive Standardwerte je Windows-Version, Best Practice
• LDAP signing for Active Directory Domain Services on Windows Server — Windows-Server-2025-Standardwerte und Upgrade-Verhalten
• Manage LDAP signing using Group Policy — die Server-2025-Signierungsrichtlinie und Diagnoseprotokollierungsschritte
• KB4546509: Frequently asked questions about changes to Lightweight Directory Access Protocol — Kompatibilitäts-Ausfallmodi

Weiterführende Lektüre

• LDAP-Signierung deaktiviert: Wie unsignierte Bindungen Active Directory offenlegen
• NTLM-Relay-Angriffe: Authentifizierung in AD kapern
• SMB-Signierung deaktiviert: Warum es weiterhin NTLM-Relay ermöglicht
• Domain Controller LDAPS: Schwaches TLS, Print Spooler, Zeitsynchronisations-Audit — eine Checkliste für Netzwerkhygiene
• Anonymer LDAP-Zugriff über dsHeuristics: Active-Directory-Enumeration
• Active Directory Machine Account Quota (ms-DS-MachineAccountQuota)
• ADCS-Angriffspfade erklärt: Wie Zertifikatfehlkonfigurationen zu Active-Directory-Eskalationspfaden werden
• Windows Server 2016 Support-Ende: Active-Directory-Domain-Controller-Upgrade