SMB-gestelogon via VPN: Windows vil stadig have en identitet
En fungerende VPN-tunnel gør ikke et anonymt SMB-logon godkendt. Læs klientpolitikken, bekræft hændelse 31017, og brug derefter en navngivet sharekonto.
Når du logger på kontorets VPN, bliver filserveren tilgængelig, og alligevel afviser sharet adgang, hvilket indbyder til den konklusion, at tunnelen er i stykker. Det er den som regel ikke. SMB godkender hver session for sig, og Windows er blevet strammere med, hvad det accepterer som anonymt logon. En netværkssti og en brugeridentitet er forskellige krav, og det er den anden, fejlen handler om.
Hvorfor tunnelen ikke kan erstatte en SMB-identitet
At dele et subnet med en server har aldrig betydet tilladelse til at læse dens filer; det fjerner kun routingproblemet. Windows registrerer hændelse 31017, når klienten blokerer et usikkert gestelogon, og det er en beslutning, der træffes på din maskine og ikke på serveren. Tunnelen transporterer SMB-pakker trofast, mens gæstesessionen afvises. Derfor virker én bærbar på identiske hjemmenetværk og en anden ikke.
Behandl hændelsen som bevis på en politik, ikke som en netværksfejl. Rettelsen ligger i identiteten eller i enheden.
Læs klientpolitikken og afvisningshændelsen
To output afgør spørgsmålet hurtigt: den effektive klientkonfiguration og de seneste afvisningshændelser.
Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017En falsk gæsteindstilling kombineret med et krav om signering forklarer fejlen, før nogen yderligere undersøgelse er nødvendig. Hændelsesloggen bekræfter, at klienten afviste sessionen, og ikke at serveren afviste en legitimationsoplysning. Notér sharestien og den konto, der blev brugt i et vellykket forsøg på en anden maskine, for en cachet session kan få to tests til at se identiske ud, når de ikke er. Ryd eksisterende forbindelser med net use før du sammenligner, så en gammel session ikke svarer for den nye.
Brug en navngivet konto, og behold signeringen
Den holdbare løsning er en konto, som serveren kender, angivet eksplicit, mens politikken for signering og kryptering lades i fred. Angiv legitimationsoplysningen på forbindelsen i stedet for at skrive et tilfældigt navn i dialogen.
net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnectionEt navngivet logon giver en session, som serveren kan revidere, og Get-SmbConnection viser dialekten og hvorvidt signering er aktiv. Gæstesessioner kan ikke opfylde krav om signering eller kryptering, så et gæsteflag kan ikke redde en politik, der kræver dem. Hvor en ældre enhed ikke har en kontomodel, skal gæsteadgang behandles som en eksplicit dokumenteret undtagelse med en udskiftningsplan. Svækk ikke signeringen for hver forbindelse for at imødekomme én enhed.
Når enheden kun taler gæst
Nogle forbruger-NAS-bokse udstiller shares uden nogen kontobegreb, hvilket efterlader to ærlige muligheder: isolér enheden eller udskift den. Sæt den på et segment uden rute til noget følsomt, og lad ikke en bekvemmelighedsundtagelse blive standarden for hele klienten. Et gæsteshar med sikkerhedskopier eller legitimationsoplysninger er et problem med dataeksponering snarere end en Windows-gener. Hvis en firmwareopdatering tilføjer brugerkonti, er det det billigere langsigtede svar.
Registrér den accepterede konto og politikværdierne i sagen. Ellers vil den næste person køre tunnelstesten igen og nå frem til den samme afvisning.