SMB-Gastanmeldung über VPN: Windows will weiterhin eine Identität

Wer sich mit dem Büro-VPN verbindet, erreicht den Dateiserver und erlebt dennoch, dass die Freigabe den Zugriff verweigert, was zu dem Schluss verleitet, der Tunnel sei defekt. Meistens ist er es nicht. SMB authentifiziert jede Sitzung einzeln, und Windows verschärft laufend, was es als anonyme Anmeldung akzeptiert. Ein Netzwerkpfad und eine Benutzeridentität sind verschiedene Anforderungen, und um die zweite geht es bei dem Fehler.

Warum der Tunnel keine SMB-Identität ersetzen kann

Ein Subnetz mit einem Server zu teilen bedeutete noch nie, dessen Dateien lesen zu dürfen; es beseitigt nur das Routingproblem. Windows protokolliert Ereignis 31017, wenn sein Client eine unsichere Gastanmeldung blockiert, und das ist eine Entscheidung auf Ihrem Rechner und nicht auf dem Server. Der Tunnel überträgt SMB-Pakete zuverlässig, während die Gastsitzung abgelehnt wird. Deshalb funktioniert ein Laptop in identischen Heimnetzen und ein anderer nicht.

Betrachten Sie das Ereignis als Beleg für eine Richtlinie, nicht als Netzwerkfehler. Die Behebung liegt in der Identität oder im Gerät.

Lesen Sie die Client-Richtlinie und das Ablehnungsereignis

Zwei Ausgaben klären die Frage schnell: die effektive Client-Konfiguration und die jüngsten Ablehnungsereignisse.

Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017

Eine falsche Gast-Einstellung zusammen mit einer Signaturanforderung erklärt den Fehler, bevor irgendwelche weiteren Untersuchungen nötig sind. Das Ereignisprotokoll bestätigt, dass der Client die Sitzung abgelehnt hat und nicht der Server eine Anmeldeinformation. Notieren Sie den Freigabepfad und das Konto aus einem erfolgreichen Versuch auf einem anderen Rechner, denn eine zwischengespeicherte Sitzung kann zwei Tests identisch aussehen lassen, obwohl sie es nicht sind. Löschen Sie bestehende Verbindungen mit net use vor dem Vergleich, damit eine alte Sitzung nicht für die neue antwortet.

Verwenden Sie ein benanntes Konto und behalten Sie die Signierung bei

Die dauerhafte Lösung ist ein Konto, das der Server kennt, ausdrücklich angegeben, während die Richtlinie für Signierung und Verschlüsselung unangetastet bleibt. Übergeben Sie die Anmeldeinformation an der Verbindung, statt einen beliebigen Namen in den Dialog zu tippen.

net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnection

Eine benannte Anmeldung erzeugt eine Sitzung, die der Server prüfen kann, und Get-SmbConnection zeigt den Dialekt und ob die Signierung aktiv ist. Gastsitzungen können Anforderungen an Signierung oder Verschlüsselung nicht erfüllen, daher kann ein Gast-Flag eine Richtlinie, die sie verlangt, nicht retten. Wo ein Altgerät kein Kontomodell hat, behandeln Sie den Gastzugriff als ausdrücklich dokumentierte Ausnahme mit einem Ersetzungsplan. Schwächen Sie die Signierung nicht für jede Verbindung ab, um einem einzigen Gerät entgegenzukommen.

Wenn das Gerät nur Gast spricht

Manche Consumer-NAS-Gehäuse bieten Freigaben ohne Kontobegriff an, was zwei ehrliche Optionen lässt: das Gerät isolieren oder ersetzen. Stellen Sie es in ein Segment ohne Route zu irgendetwas Sensiblem und lassen Sie eine Bequemlichkeitsausnahme nicht zum Standard für den gesamten Client werden. Eine Gastfreigabe mit Sicherungen oder Anmeldeinformationen ist ein Problem der Datenoffenlegung und kein Windows-Ärgernis. Wenn ein Firmware-Update Benutzerkonten hinzufügt, ist das die günstigere langfristige Antwort.

Halten Sie das akzeptierte Konto und die Richtlinienwerte im Ticket fest. Sonst führt die nächste Person den Tunneltest erneut aus und kommt zur selben Ablehnung.