SMB-Signierung und LDAP-Channel-Binding — Die „andere Hälfte“ der NTLM-Abwehr in der Praxis schließen

„Wir haben angefangen, NTLM zu auditieren, und beheben auch die Stellen mit fest codierten IP-Adressen. Doch wie verteidigen wir uns gegen Relay-Angriffe in der Zwischenzeit, bis wir jede Abhängigkeit beseitigt haben?“ — Das war die mit Abstand häufigste Frage, nachdem wir den vorherigen Artikel „Bringt die NTLM-Abschaffung Ihre Fachanwendungen zum Stillstand?“ veröffentlicht hatten.

Die Antwort ist das Thema dieses Artikels: SMB-Signierung und LDAP-Signierung zusammen mit LDAP-Channel-Binding. Keines von beiden ist eine Maßnahme, um „NTLM zu stoppen“ — beide sind Verteidigungsmaßnahmen, die dafür sorgen, dass Relay-Angriffe (das Weiterleiten gestohlener Authentifizierung an ein anderes Ziel) nicht gelingen, solange NTLM noch im Einsatz ist. Bei einer der beiden, der SMB-Signierung, hat sich der Standardwert bereits tatsächlich geändert — in Windows 11 24H2 / Windows Server 2025 — und er kommt zusammen mit dem OS-Update, ganz gleich, ob Sie selbst etwas tun oder nicht. Bei der anderen, LDAP-Signierung und Channel-Binding, hat sich der Standardwert nicht geändert, und er bleibt so lange locker, bis ein Administrator ihn verschärft. Kurz gesagt: Bei SMB lautet die Frage „kommen Sie dem zuvor, oder kümmern Sie sich erst darum, nachdem das OS-Update einen Vorfall verursacht hat“; bei LDAP lautet die Frage „wann entscheiden Sie selbst, es zu verschärfen“.

Dies ist der dritte Artikel der NTLM-Serie. Das Vorgehen beim NTLM-Audit finden Sie im ersten Artikel, wie das Protokoll funktioniert, im zweiten Artikel.

1. Das Wichtigste zuerst

• SMB-Signierung fügt jeder SMB-Nachricht eine manipulationserkennende Signatur bei. Die Signatur enthält einen Hash der gesamten Nachricht sowie die Identitäten von Sender und Empfänger und schützt so vor Relay- und Identitätswechsel-Angriffen.¹
• Der Standardwert hat sich bereits geändert. Bei Windows 11 Version 24H2 Enterprise, Pro und Education ist Signierung nun sowohl ausgehend als auch eingehend zwingend; bei Windows Server 2025 ist sie nur ausgehend zwingend (bei Home ist keines von beiden zwingend).²
• Die Erzwingung der Signierung bringt auch die Deaktivierung des Gastzugriffs mit sich. Ein NAS, das Signierung nicht unterstützt, oder jedes Gerät, das eine Gastverbindung voraussetzt, wird ab dem Zeitpunkt des OS-Updates die Verbindung verweigern. Die Fehlercodes sind 0xc000a000 (STATUS_INVALID_SIGNATURE) und die Meldung zur Gastblockierung (Abschnitt 4.3).²
• LDAP-Signierung ermöglicht es einem Domänencontroller, „SASL-Binds ohne Signierungsanforderung“ und „Klartext-Einfachbindungen“ abzulehnen. Unsignierter LDAP-Verkehr ist anfällig für Replay-Angriffe und Man-in-the-Middle-Angriffe.³
• LDAP-Channel-Binding bindet Windows-Authentifizierung (einen SASL-Bind) über LDAPS (SSL/TLS) an den TLS-Kanal. Der dafür verwendete Wert heißt Channel-Binding-Token (CBT). Einfachbindungen, die kein CBT besitzen, liegen außerhalb dieser Prüfung (Kapitel 6). Die Steuerung erfolgt über den Registrierungswert LdapEnforceChannelBinding (0/1/2) oder per Gruppenrichtlinie.⁴
• Beide folgen demselben Dreischritt: Audit-Ereignisse lesen, Quellen beheben, dann zur Erzwingung wechseln. Bei LDAP-Signierung identifizieren die Ereignisse 2887 und 2889 die Quellen; beim Channel-Binding leisten das die Ereignisse 3039/3040 sowie die Audit-Ereignisse 3074/3075 (Kapitel 5 und 6).³⁴
• Eine entscheidende Voraussetzung: Keines dieser Updates ändert die Standardwerte von selbst. Microsoft stellt für die gesamte Reihe von LDAP-Updates ab März 2020 ausdrücklich klar, dass sie die Standardrichtlinie für LDAP-Signierung und Channel-Binding nicht ändern. Das Verschärfen ist Aufgabe des Administrators.⁴

