SMB Signing — jetzt Pflicht, aber habt ihr es auch wirklich aktiv?
Windows Server 2025 und Windows 11 24H2 erzwingen SMB-Signierung standardmäßig. Doch gemischte Umgebungen mit älteren Servern, NAS-Geräten und Drittanbieter-Software sind eine tickende Zeitbombe — wenn ihr es nicht vorher prüft.
SMB Signing ist keine neue Erfindung. Die Technologie existiert seit Windows 2000. Und trotzdem war sie in den meisten Unternehmensumgebungen jahrzehntelang nicht konsequent aktiviert — weil Microsoft sie nie wirklich erzwungen hat. Das hat sich mit Windows Server 2025 und Windows 11 24H2 geändert. Grundlegend.
In diesem Beitrag erkläre ich, was SMB Signing ist, warum Microsoft jetzt auf Enforcement umgestellt hat, welche Fallstricke in gemischten Umgebungen lauern — und wie ihr mit PowerShell und GPO den Status eurer gesamten Umgebung prüft und absichert.
Was ist SMB Signing — und warum ist es so wichtig?
Server Message Block (SMB) ist das Protokoll hinter jeder Windows-Dateifreigabe, jedem Druckerzugriff und vielen internen Kommunikationswegen. SMB Signing fügt jedem SMB-Paket eine kryptografische Signatur hinzu — basierend auf dem Session Key und einer Cipher Suite.
Diese Signatur enthält einen Hash der gesamten Nachricht. Wird eine Nachricht auf dem Übertragungsweg manipuliert, stimmt der Hash nicht mehr — und das System erkennt den Angriff sofort.
Ohne SMB Signing kann ein Angreifer im Netzwerk Authentifizierungsanfragen abfangen und gegen einen anderen Server weiterleiten — ohne das Passwort zu kennen. Ergebnis: Domänencompromittierung in wenigen Minuten.
Ohne Signierung kann ein Angreifer SMB-Pakete unbemerkt manipulieren — Dateien austauschen, Konfigurationen ändern oder Malware injizieren, ohne dass Client oder Server etwas merken.
Ein gefälschter SMB-Server kann sich ohne Signing gegenüber Clients als legitimer Fileserver ausgeben — ein klassischer Phishing-Ansatz auf Protokollebene, besonders tückisch bei Gastzugriffen.
Eine aktuelle SMB-Relay-Schwachstelle aus dem Jahr 2025 zeigt: Das Thema ist kein akademisches Problem, sondern aktiv ausgenutzt. Microsoft reagierte mit erweiterten Audit-Funktionen und Härtungsempfehlungen.
Die historische Ausgangslage: SMB Signing war nie wirklich Pflicht
Bis Windows Server 2025 war SMB Signing nur in zwei Szenarien automatisch erzwungen:
- Beim Zugriff auf die Freigaben SYSVOL und NETLOGON auf Domänencontrollern
- Wenn ein Active Directory-DC SMB Signing für seine Clients explizit per GPO erzwang
Alle anderen Verbindungen — also praktisch jede normale Dateifreigabe, jeder DFS-Namespace-Zugriff, jede administrativer Share — liefen ohne Signing. Admins mussten aktiv werden, wenn sie es wollten. Das Ergebnis: In den meisten Umgebungen war SMB Signing über Jahrzehnte stillschweigend deaktiviert.
Der Wendepunkt: Was Windows Server 2025 und Windows 11 24H2 ändern
| Betriebssystem | Ausgehend (Client) | Eingehend (Server) |
|---|---|---|
| Windows Server 2019 / 2022 | Nur SYSVOL/NETLOGON | Nur SYSVOL/NETLOGON |
| Windows Server 2025 | ✓ Alle Verbindungen | Optional (empfohlen) |
| Windows 11 24H2 (Pro/Enterprise) | ✓ Alle Verbindungen | ✓ Alle Verbindungen |
| Windows 11 24H2 Home | Nicht erzwungen | Nicht erzwungen |
Neu seit September 2025: Audit-Modus für sicheres Rollout
Microsoft hat mit den September-2025-Updates eine entscheidende Neuerung eingeführt: Bevor ihr SMB Signing serverseitig hart erzwingt, könnt ihr mit dem Audit-Modus genau sehen, welche Clients in eurer Umgebung kein Signing unterstützen — ohne dass bestehende Verbindungen unterbrochen werden.
Audit-Modus per PowerShell aktivieren:
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true -Force# EPA-Audit aktivieren (Extended Protection for Authentication)
Set-SmbServerConfiguration -AuditClientDoesNotSupportEncryption $true -Force
Im Anschluss erscheinen im Event Log unter Microsoft-Windows-SMBServer/Audit folgende Event IDs:
| Event ID | Bedeutung |
|---|---|
| 3021 | Client hat sich verbunden, unterstützt aber kein SMB Signing |
| 3022 | Client hat sich verbunden, unterstützt kein SMB Signing und keine EPA |
| 3023 | Client hat sich ohne EPA verbunden (SPN nicht mitgeschickt) |
| 3024 | Client unterstützt weder Signing noch Encryption |
$since = (Get-Date).AddDays(-7)
Get-WinEvent -LogName “Microsoft-Windows-SMBServer/Audit” -ErrorAction SilentlyContinue |
Where-Object { $_.Id -in @(3021,3022,3023,3024) -and $_.TimeCreated -gt $since } |
Select-Object TimeCreated, Id, Message |
Sort-Object Id |
Format-Table -AutoSize# Als CSV exportieren für Bestandsaufnahme
Get-WinEvent -LogName “Microsoft-Windows-SMBServer/Audit” -ErrorAction SilentlyContinue |
Where-Object { $_.Id -in @(3021,3022,3023,3024) -and $_.TimeCreated -gt $since } |
Select-Object TimeCreated, Id,
@{N=”ClientIP”;E={$_.Properties[0].Value}},
@{N=”ShareName”;E={$_.Properties[1].Value}} |
Export-Csv “SMB_Audit_Report.csv” -Encoding UTF8 -NoTypeInformation
Schritt 1 — Aktuellen SMB-Status eurer Umgebung prüfen
Bevor ihr irgendetwas ändert: Verschafft euch einen vollständigen Überblick über den Ist-Zustand.
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature, EncryptData# Lokalen SMB-Client-Status prüfen
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
Ausgabe-Interpretation:
| Eigenschaft | True | False |
|---|---|---|
| RequireSecuritySignature | ✓ Signing erzwungen | ✗ Nicht erzwungen |
| EnableSecuritySignature | Signing angeboten | ✗ Deaktiviert |
Domänenweit alle Server abfragen:
$servers = Get-ADComputer -Filter { OperatingSystem -like “*Server*” } |
Select-Object -ExpandProperty Name$results = foreach ($srv in $servers) {
$cfg = Invoke-Command -ComputerName $srv -ScriptBlock {
$s = Get-SmbServerConfiguration
[PSCustomObject]@{
ServerRequire = $s.RequireSecuritySignature
ServerEnable = $s.EnableSecuritySignature
Encrypted = $s.EncryptData
}
} -ErrorAction SilentlyContinue
[PSCustomObject]@{
Server = $srv
SignRequired = $cfg.ServerRequire
SignEnabled = $cfg.ServerEnable
Encrypted = $cfg.Encrypted
}
}
$results | Sort-Object SignRequired | Format-Table -AutoSize
$results | Export-Csv “SMBSigning_Status.csv” -Encoding UTF8 -NoTypeInformation
Schritt 2 — SMB Signing domänenweit per GPO erzwingen
Die sicherste und skalierbarste Methode für Unternehmensumgebungen ist die Durchsetzung via Gruppenrichtlinie. Erstellt eine neue GPO und setzt die folgenden Einstellungen:
| Richtlinie | Empfohlener Wert | Gilt für |
|---|---|---|
| Microsoft-Netzwerkclient: Kommunikation digital signieren (immer) | Aktiviert | SMB-Client (ausgehend) |
| Microsoft-Netzwerkserver: Kommunikation digital signieren (immer) | Aktiviert | SMB-Server (eingehend) |
Alternativ per PowerShell direkt auf einzelnen Servern setzen:
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force# SMB Signing auf dem CLIENT erzwingen (ausgehend)
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force# Status nach Änderung kontrollieren
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Fallstricke in gemischten Umgebungen
NAS-Systeme von Synology, QNAP, NetApp und anderen unterstützen SMB Signing teilweise nur in neueren Firmware-Versionen oder gar nicht. Wenn ein Windows Server 2025-Client (mit erzwungenem Signing) auf einen solchen NAS zugreift und dieser kein Signing unterstützt, schlägt die Verbindung fehl.
Lösung: Firmware der NAS-Geräte aktualisieren. Falls nicht möglich: Ausnahmeregelung per GPO für den betreffenden Share — aber dokumentieren und als temporär behandeln.
SMB Signing ist nicht kompatibel mit Gastzugriffen (ohne Passwort). Wenn ihr SMB Signing erzwingt, werden alle Verbindungen über Gastkonten sofort blockiert — auch wenn sie bisher funktioniert haben.
Lösung: Gastkonten auf Shares eliminieren. Berechtigungen auf authentifizierte Domänenkonten umstellen — das hätte ohnehin längst passieren sollen.
Windows Server 2012 R2 und 2016 unterstützen SMB Signing, haben es aber standardmäßig nicht erzwungen. Sie zeigen im Audit-Log Event IDs 3021/3022, wenn ein 2025-Server Signing erwartet. Diese Systeme müssen explizit konfiguriert werden — oder sie sind das schwächste Glied in eurer Kette.
Wenn Shares über IP-Adressen oder CNAME-DNS-Einträge eingebunden werden, nutzt Windows zwingend NTLM statt Kerberos — und der Session Key ist deutlich schwächer. Konsequenz: SMB Signing ist weniger effektiv als mit Kerberos. Immer Hostnamen (A-Records) nutzen!
Empfohlenes Rollout-Vorgehen: Audit first, enforce later
AuditClientDoesNotSupportSigning = $true auf allen File-Servern setzen. 2–4 Wochen Daten sammeln.Bonus-Härtung: SMB Server Extended Protection for Authentication (EPA)
Get-SmbServerConfiguration | Select-Object EnableSMBQUIC, SmbServerNameHardeningLevel# EPA aktivieren (SPN-Validierung erzwingen)
# 0 = Aus, 1 = Akzeptieren wenn angeboten, 2 = Erzwingen
Set-SmbServerConfiguration -SmbServerNameHardeningLevel 1 -Force# Hinweis: Wert 2 (Enforce) erst nach EPA-Audit aktivieren!
# Sonst können ältere Clients keine Verbindung mehr aufbauen.
Admin-Checkliste: SMB Signing — fertig?
RequireSecuritySignature-Status geprüftFazit: Standard ist nicht gleich ausreichend
Windows Server 2025 erzwingt SMB Signing für ausgehende Verbindungen — das ist ein echter Fortschritt. Aber eingehende Verbindungen, ältere Server im gleichen Netz, NAS-Geräte und Drittanbieter-Software sind weiterhin eure Verantwortung. Mit dem Audit-Modus habt ihr jetzt ein mächtiges Werkzeug, um blinde Flecken zu finden, bevor ihr hart erzwingt.
Wer noch auf Windows Server 2019 oder 2022 läuft, ist besonders gefragt: In eurer Umgebung ist SMB Signing mit hoher Wahrscheinlichkeit noch nicht flächendeckend aktiv. Das Inventur-Skript oben zeigt euch in wenigen Minuten, wo ihr steht.
© 2026 IT-Service Walter — isw-adtools.de
Windows-Administration & IT-Sicherheit für Profis | Euskirchen