LDAP-Signierung und Channel Binding auf DCs erzwingen

NTLM-Authentifizierung per Relay an LDAP auf einem Domänencontroller weiterzuleiten, ist der direkteste Weg von „Ich kann einen Rechner dazu bringen, sich bei mir zu authentifizieren“ zur Domänenkompromittierung. Ein Angreifer, der ein Computerkonto an LDAP weiterleitet, kann auf diesem Computer ressourcenbasierte eingeschränkte Delegierung konfigurieren. Ein weitergeleiteter privilegierter Benutzer kann Konten zu Gruppen hinzufügen oder DCSync-Rechte vergeben. Werkzeuge wie ntlmrelayx und KrbRelayUp automatisieren genau das — deshalb ist LDAP-Schutz meist das Erste, was ein Pentest-Bericht fordert.

Der Leitfaden zu NTLM und Legacy-Protokollen nennt die beiden Registrierungswerte, die das Problem beheben. Dieser Leitfaden behandelt die Einführung: wie Sie die Belege von jedem DC sammeln, wie Sie die Ereignisse 2886 bis 2889 und 3039 bis 3041 lesen, was an den einzelnen Client-Typen zu ändern ist und wie Sie vom Audit zur Erzwingung wechseln, ohne an einem Montagmorgen einen Ausfall zu verursachen.

Worin sich die beiden Maßnahmen unterscheiden

Beide Einstellungen befinden sich unter:

Computer Configuration > Policies > Windows Settings > Security Settings >
  Local Policies > Security Options

Channel Binding existiert nur für TLS-geschützte Sitzungen und setzt daher voraus, dass Ihre DCs ein gültiges LDAPS-Zertifikat besitzen, das in der Regel aus der Vorlage Domain Controller Authentication oder Kerberos Authentication ausgestellt wird. Hat LDAPS in Ihrer Domäne noch nie funktioniert, beheben Sie das zuerst; der Leitfaden zur AD-CS-Härtung behandelt die Vorlagen.

Die Standardwerte hängen von der Version ab. Ältere DCs werden mit nicht erforderlicher Signierung und Channel Binding auf „nie“ ausgeliefert. Windows Server 2025 hat für Neuinstallationen strengere Standardwerte und eine zusätzliche Erzwingungseinstellung in den Sicherheitsoptionen eingeführt, aber aktualisierte und In-Place-Umgebungen behalten ihre bisherige Konfiguration. Lesen Sie immer die tatsächlich wirksamen Registrierungswerte aus, statt Annahmen zu treffen.

Messen: die Telemetrie einschalten

Jeder DC protokolliert ohne weitere Änderung Zusammenfassungsereignisse im Protokoll „Directory Service“:

Die clientbezogenen Ereignisse 2889 und 3039 sind die, die Sie brauchen, und sie erfordern die Diagnoseprotokollierung der LDAP-Schnittstelle auf Stufe 2. Aktivieren Sie sie auf jedem DC. In den meisten Domänen ist das Volumen gering, erhöhen Sie aber die Größe des Directory-Service-Protokolls, damit eine Woche an Daten hineinpasst.

$dcs = (Get-ADDomainController -Filter *).HostName
Invoke-Command -ComputerName $dcs -ScriptBlock {
    Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' `
        -Name '16 LDAP Interface Events' -Value 2 -Type DWord
    Limit-EventLog -LogName 'Directory Service' -MaximumSize 512MB
}

Auditieren: die Abarbeitungsliste erstellen

Sammeln Sie 2889 und 3039 von allen DCs über mindestens zwei Wochen, einschließlich eines Monatsabschlusses, falls sich Finanzsysteme an AD binden. Ereignis 2889 speichert Client-Adresse, Identität und Bind-Typ an festen Positionen: Bind-Typ 0 ist ein unsignierter SASL-Bind, 1 ein Simple Bind ohne TLS.