2. Warum Signierung — die „andere Hälfte“ des Relay-Angriffs

Wie im zweiten Artikel beschrieben, liegt die grundlegende Schwäche von NTLM darin, dass es keine gegenseitige Authentifizierung gibt. Ein Client kann die Identität eines Servers nicht überprüfen, sodass ein Angreifer sich als echter Server ausgeben, den Client dagegen authentifizieren lassen und die daraus resultierende Authentifizierungsantwort einfach an den echten Server weiterleiten kann. Das ist der Relay-Angriff, und Microsoft selbst schreibt ausdrücklich, dass NTLM- und NTLMv2-Authentifizierung für SMB-Relay- und Man-in-the-Middle-Angriffe anfällig sind.⁵

Würde man NTLM vollständig abschalten, wäre dieser Angriff nicht mehr möglich, doch wie der erste Artikel gezeigt hat, dauert die Bestandsaufnahme und Behebung jeder Abhängigkeit mehrere Monate. Signierung ist die Verteidigung für die Zeit dazwischen.

flowchart LR
    CL["Client"]
    AT["Angreifer<br/>(gefälschter Server)"]
    SV["Echter Server"]

    CL -->|"① Authentifizierungsantwort"| AT
    AT -->|"② Unverändert weitergeleitet"| SV
    SV -.->|"③ Bei erzwungener Signierung:<br/>Der Angreifer besitzt keinen Sitzungsschlüssel<br/>und kann keine gültige Signatur fälschen — Fehlschlag"| AT

Abbildung 1: Zusammenhang zwischen Relay-Angriff und SMB-Signierung

Der entscheidende Punkt ist, dass der Signierschlüssel (der Sitzungsschlüssel) als Ergebnis der Authentifizierung nur beim Client und beim echten Server vorliegt. Ein Angreifer, der lediglich die Authentifizierungsantwort weitergeleitet hat, besitzt den Sitzungsschlüssel nicht und kann daher in einer Umgebung mit erzwungener Signierung keine weiteren Nachrichten fälschen. SMB-Signierung schließt Relays gegen SMB, LDAP-Signierung und Channel-Binding schließen Relays gegen LDAP/LDAPS eines Domänencontrollers.

Ein weiterer praktischer Hinweis: Die Wirksamkeit der Signierung ist nicht unabhängig von der Wahl des Authentifizierungsprotokolls. Der Sitzungsschlüssel leitet sich vom Passwort ab, daher gilt: Wird mit NTLMv2 statt mit Kerberos authentifiziert, ist der Schlüssel, auf dem die Signatur beruht, schwächer. Microsoft selbst nennt die Verwendung von Kerberos und den Verzicht auf Verbindungen zu Freigaben per IP-Adresse oder CNAME als Bedingungen, um die Wirksamkeit der SMB-Signierung zu maximieren.¹ Der Grund: Bei einer Verbindung per IP-Adresse oder über einen Alias, für den kein passender SPN registriert ist, wird statt Kerberos NTLM verwendet (die SPN-Registrierung, falls Sie einen Alias weiterverwenden möchten, wird im ersten Artikel behandelt). Mit anderen Worten: Die Reduzierung der NTLM-Abhängigkeit und die Erzwingung der Signierung sind keine getrennten Maßnahmen, sondern zwei Seiten derselben Sache.

3. SMB-Signierung — Funktionsweise und der bereits geänderte Standardwert

3.1. Die Funktionsweise in einer Minute

SMB-Signierung verwendet den Sitzungsschlüssel und die Verschlüsselungssuite, um jeder Nachricht, die über die Verbindung läuft, eine Signatur beizufügen. Die Signatur enthält im SMB-Header einen Hash der gesamten Nachricht, sodass eine Manipulation unterwegs dazu führt, dass der Hash nicht mehr übereinstimmt. Der Hash enthält auch die Identitäten von Sender und Empfänger, wodurch sich auch Identitätswechsel erkennen lassen.¹

Der Algorithmus wurde von Generation zu Generation verstärkt. SMB1 verwendete MD5, SMB 2.02 wechselte zu HMAC-SHA-256, SMB 3.0 zu AES-CMAC, und Windows Server 2022 sowie Windows 11 führten eine Signierungsbeschleunigung mit AES-128-GMAC ein.¹ Wenn Ihre Erinnerung an „Signierung = langsam“ noch aus der SMB1-Zeit stammt, lohnt es sich, das beiseitezulegen und neu zu messen.

Denken Sie bei der Einstellung nicht in „aktiviert/deaktiviert“, sondern in „erforderlich (Require) oder nicht“. Ab SMB 2.x wird die Einstellung EnableSecuritySignature ignoriert, und nur RequireSecuritySignature hat noch eine Bedeutung. Und wenn entweder Client oder Server Signierung verlangt, wird die Verbindung signiert. Nur wenn keine der beiden Seiten Signierung verlangt, entfällt sie.¹

