SMB-gastaanmelding via VPN: Windows wil nog steeds een identiteit

Verbinding maken met de VPN van kantoor maakt de fileserver bereikbaar en toch blijft de share toegang weigeren, wat de conclusie uitlokt dat de tunnel stuk is. Meestal is dat niet zo. SMB authenticeert elke sessie afzonderlijk en Windows wordt steeds strenger in wat het als anonieme aanmelding accepteert. Een netwerkpad en een gebruikersidentiteit zijn verschillende vereisten, en het is de tweede waar de fout over gaat.

Waarom de tunnel geen SMB-identiteit kan vervangen

Een subnet delen met een server betekende nooit toestemming om de bestanden te lezen; het haalt alleen het routeringsprobleem weg. Windows registreert gebeurtenis 31017 wanneer zijn client een onveilige gastaanmelding blokkeert, en dat is een beslissing op jouw machine en niet op de server. De tunnel vervoert SMB-pakketten trouw terwijl de gastsessie wordt geweigerd. Daarom werkt de ene laptop op identieke thuisnetwerken en de andere niet.

Behandel de gebeurtenis als bewijs van beleid, niet als netwerkstoring. De oplossing zit in de identiteit of in het apparaat.

Lees het clientbeleid en de weigeringsgebeurtenis

Twee uitvoerwaarden beslechten de vraag snel: de effectieve clientconfiguratie en de recente weigeringsgebeurtenissen.

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

Een onjuiste gastinstelling in combinatie met een ondertekeningsvereiste verklaart de fout voordat verder onderzoek nodig is. Het gebeurtenislogboek bevestigt dat de client de sessie weigerde en niet dat de server een referentie weigerde. Noteer het sharepad en het account dat bij een geslaagde poging op een andere machine is gebruikt, want een gecachte sessie kan twee tests identiek laten lijken terwijl ze dat niet zijn. Wis bestaande verbindingen met net use voordat je vergelijkt, zodat een oude sessie niet voor de nieuwe antwoordt.

Gebruik een benoemd account en houd de ondertekening

De blijvende oplossing is een account dat de server kent, expliciet opgegeven, met het beleid voor ondertekening en versleuteling ongewijzigd. Geef de referentie op de verbinding in plaats van een willekeurige naam in het dialoogvenster te typen.

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

Een benoemde aanmelding levert een sessie op die de server kan auditen, en Get-SmbConnection toont de dialect en of ondertekening actief is. Gastsessies kunnen niet aan ondertekenings- of versleutelingsvereisten voldoen, dus een gastvlag inschakelen kan een beleid dat die eist niet redden. Waar een oud apparaat geen accountmodel heeft, behandel gasttoegang als een expliciet gedocumenteerde uitzondering met een vervangingsplan. Verzwak de ondertekening niet voor elke verbinding om één apparaat tegemoet te komen.

Wanneer het apparaat alleen gast kent

Sommige consumenten-NAS-boxen bieden shares zonder enig accountbegrip, wat twee eerlijke opties laat: het apparaat isoleren of vervangen. Zet het op een segment zonder route naar iets gevoeligs en laat een gemaksuitzondering niet de standaard voor de hele client worden. Een gastshare met back-ups of referenties is een probleem van gegevensblootstelling en geen Windows-ergernis. Als een firmware-update gebruikersaccounts toevoegt, is dat het goedkopere antwoord op lange termijn.

Leg het geaccepteerde account en de beleidswaarden vast in het ticket. Anders voert de volgende persoon de tunneltest opnieuw uit en komt bij dezelfde weigering uit.