Windows Server 2025 / SMB-Signierung prüfen und Freigabeverschlüsselung testen

Die Signierung des Server-Message-Block-Protokolls (SMB) schützt die Integrität von Nachrichten; SMB-Verschlüsselung schützt den übertragenen Inhalt. Prüfen Sie bei Verbindungsfehlern zuerst Servernamen, Identität, Protokollunterstützung und die tatsächlich ausgehandelte Verbindung.

Signierung, Verschlüsselung und Berechtigungen unterscheiden

Signiert bedeutet nicht automatisch verschlüsselt. Verschlüsselter Netzwerkverkehr korrigiert weder zu weit gefasste Dateirechte noch verschlüsselt er gespeicherte Dateien auf dem Datenträger. Die spezielle Dokumentation zur SMB-Signierung unterscheidet die ausgehende Anforderung von Windows Server 2025: Beim Zugriff auf einen anderen Server ist FS1 selbst SMB-Client. Übertragen Sie diese Vorgabe nicht pauschal auf eingehende Verbindungen jeder Serverrolle. Gruppenrichtlinienobjekte (GPO) und die Rolle des Computers können die wirksame Konfiguration beeinflussen. NTFS steht für New Technology File System; dessen Dateirechte wirken zusammen mit den Freigaberechten.

Anforderungen vor einer Änderung abfragen

Öffnen Sie auf FS1 PowerShell mit erhöhten Rechten. Untersuchen Sie den SMB-Client für Zugriffe auf andere Server getrennt vom SMB-Server, der eigene Dateien bereitstellt. Verwenden Sie LabRead aus der Übung zu SMB- und NTFS-Berechtigungen. Prüfen Sie den tatsächlichen Pfad und lesen Sie zunächst mit dem Testbenutzer eine bekannte Datei. Fehlt die Freigabe oder scheitert bereits dieser Zugriff, beheben Sie zuerst die Ursache:

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EncryptData,RejectUnencryptedAccess
Get-SmbShare -Name 'LabRead' | Select-Object Name,Path,EncryptData

RequireSecuritySignature zeigt eine Signierungsanforderung, nicht den Schutz jeder einzelnen Sitzung. EncryptData betrifft je nach Abfrage den Server oder die Freigabe; RejectUnencryptedAccess regelt die Zurückweisung nicht verschlüsselungsfähiger Zugriffe im zugehörigen Kontext. Ändern Sie diese globalen Werte hier nicht. Die Übersicht zur SMB-Sicherheitshärtung beschreibt neue Funktionen; für Signierung je Richtung verwenden Sie die spezielle Dokumentation und die tatsächlichen Einstellungen. Eine zusätzliche Verschlüsselungsanforderung des Clients wird von dieser Spaltenauswahl nicht angezeigt.

Verschlüsselung nur für die Testfreigabe aktivieren

Arbeiten Sie nur mit LabRead im isolierten Labor und einer gültigen Domänenidentität. Schließen Sie offene Dateien. Führen Sie zunächst die Zuweisung an $previousEncryption aus, prüfen Sie den booleschen Wert und notieren Sie ihn zusätzlich außerhalb der Sitzung. Damit bleibt die Wiederherstellung möglich, wenn das Fenster geschlossen wird. Wiederholen Sie die Zuweisung nach dem Einschalten nicht: Sonst überschreiben Sie den ursprünglichen Wert. Führen Sie die weiteren Zeilen einzeln aus, bestätigen Sie gegebenenfalls die Änderung genau dieser Freigabe und halten Sie bei einem Fehler an:

$previousEncryption = (Get-SmbShare -Name 'LabRead').EncryptData
Set-SmbShare -Name 'LabRead' -EncryptData $true
Get-SmbShare -Name 'LabRead' | Select-Object Name,EncryptData

Die letzte Abfrage muss LabRead mit EncryptData=True zeigen. SMB-Verschlüsselung setzt Unterstützung auf beiden Seiten voraus; die bloße Angabe SMB 3.x bei einem Gerät beweist noch keine passende Verschlüsselungsfunktion. Behalten Sie globale Richtlinien einschließlich der Ablehnung unverschlüsselter Zugriffe bei. Besteht im Labor bereits eine Ausnahme, die den Nachweis verhindert, klären Sie diese vor dem Test. Speichern Sie die Arbeit und schließen Sie nur die betroffenen Clientverbindungen, bevor Sie den normalen Servernamen erneut verwenden. Halten andere Anwendungen noch eine FS1-Sitzung offen, stimmen Sie deren Schließen ab; ein geschlossenes Explorer-Fenster allein beweist keine neue Verbindung. Trennen Sie nicht pauschal alle Netzlaufwerke.