3.2. Entscheidungstabelle für die Standardwerte

Sie müssen diese Tabelle nicht vollständig lesen. Prüfen Sie zunächst OS und Edition Ihrer eigenen Clients und Server, und lesen Sie nur die für Sie zutreffende Zeile. Edition und Version lassen sich unter Einstellungen > System > Info einsehen („Edition“ zeigt Pro/Home/Enterprise/Education und Ähnliches, „Version“ etwas wie 24H2).

Die oberen drei Zeilen sind die von Microsoft ausdrücklich dokumentierten Standardwerte.² Die unterste Zeile ist seit jeher geltendes Verhalten: Ein Domänencontroller verlangt SMB-Signierung von jeder Gegenstelle, die sich mit ihm verbindet. Die Verteilung von Gruppenrichtlinien und Anmeldeskripten läuft seit jeher unter der Annahme, dass signiert wird.¹

Allein die Home-Edition ist von dieser Standardwertänderung ausgenommen. Weder ausgehend noch eingehend wird Signierung zwingend, sodass ein Update auf 24H2 auf einem Home-Gerät keine Verbindungsfehler durch erzwungene Signierung auslöst (das ist keine Garantie für künftige Änderungen, aber zumindest zum Stand 24H2 gehört es nicht zur „Deadline“).² Anders ausgedrückt: Das Verhalten unterscheidet sich je nach Edition, selbst innerhalb derselben Version 24H2. Bei der Eingrenzung eines Falls „nach dem Update kommen wir nicht mehr auf die Freigabe“ prüfen Sie zuerst die Edition, nicht nur die Version.

Die praktische Bedeutung dieser Tabelle lautet: Das Update auf Windows 11 24H2 (Enterprise, Pro oder Education) macht jede SMB-Verbindung von diesem PC aus signierungspflichtig (Home ist ausgenommen). Ist Ihr firmeneigener Dateiserver ein Windows-System, passiert nichts (Windows unterstützt Signierung in allen Versionen). Vorfälle entstehen bei Drittanbietergeräten, die Signierung nicht unterstützen oder sie deaktiviert haben — also bei alten NAS-Systemen, dem Scan-Ziel eines Multifunktionsgeräts oder eingebetteten Linux-Systemen mit Samba.

4. SMB-Signierung auf „erforderlich“ umstellen

4.1. Den aktuellen Zustand prüfen

# Signierungsanforderung auf Client-Seite (ausgehend)
Get-SmbClientConfiguration | FL RequireSecuritySignature

# Signierungsanforderung auf Server-Seite (eingehend)
Get-SmbServerConfiguration | FL RequireSecuritySignature

True bedeutet erforderlich, False bedeutet nicht erforderlich.² Wenn Sie das per Gruppenrichtlinie verwalten, finden Sie die Einstellung unter Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen, unter „Microsoft-Netzwerk (Client): Kommunikation grundsätzlich digital signieren“ (Client) und „Microsoft-Netzwerk (Server): Kommunikation grundsätzlich digital signieren“ (Server). Das „grundsätzlich (always)“ im Richtliniennamen bedeutet „erforderlich“.¹

4.2. Zuerst „Gegenstellen, die nicht signieren können“ ermitteln (Audit)

Ab Windows 11 Version 24H2 lässt sich ein Audit aktivieren, das Drittanbieter-Clients und -Server erkennt, die Signierung oder Verschlüsselung nicht unterstützen.¹

# Server-Seite: Clients ohne Signierungsunterstützung erkennen
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

# Client-Seite: Server ohne Signierungsunterstützung erkennen
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

Derselbe Mechanismus bietet auch ein Audit, das Gegenstellen ohne Verschlüsselungs-Unterstützung erkennt (-AuditClientDoesNotSupportEncryption / -AuditServerDoesNotSupportEncryption),¹ doch das ist Vorbereitung für einen künftigen Fahrplan zur zwingenden SMB-Verschlüsselung, getrennt vom Signierungsstrang. Geräte, die Signierung, aber nicht Verschlüsselung unterstützen, sind nicht ungewöhnlich, daher sollten Sie Verschlüsselungs-Audit-Ereignisse nicht in Ihre Entscheidung mischen, ob die Signierungsarbeit abgeschlossen ist.

Aufgezeichnet wird an folgenden Orten.¹

Die Prüfung der Ereignisse erfolgt in drei Schritten.