$results = foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{ LogName = 'Directory Service'; Id = 2889 } -ErrorAction SilentlyContinue |
        ForEach-Object {
            [PSCustomObject]@{
                DC       = $dc
                Client   = ($_.Properties[0].Value -split ':')[0]
                Identity = $_.Properties[1].Value
                BindType = @{ '0' = 'Unsigned SASL'; '1' = 'Simple (cleartext)' }[[string]$_.Properties[2].Value]
            }
        }
}
$results | Group-Object Client, Identity, BindType | Sort-Object Count -Descending |
    Select-Object Count, Name | Export-Csv .\ldap-unsigned-clients.csv -NoTypeInformation

# Channel Binding: die rohen 3039-Meldungen pro DC auflisten
foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{ LogName = 'Directory Service'; Id = 3039 } -MaxEvents 200 -ErrorAction SilentlyContinue |
        Select-Object @{n='DC';e={$dc}}, TimeCreated, Message
}

Wenn Sie Ereignisse zentral weiterleiten (siehe Windows-Ereignisweiterleitung), nehmen Sie stattdessen beide IDs in das DC-Abonnement auf und fragen den Collector ab.

Ordnen Sie jede Client-IP einem Verantwortlichen zu. Erfahrungsgemäß enthält die Liste fast immer dieselben Kategorien:

• Drucker und Multifunktionsgeräte, die Adressbuchabfragen per Simple Bind auf 389 durchführen.
• Linux- und Appliance-Integrationen (VPN-Konzentratoren, Firewalls, Wiki- und Ticketsysteme, NAS), konfiguriert mit Bind-DN und Kennwort über unverschlüsseltes LDAP.
• Java-Anwendungen, die JNDI mit einfacher Authentifizierung verwenden.
• Skripte, die System.DirectoryServices mit AuthenticationTypes.None oder expliziter Basic-Authentifizierung nutzen.
• Windows-Clients sind selten ein Problem: Sie handeln die Signierung standardmäßig aus („Network security: LDAP client signing requirements“ = Negotiate signing) und unterstützen Channel Binding seit Jahren.

Die Clients korrigieren

Wählen Sie für jede Quelle eine der folgenden Optionen, in absteigender Präferenz:

1. Kerberos oder Negotiate-SASL verwenden, sofern die Bibliothek das unterstützt. Die Signierung übernimmt dann das Protokoll.
2. LDAPS (636) oder StartTLS verwenden, wobei der Client der Kette der Unternehmens-CA vertraut. Das erfüllt die Signierungsanforderung. Für Channel Binding muss die Client-Bibliothek zusätzlich ein Binding-Token senden; aktuelle Java-Versionen unterstützen das über eine JNDI-Eigenschaft, bei aktuellen OpenLDAP-basierten Clients hängt es von der Version ab — testen Sie jeden einzeln.
3. Das Gerät außer Betrieb nehmen oder ersetzen, wenn es keines von beiden kann. Ein Multifunktionsgerät, das sich nur per Klartext binden kann, legt zudem das Kennwort seines Bind-Kontos für jeden im Netzwerk offen.

Ändern Sie das Kennwort jedes Kontos, das in einem Klartext-Simple-Bind aufgetaucht ist: Es wurde so lange ungeschützt über das Netzwerk gesendet, wie die Integration existiert. Stellen Sie diese Integrationen nach Möglichkeit auf dedizierte Konten mit geringen Rechten um statt auf wiederverwendete Dienstkonten.

Setzen Sie außerdem auf Windows-Rechnern die clientseitige Richtlinie auf erforderliche Signierung, sobald Ihre DCs sie erzwingen, damit ein bösartiger LDAP-Server keinen Downgrade erzwingen kann:

Network security: LDAP client signing requirements = Require signing
HKLM\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity (DWORD) = 2

Stufenweise erzwingen