Öffnen Sie auf CLIENT1 als derselbe Domänenbenutzer \\fs1.ad.example.test\LabRead und lesen Sie die bekannte Datei. Führen Sie die folgende Abfrage auf diesem Client im Kontext der Verbindung aus. Eine Konsole mit anderen Anmeldeinformationen kann andere Sitzungen anzeigen:

Get-SmbConnection | Where-Object ShareName -eq 'LabRead' | Select-Object ServerName,ShareName,Dialect,Encrypted

Prüfen Sie neben ShareName auch ServerName: Der Filter wählt nur LabRead aus und kann gleichnamige Freigaben mehrerer Server liefern. In der Zeile für fs1.ad.example.test muss Dialect eine unterstützte SMB-3.x-Version und Encrypted den Wert True zeigen. Die Referenz zu Get-SmbConnection erklärt die Zuordnung zu Benutzer und Anmeldeinformationen. Fehlt die Zeile, prüfen Sie den tatsächlichen Dateizugriff und den Abfragekontext. Bei Encrypted=False ist Verschlüsselung noch nicht nachgewiesen; untersuchen Sie bestehende Sitzungen, Ziel und Richtlinien. Die Abfrage zeigt keinen Signed-Status. Leserechte werden durch Verschlüsselung nicht zu Schreibrechten.

Kompatibilitäts- und Anmeldefehler unterscheiden

Verwenden Sie in der Domäne den korrekten Servernamen und nach Möglichkeit Kerberos. Umgehen Sie Identitätsprobleme nicht mit IP-Adressen oder beliebigen Aliasnamen. Prüfen Sie bei älterem netzgebundenem Speicher (Network Attached Storage, NAS) Updates, authentifizierte Konten sowie Signierungs- und Verschlüsselungsunterstützung. Erwägen Sie bei fehlender Kompatibilität Austausch oder Trennung vom übrigen Netz. Schalten Sie nicht als schnelle Lösung global die Signierung ab und aktivieren Sie weder unsicheren Gastzugriff noch SMB1.

Öffnen Sie die Ereignisanzeige → Anwendungs- und Dienstprotokolle → Microsoft → Windows. Untersuchen Sie passende SMBClient-Kanäle auf CLIENT1 und SMBServer-Kanäle auf FS1 zum gleichen Fehlerzeitpunkt. Notieren Sie Fehlercode, vollständigen Meldungstext, Computer, Freigabe und Konto; veröffentlichen Sie keine Zugangsdaten. Vergleichen Sie diese Angaben mit der Tabelle: „Zugriff verweigert“ kann sowohl mit Berechtigungen als auch mit Sicherheitsverhandlungen zusammenhängen. Ordnen Sie Ereignisse und Konfiguration einander zu, bevor Sie eine einzelne Ursache korrigieren und denselben Lesezugriff wiederholen.

Nur die Änderung des Tests zurücksetzen

Stellen Sie nach dem Vergleich in derselben FS1-PowerShell-Sitzung genau den gespeicherten Wert wieder her. Prüfen Sie vorher, ob die Variable noch den ursprünglichen booleschen Wert enthält. Ist sie verloren gegangen, verwenden Sie die vorherige Notiz, statt zu raten. Eine ursprünglich verschlüsselte Freigabe darf nicht versehentlich unverschlüsselt zurückbleiben:

Set-SmbShare -Name 'LabRead' -EncryptData $previousEncryption

Kontrollieren Sie EncryptData erneut mit der vorherigen Abfrage. Bauen Sie die CLIENT1-Verbindung neu auf, lesen Sie dieselbe Datei und prüfen Sie Encrypted. War der Anfangswert True, muss er True bleiben. War er False, können die Verschlüsselungsanforderung des Clients oder andere Richtlinien die Sitzung weiterhin verschlüsseln. Lockern Sie keine globale Richtlinie, um einen Vergleichswert zu erzwingen. Für den Produktiveinsatz bewerten Sie Datenbedarf, Kompatibilität, im eigenen Umfeld gemessene Leistung und Wiederherstellungszugang. Dieser Test misst keine Leistung und ersetzt keine Berechtigungsprüfung.