1. Öffnen Sie die Ereignisanzeige (eventvwr.msc) und öffnen Sie im linken Baum Ereignisanzeige > Anwendungs- und Dienstprotokolle > Microsoft > Windows > SMBClient > Audit (für die Serverseite öffnen Sie auf derselben Ebene SMBServer > Audit).
2. Wählen Sie im rechten Bereich „Aktuelles Protokoll filtern“ und geben Sie im Feld „Alle Ereignis-IDs“ 31998,31999 ein (Serverseite: 3021,3022).
3. Öffnen Sie die verbleibenden Ereignisse — sie enthalten Informationen über die Gegenstelle, die nicht signieren konnte. Übertragen Sie das in Ihr Geräteverzeichnis.

Für eine gesammelte Abfrage per PowerShell:

# Client-Seite: Audit-Ereignisse für Server ohne Signierungsunterstützung
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBClient/Audit'; Id=31998,31999 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

# Server-Seite: Audit-Ereignisse für Clients ohne Signierungsunterstützung
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBServer/Audit'; Id=3021,3022 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

Liegen unmittelbar nach dem Aktivieren des Audits noch keine Einträge vor, gibt Get-WinEvent einen Fehler zurück, dass keine passenden Ereignisse gefunden wurden (deshalb ist oben -ErrorAction SilentlyContinue gesetzt). Wie man Filter schreibt, ist in „Ereignisprotokolle praxisnah mit Get-WinEvent untersuchen“ zusammengefasst.

In der Gruppenrichtlinie entsprechen dem „Audit client does not support signing“ und ähnliche Einträge unter Lanman Server / Lanman Workstation, zu finden unter Computerkonfiguration\Administrative Vorlagen\Netzwerk.¹ Der im ersten Artikel beschriebene Ansatz zur Audit-Dauer (so lange laufen lassen, bis der Betrieb einmal vollständig durchlaufen ist) gilt hier genauso.

4.3. Die typischen Fehlerbilder kennen

Verbindet man sich in einer Umgebung mit erzwungener Signierung zu einer Gegenstelle, die nicht signieren kann, ergibt sich folgender Fehler.²

0xc000a000
STATUS_INVALID_SIGNATURE
Die kryptografische Signatur ist ungültig.

Ein weiterer, leicht übersehener Fall ist der Gastzugriff. Die Erzwingung der Signierung bringt auch die Deaktivierung des Gastzugriffs mit sich. Verbindet man sich mit einem NAS, das für nicht authentifizierten (Gast-)Zugriff konfiguriert ist, erscheint eine Fehlermeldung wie die folgende.²

Der Zugriff auf diesen freigegebenen Ordner ist nicht möglich, da die
Sicherheitsrichtlinien Ihrer Organisation den nicht authentifizierten
Gastzugriff blockieren.

Die Priorität bei der Behebung ist klar. Zuerst SMB-Signierung auf dem Gerät selbst aktivieren und mit Anmeldeinformationen statt als Gast authentifizieren. Setzt man clientseitig Set-SmbClientConfiguration -RequireSecuritySignature $false, lässt sich der Signierungsfehler (0xc000a000) vermeiden, doch die Gastblockierung stammt aus einer anderen Clienteinstellung (Verbot unsicherer Gastanmeldungen), und das bloße Lockern der Signierung behebt sie nicht. Microsoft empfiehlt weder das Deaktivieren der Signierung noch den Versuch, Signierung mit einem Gastkonto zu verwenden, als Umgehung für Drittanbietergeräte.² Wenn Sie lockern, behandeln Sie das als zeitlich befristete Ausnahme bis zum Austausch des betreffenden Geräts.

4.4. Reihenfolge der Einführung

Da mit zunehmender Zahl von Geräten mit 24H2 oder neuer „die Client-Seite standardmäßig signierungspflichtig ist“ für einen wachsenden Anteil des Bestands gilt, bestimmt Ihre OS-Update-Planung faktisch die Deadline. Organisationen, die im Zuge des Windows-10-Supportendes auf Windows 11 24H2 oder neuer migrieren, sollten diese Prüfung als Voraussetzung in die Migration aufnehmen („Praktische Optionen nach dem Support-Ende von Windows 10“).

5. LDAP-Signierung — Den Weg zum Domänencontroller schützen

In diesem und im nächsten Kapitel dreht sich alles um die Art des „Binds“, daher klären wir zunächst zwei Begriffe.

Mit anderen Worten: „LDAP-Signierung erzwingen“ bedeutet, für SASL-Binds Signierung zu verlangen und Einfachbindungen über Klartextverbindungen abzulehnen.

Nach SMB folgt LDAP. Unsignierter LDAP-Verkehr zu einem Domänencontroller (oder AD LDS) ist anfällig für Replay-Angriffe und Man-in-the-Middle-Angriffe. Fängt ein Angreifer ein Paket ab, verändert es und leitet es an den Server weiter, kann der Server auf Grundlage dieser gefälschten Anfrage handeln.³