1. Channel Binding auf 1 (wenn unterstützt) auf allen DCs. Das schützt jeden Client, der bereits Tokens sendet — also moderne Windows-Systeme — praktisch ohne Risiko.
2. Signierung auf erforderlich (LDAPServerIntegrity = 2), sobald 2889 ausbleibt oder nur noch akzeptierte, zur Entfernung eingeplante Quellen zeigt. Beginnen Sie nach Möglichkeit mit einem DC, auf den Sie die verbleibenden Clients lenken können, dann folgen die übrigen.
3. Channel Binding auf 2 (immer), sobald 3039 ausbleibt.

Verteilen Sie die Einstellungen über eine GPO, die mit der OU Domain Controllers verknüpft ist, damit ein neu heraufgestufter DC sie erbt. Beide werden auf aktuellen Windows-Server-Versionen ohne Neustart wirksam; wenn Sie Gewissheit wollen, planen Sie dennoch einen rollierenden Neustart des NTDS-Dienstes oder der DCs in einem Wartungsfenster ein.

Überprüfen

Invoke-Command -ComputerName $dcs -ScriptBlock {
    $p = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
    [PSCustomObject]@{
        DC                  = $env:COMPUTERNAME
        LDAPServerIntegrity = $p.LDAPServerIntegrity
        ChannelBinding      = $p.LdapEnforceChannelBinding
    }
} | Format-Table DC, LDAPServerIntegrity, ChannelBinding

Jeder DC sollte 2 und 2 melden. Die Ereignisse 2886 und 3041 sollten nach dem nächsten 24-Stunden-Zyklus nicht mehr auftreten, und 2888 sollte mit der Anzahl abgelehnter Binds erscheinen — idealerweise null. Ein Wert ungleich null bei 2888 nach der Erzwingung bedeutet, dass ein übersehener Client fehlschlägt: Die Diagnoseereignisse identifizieren ihn. Sobald die Erzwingung stabil läuft, setzen Sie die Diagnosestufe wieder auf 0 — oder belassen Sie sie auf 2, wenn Sie eine dauerhafte Warnung bei Regressionen wünschen.

Führen Sie abschließend Ihre Pentest-Werkzeuge erneut aus oder bitten Sie Ihr Red Team, den Relay-zu-LDAP-Test zu wiederholen. Das Relay sollte beim Bind scheitern.

Was dabei ausfallen kann

• Simple Binds auf 389 ohne TLS werden abgelehnt, sobald Signierung erforderlich ist: Adressbücher von Multifunktionsgeräten, ältere VPN-Appliances, manche SIEM- und IAM-Connectors sowie selbst entwickelte Skripte. Sie müssen auf LDAPS oder StartTLS umgestellt werden.
• LDAPS-Clients ohne Channel-Binding-Unterstützung schlagen fehl, sobald der Wert 2 ist: ältere Java-Laufzeitumgebungen, manche eingebetteten LDAP-Stacks und bestimmte Identitäts-Bridges von Drittanbietern. Wert 1 lässt sie weiter funktionieren — deshalb ist er ein Zwischenschritt.
• TLS-Inspektion oder Load Balancer vor DCs, die TLS terminieren, brechen Channel Binding konstruktionsbedingt, weil der Kanal des Clients nicht der Kanal des DCs ist. Stellen Sie DCs nicht hinter TLS-terminierende Geräte.
• Zertifikatsprobleme werden zu Ausfällen: Sobald Integrationen von LDAPS abhängen, legt ein abgelaufenes DC-Zertifikat sie lahm. Überwachen Sie den Ablauf der DC-Zertifikate und die automatische Registrierung.

Weiterführend: das Thema NTLM & Legacy-Protokolle, der Glossareintrag LDAP Channel Binding, Authentifizierungserzwingung blockieren, um die Auslöser zu beseitigen, die Angreifer weiterleiten, sowie eingeschränkte Delegierung und RBCD zu dem Delegierungs-Schreibzugriff, auf den Relay-zu-LDAP meist abzielt.