SMB vendégbejelentkezés VPN-en át: a Windows még mindig identitást kér

Az irodai VPN-hez csatlakozva a fájlkiszolgáló elérhetővé válik, a megosztás mégis megtagadja a hozzáférést, ami arra a következtetésre csábít, hogy az alagút hibás. Általában nem az. Az SMB minden munkamenetet külön hitelesít, a Windows pedig egyre szigorúbban szabályozza, mit fogad el anonim bejelentkezésként. A hálózati útvonal és a felhasználói identitás különböző követelmények, és a hiba az utóbbiról szól.

Miért nem helyettesítheti az alagút az SMB-identitást

Az alhálózat megosztása egy kiszolgálóval soha nem jelentett engedélyt a fájljai olvasására; csak az útválasztási problémát szünteti meg. A Windows 31017 eseményt rögzít, amikor az ügyfele blokkol egy nem biztonságos vendégbejelentkezést, és ez a döntés az Ön gépén születik, nem a kiszolgálón. Az alagút hűen továbbítja az SMB-csomagokat, miközben a vendégmunkamenet elutasításra kerül. Ezért működik az egyik laptop azonos otthoni hálózatokon, a másik pedig nem.

Tekintse az eseményt egy házirend bizonyítékának, nem hálózati hibának. A javítás az identitásban vagy az eszközben rejlik.

Olvassa el az ügyfél házirendjét és az elutasítási eseményt

Két kimenet gyorsan eldönti a kérdést: az érvényes ügyfélkonfiguráció és a legutóbbi elutasítási események.

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

Egy hamis vendégbeállítás és egy aláírási követelmény együtt megmagyarázza a hibát bármilyen további vizsgálat előtt. Az eseménynapló megerősíti, hogy az ügyfél utasította el a munkamenetet, és nem a kiszolgáló utasított el egy hitelesítő adatot. Jegyezze fel a megosztás útvonalát és a másik gépen sikeres kísérletben használt fiókot, mert egy gyorsítótárazott munkamenet két tesztet azonossá tehet, amikor azok nem azok. Törölje a meglévő kapcsolatokat a következővel: net use az összehasonlítás előtt, hogy egy régi munkamenet ne válaszoljon az új helyett.

Használjon elnevezett fiókot, és tartsa meg az aláírást

A tartós megoldás egy olyan fiók, amelyet a kiszolgáló ismer, kifejezetten megadva, miközben az aláírási és titkosítási házirend érintetlen marad. A hitelesítő adatot a kapcsolaton adja meg, ahelyett hogy véletlenszerű nevet írna a párbeszédpanelbe.

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

Az elnevezett bejelentkezés olyan munkamenetet hoz létre, amelyet a kiszolgáló naplózhat, és Get-SmbConnection megmutatja a dialektust és azt, hogy az aláírás aktív-e. A vendégmunkamenetek nem tudják teljesíteni az aláírási vagy titkosítási követelményeket, így egy vendégjelző bekapcsolása nem mentheti meg az ezeket megkövetelő házirendet. Ahol egy régi eszköznek nincs fiókmodellje, kezelje a vendéghozzáférést kifejezetten dokumentált kivételként, csereforgatókönyvvel. Ne gyengítse az aláírást minden kapcsolatnál egyetlen eszköz kedvéért.

Amikor az eszköz csak vendéget ismer

Egyes fogyasztói NAS-dobozok fiókfogalom nélküli megosztásokat kínálnak, ami két őszinte lehetőséget hagy: izolálja vagy cserélje le az eszközt. Tegye olyan szegmensbe, ahonnan nincs útvonal semmi érzékenyhez, és ne engedje, hogy egy kényelmi kivétel az egész ügyfél alapértelmezésévé váljon. A biztonsági mentéseket vagy hitelesítő adatokat tartalmazó vendégmegosztás adatkiszivárgási probléma, nem Windows-idegeskedés. Ha egy firmware-frissítés felhasználói fiókokat ad hozzá, az az olcsóbb hosszú távú válasz.

Rögzítse az elfogadott fiókot és a házirend értékeit a jegyben. Különben a következő személy újra lefuttatja az alagút tesztjét, és ugyanahhoz az elutasításhoz jut.