Die Erzwingung der LDAP-Signierung bedeutet, den Verzeichnisserver dazu zu bringen, die folgenden zwei Arten von Binds abzulehnen.³

1. SASL-Binds, die keine Signierung (Integritätsprüfung) verlangen (SASL umfasst hier Negotiate, Kerberos, NTLM und Digest)
2. Einfachbindungen, die über eine Klartextverbindung (nicht SSL/TLS) erfolgen

5.1. Übersicht der Ereignis-IDs (gemeinsam für LDAP-Signierung und Channel-Binding)

Fassen wir zunächst die Ereignis-IDs zusammen, die in diesem und im nächsten Kapitel vorkommen. Alle werden im „Directory Service“-Protokoll des Domänencontrollers erfasst (Ereignisanzeige > Anwendungs- und Dienstprotokolle > Directory Service). Diese Tabelle ist so aufgebaut, dass Sie Ihr Audit-Design direkt daraus ableiten können.

Die Unterscheidung ist einfach. Die Zählereignisse (2887, 3040) zeigen „wie viele noch übrig sind“, die Einzelereignisse (2889, 3039, 3074, 3075) zeigen „woher sie kommen“. Solange die Anzahl nicht null erreicht, gehen Sie nicht zur Erzwingung über. Im Folgenden betrachtet Abschnitt 5.2 die LDAP-Signierung im Detail, Kapitel 6 das Channel-Binding.

5.2. Zuerst auditieren — Ereignisse 2886/2887/2889

Das Directory-Service-Protokoll des Domänencontrollers liefert von Anfang an Hinweise. Von den Ereignissen der Tabelle in Abschnitt 5.1 betreffen 2886, 2887, 2888 und 2889 die LDAP-Signierung; davon zeigt 2887 „wie viele unsignierte Binds es noch gibt“ und 2889 „woher sie kommen“ (2888 ist die Zählung nach Konfiguration der Ablehnung).³

Nur 2889 wird standardmäßig nicht ausgegeben. Setzt man die Diagnoseeinstellung „16 LDAP Interface Events“ auf 2 (Basic), wird das Ereignis aufgezeichnet.³ Das Vorgehen ist also: zuerst mit der Zählung von 2887 prüfen, ob es überhaupt unsignierte Binds gibt, und wenn diese Zahl nicht null ist, 2889 aktivieren, um die Quellen zu identifizieren. Zu beachten ist, dass 2889 keine Zählung ist, sondern bei jedem Auftreten des betreffenden Binds aufgezeichnet wird — in einer Umgebung mit häufigen Legacy-Binds kann das Directory-Service-Protokoll dadurch rasch volllaufen. Setzen Sie die Diagnoseeinstellung nach Identifizierung der Quellen auf ihre vorherige Stufe zurück (standardmäßig 0). Wenn Sie sie dauerhaft laufen lassen möchten, klären Sie zuerst die Weiterleitung und Aufbewahrung der Protokolle.

Typische Quellen sind Fachanwendungen mit LDAP-Anbindung (Authentifizierungsverbund, HR-System-Anbindung), die LDAP-Adressbuchsuche eines Multifunktionsgeräts sowie LDAP-Authentifizierung von Netzwerkgeräten. Besonders die „LDAP-Servereinstellungen“ von Multifunktionsgeräten und ähnlichen Geräten sind oft auf Klartext-Einfachbindungen eingestellt, daher sollten Sie diese zuerst verdächtigen. Die Behebung besteht darin, die Einstellung des Geräts oder der Anwendung auf LDAPS (Port 636) oder auf einen signierten SASL-Bind umzustellen.

5.3. Erzwingen

Sind alle Quellen behoben, erzwingen Sie es per Gruppenrichtlinie.³

• Auf der Domänencontroller-Seite: „Domänencontroller: LDAP-Server-Signaturanforderungen“ unter Sicherheitsoptionen in der Default Domain Controller Policy auf „Signatur erforderlich“ setzen
• Auf der Client-Seite: „Netzwerksicherheit: Anforderungen an LDAP-Client-Signaturen“ auf „Signatur erforderlich“ setzen

Die Überprüfung erfolgt mit ldp.exe. Verbinden Sie sich mit Port 389, versuchen Sie eine Einfachbindung, und wenn folgender Fehler erscheint, ist die Konfiguration wirksam.³

Ldap_simple_bind_s() failed: Strong Authentication Required

6. LDAP-Channel-Binding — Schutz auf der LDAPS-Seite

„Bei uns läuft alles über LDAPS, also sind wir sicher“ — hier schließt Channel-Binding die verbleibende Lücke hinter dieser Annahme. LDAPS verschlüsselt die Kommunikation, kann aber allein nicht vollständig einen Relay verhindern, bei dem „ein Client zur Authentifizierung veranlasst wird und diese Authentifizierung an eine separate, vom Angreifer kontrollierte TLS-Verbindung weitergeleitet wird“. Das Channel-Binding-Token (CBT) bindet die Authentifizierung selbst an genau diesen TLS-Kanal und macht so eine Weiterleitung an einen anderen Kanal erkennbar.

Genau genommen betrifft dies Verbindungen, die Windows-Authentifizierung (NTLM, Kerberos oder Ähnliches über einen SASL-Bind) über LDAPS durchführen. Einfachbindungen besitzen von vornherein kein CBT und liegen daher außerhalb dieser Prüfung. Was eine Einfachbindung über LDAPS schützt, sind die TLS-Verschlüsselung und die Handhabung der Anmeldeinformationen selbst — selbst mit der Einstellung Always erscheint ein Client, der eine Einfachbindung verwendet, nie in den CBT-Audit-Ereignissen.

Die Steuerung erfolgt über einen Registrierungswert auf dem Domänencontroller oder die entsprechende Gruppenrichtlinie.⁴

Die für das Audit verwendeten Ereignisse sind folgende (dies führt die Channel-Binding-Seite der Übersicht aus Abschnitt 5.1 näher aus). Channel-Binding-Ereignisse wurden mit dem Update vom 10. März 2020 hinzugefügt, und die Audit-Ereignisse wurden durch Updates ab 2023 weiter ausgebaut.⁴

Das Vorgehen entspricht dem bei der LDAP-Signierung, und auch Microsofts eigene Anleitung lautet ähnlich: „Überwachen Sie im Directory-Service-Protokoll jedes Domänencontrollers das Ereignis 2889 für Signierungsfehler, 3039 für Channel-Binding-Fehler sowie die Audit-Ereignisse 3074/3075, identifizieren Sie die problematischen Geräte, klären Sie das mit deren Anbietern, bestätigen Sie eine Lösung, und erzwingen Sie erst danach.“⁴

Ein Punkt verdient besondere Betonung: Microsoft hat mit diesen Updates die Standardwerte nicht geändert. Es wird ausdrücklich festgehalten, dass das Update vom 10. März 2020 sowie die folgenden Updates die Standardrichtlinie für LDAP-Signierung und LDAP-Channel-Binding nicht ändern.⁴ Im Gegensatz zur SMB-Signierung (deren Standardwert sich mit 24H2 geändert hat) bleibt LDAP so lange locker, wie der Administrator es zulässt. Positiv gewendet bedeutet das: Sie können den Zeitpunkt der Erzwingung selbst planen, solange Sie noch die Wahl haben.

7. Fachanwendungen und Geräte beheben (Entscheidungstabelle)

Hier sehen Sie, wie sich die vom Audit gefundenen Quellen nach Ursache sortieren lassen.

Arbeiten Sie an einer selbst entwickelten .NET-Anwendung, die LDAP anspricht, ist der erste Verdacht, ob eine Einfachbindung im Klartext gesendet wird.

// Schlechtes Beispiel: Einfachbindung über Klartext-Port 389. Wird bei erzwungener LDAP-Signierung abgelehnt
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Basic;
conn.Bind(new NetworkCredential(user, password));

// Gutes Beispiel 1: Negotiate mit Signierung und Verschlüsselung verlangen
// (Kerberos wird gewählt, sobald SPN und Namensauflösung stimmen)
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Negotiate;
conn.SessionOptions.Signing = true;
conn.SessionOptions.Sealing = true;
conn.Bind();  // Authentifizierung mit dem ausführenden Konto

// Gutes Beispiel 2: Bei Verwendung einer Einfachbindung unbedingt LDAPS einsetzen
var id = new LdapDirectoryIdentifier("dc01.corp.example.com", 636);
var conn2 = new LdapConnection(id);
conn2.SessionOptions.SecureSocketLayer = true;
conn2.AuthType = AuthType.Basic;
conn2.Bind(new NetworkCredential(user, password));

Das Negotiate aus dem guten Beispiel 1 bevorzugt Kerberos, erzwingt es aber nicht. Ist das Ziel eine IP-Adresse, oder ist der SPN nicht registriert oder doppelt vorhanden, fällt es stillschweigend auf NTLM zurück (auch dann greift die Anforderung von Signierung und Verschlüsselung selbst weiterhin). Ob tatsächlich mit Kerberos authentifiziert wird, lässt sich zuverlässig mit klist prüfen, indem man kontrolliert, ob ein Ticket für den betreffenden Dienst tatsächlich abgerufen wurde. Wenn Sie das NTLM-Audit aus dem ersten Artikel (ausgehenden NTLM-Verkehr vollständig auditieren) aktiviert haben, ist das Ausbleiben von Ereignis 8001 ein weiteres Indiz — beachten Sie aber, dass „8001 tritt nicht auf“ bedeutungslos ist, solange diese Audit-Richtlinie nie aktiviert war. Die Einfachbindung aus gutem Beispiel 2 wird zwar durch TLS verschlüsselt, doch wie in Kapitel 6 beschrieben, gilt die CBT-Prüfung für die Seite der Windows-Authentifizierung. Haben Sie in einer Domänenumgebung die Wahl, sollten Sie gutes Beispiel 1 als Standard verwenden. Gehen Sie über DirectoryEntry (ADSI), ist es zuverlässig, AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing explizit zu setzen. Der im ersten Artikel der NTLM-Serie beschriebene Grundsatz — Ziele als FQDN statt als IP-Adresse anzugeben — wirkt auch hier, als Voraussetzung dafür, dass ein SASL-Bind über Kerberos gelingt.

8. Zusammenfassung

• SMB-Signierung und LDAP-Signierung/Channel-Binding verteidigen gegen Relay-Angriffe, während Sie die NTLM-Abhängigkeit beseitigen, und sind zugleich eine dauerhafte Härtungsmaßnahme, die auch nach dem Ende von NTLM sinnvoll bleibt (sowohl die Manipulationserkennung der Signierung als auch das Channel-Binding schützen auch Kerberos-authentifizierte Sitzungen). Verfolgen Sie sie gemeinsam mit der NTLM-Reduzierung, als zwei Seiten derselben Sache.¹⁵
• Der Standardwert der SMB-Signierung hat sich bereits geändert. Windows 11 24H2 (Enterprise/Pro/Education) verlangt sie in beide Richtungen, Windows Server 2025 ausgehend. Ihre OS-Update-Planung setzt die Deadline.²
• Die Fehlerbilder sind vorhersehbar: 0xc000a000 bei Geräten ohne Signierungsunterstützung, und die Gastzugriffsblockierung. Das ab 24H2 verfügbare Audit lässt sich vorausschauend nutzen, um diese zu finden.²¹
• Bei LDAP identifizieren Sie die Quellen mit den Ereignissen 2887/2889 (Signierung) und 3039/3040/3074/3075 (Channel-Binding); beheben Sie sie, dann erzwingen Sie es.³⁴
• Die Standardwerte auf der LDAP-Seite ändern sich nicht durch Updates. Sie bleiben locker, bis ein Administrator sie verschärft. Gehen Sie planvoll vor, solange Sie noch die Wahl haben.⁴
• Bei eigenen Anwendungen lässt sich der Großteil erledigen, indem man „Klartext-Einfachbindungen“ und „fest codierte IP-Adressen“ beseitigt.

Verwandte Artikel

• Bringt die NTLM-Abschaffung Ihre Fachanwendungen zum Stillstand? — Wie Sie Audit-Protokolle erfassen und in welcher Reihenfolge Sie Abhängigkeiten beseitigen
• NTLM und Kerberos anhand von Diagrammen erklärt — Warum die Authentifizierung auf NTLM zurückfällt
• Fallstricke bei Netzlaufwerken und UNC-Pfaden — Der Umgang mit Dateiservern (Freigabeordnern) aus einer Fachanwendung heraus
• Ereignisprotokolle praxisnah mit Get-WinEvent untersuchen
• Praktische Optionen nach dem Support-Ende von Windows 10
• Minimale Sicherheits-Checkliste für Windows-Anwendungen

Verwandte Beratungsleistungen

Die KomuraSoft LLC übernimmt die Anpassung von Fachanwendungen im Zuge der Erzwingung von SMB- und LDAP-Signierung sowie die Untersuchung von Verbindungsstörungen rund um Authentifizierung und Dateifreigabe.

• Windows-Anwendungsentwicklung
• Fehleruntersuchung und Ursachenanalyse
• Weiternutzung und Migration von Altbeständen
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wird der Dateiserver langsamer, wenn wir SMB-Signierung erzwingen?

Der Rechenaufwand für die Signierung ist nicht null, aber der Algorithmus wurde von Generation zu Generation verbessert. Wo SMB1 noch MD5 verwendete, wechselte SMB 2.02 zu HMAC-SHA-256 und SMB 3.0 zu AES-CMAC, und Windows Server 2022 sowie Windows 11 führten eine Signierungsbeschleunigung mit AES-128-GMAC ein. Domänencontroller verlangen zudem schon lange von allen, die sich mit SYSVOL und NETLOGON verbinden, SMB-Signierung, sodass die Verteilung von Gruppenrichtlinien seit jeher unter der Annahme läuft, dass signiert wird. Bevor Sie es aus Leistungsgründen zurückstellen, empfehlen wir, die Signierung zunächst auf einem Pilot-Client zu erzwingen und den tatsächlichen Effekt zu messen. Ein spürbarer Unterschied zeigt sich in der Regel nur bei bestimmten Nutzungsmustern, etwa bei fortlaufender Übertragung großer Dateien.

Nach dem Update auf Windows 11 24H2 verbindet sich unser NAS nicht mehr. Liegt das an der SMB-Signierung?

Typischerweise ja. Bei Windows 11 Version 24H2 Enterprise, Pro und Education ist SMB-Signierung standardmäßig sowohl für ausgehende als auch für eingehende Verbindungen zwingend geworden. Die Verbindung zu einem NAS eines Drittanbieters, der Signierung nicht unterstützt (oder sie deaktiviert hat), schlägt daher mit 0xc000a000 (STATUS_INVALID_SIGNATURE) fehl. Da die Erzwingung der Signierung auch die Deaktivierung des Gastzugriffs mit sich bringt, erscheint bei einem NAS, das für nicht authentifizierte Nutzung konfiguriert ist, die Fehlermeldung „Der Zugriff auf diesen freigegebenen Ordner ist nicht möglich, da die Sicherheitsrichtlinien Ihrer Organisation den nicht authentifizierten Gastzugriff blockieren.“ Die erste Abhilfe besteht darin, SMB-Signierung auf dem NAS selbst zu aktivieren und sich mit Anmeldeinformationen statt als Gast zu verbinden. Es gibt zwar eine clientseitige Umgehung, die die Signierungsanforderung deaktiviert, doch damit lässt sich nur die Seite des Signierungsfehlers beheben. Die Blockierung der Gastverbindung stammt aus einer separaten Clienteinstellung (Verbot unsicherer Gastanmeldungen) und nicht aus der Signierung, und bleibt bestehen, solange nicht auch diese gelockert wird. Microsoft empfiehlt weder das Deaktivieren der Signierung noch den Betrieb über Gastkonten.

Was ist der Unterschied zwischen LDAP-Signierung und LDAPS (LDAP über SSL/TLS)?

Das sind zwei verschiedene Dinge. LDAP-Signierung verlangt Integritätsprüfung (Signierung) für SASL-Binds (Negotiate, Kerberos, NTLM, Digest), die über eine LDAP-Verbindung auf Port 389 laufen; die Kommunikation selbst wird dabei nicht verschlüsselt. LDAPS verschlüsselt die gesamte Verbindung mit SSL/TLS. LDAP-Channel-Binding ist eine weitere Schutzebene oberhalb von LDAPS: Es bindet die Authentifizierung an den TLS-Kanal und verhindert damit Angriffe, bei denen lediglich die Anmeldeinformationen an eine andere TLS-Verbindung weitergeleitet werden. Um einen Domänencontroller zu schützen, denken Sie an drei Maßnahmen zusammen: Klartext-Einfachbindungen unterbinden, für SASL-Binds Signierung verlangen und für Windows-Authentifizierung (SASL-Binds) über LDAPS die Prüfung des Channel-Binding-Tokens verlangen. Beachten Sie, dass Einfachbindungen ohne CBT nicht Gegenstand der Channel-Binding-Prüfung sind — was eine Einfachbindung über LDAPS schützt, ist die TLS-Verschlüsselung selbst.

In welcher Reihenfolge sollten wir das umsetzen?

Die Reihenfolge — Audit, dann Behebung, dann Erzwingung — ist dieselbe wie bei der Einschränkung von NTLM. Aktivieren Sie zunächst bei SMB das ab Windows 11 24H2 verfügbare Audit, das Gegenstellen ohne Signierungsunterstützung erkennt, und ermitteln Sie damit die Geräte, die nicht signieren können. Prüfen Sie bei LDAP im Directory-Service-Protokoll des Domänencontrollers Ereignis 2887 (die 24-stündliche Zählung unsignierter Binds); ist die Anzahl nicht null, setzen Sie die Diagnoseeinstellung „16 LDAP Interface Events“ auf 2 und identifizieren Sie mit Ereignis 2889 die Clients. Beim Channel-Binding gehen Sie ebenso mit den Ereignissen 3039/3040 sowie den seit 2023 hinzugekommenen Audit-Ereignissen 3074/3075 vor. Erst wenn alle problematischen Quellen behoben sind, schalten Sie um: SMB-Signierung erzwingen, LDAP-Signierung erzwingen und Channel-Binding auf Always setzen. Der eine Grundsatz lautet: niemals direkt zur Erzwingung springen.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.