Autentificare oaspete SMB prin VPN: Windows cere în continuare o identitate

Conectarea la VPN-ul biroului face serverul de fișiere accesibil și totuși partajarea refuză în continuare accesul, ceea ce duce la concluzia că tunelul este defect. De obicei nu este. SMB autentifică fiecare sesiune separat, iar Windows a înăsprit constant ceea ce acceptă ca autentificare anonimă. O cale de rețea și o identitate de utilizator sunt cerințe diferite, iar eroarea se referă la a doua.

De ce tunelul nu poate înlocui o identitate SMB

Partajarea unei subrețele cu un server nu a însemnat niciodată permisiunea de a-i citi fișierele; elimină doar problema de rutare. Windows înregistrează evenimentul 31017 când clientul său blochează o autentificare oaspete nesigură, iar aceasta este o decizie luată pe mașina dumneavoastră, nu pe server. Tunelul transportă fidel pachetele SMB în timp ce sesiunea oaspete este refuzată. De aceea un laptop funcționează în rețele de acasă identice, iar altul nu.

Tratați evenimentul ca dovadă a unei politici, nu ca o defecțiune de rețea. Corectarea ține de identitate sau de aparat.

Citiți politica clientului și evenimentul de refuz

Două ieșiri lămuresc repede întrebarea: configurația efectivă a clientului și evenimentele recente de refuz.

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

O setare oaspete falsă împreună cu o cerință de semnătură explică eșecul înainte de orice investigație suplimentară. Jurnalul de evenimente confirmă că clientul a refuzat sesiunea, nu că serverul a refuzat o acreditare. Notați calea partajării și contul folosite într-o încercare reușită pe altă mașină, deoarece o sesiune din cache poate face două teste să pară identice când nu sunt. Ștergeți conexiunile existente cu net use înainte de comparare, ca o sesiune veche să nu răspundă în locul celei noi.

Folosiți un cont cu nume și păstrați semnătura

Soluția durabilă este un cont pe care serverul îl cunoaște, furnizat explicit, cu politica de semnătură și criptare lăsată neatinsă. Furnizați acreditarea pe conexiune în loc să tastați un nume aleatoriu în dialog.

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

O autentificare cu nume produce o sesiune pe care serverul o poate audita, iar Get-SmbConnection arată dialectul și dacă semnătura este activă. Sesiunile oaspete nu pot satisface cerințele de semnătură sau criptare, deci activarea unui steag oaspete nu poate salva o politică ce le impune. Acolo unde un aparat vechi nu are model de conturi, tratați accesul oaspete ca o excepție explicită și documentată, cu un plan de înlocuire. Nu slăbiți semnătura pe fiecare conexiune pentru a acomoda un singur dispozitiv.

Când aparatul cunoaște doar oaspete

Unele carcase NAS de consum expun partajări fără nicio noțiune de cont, ceea ce lasă două opțiuni oneste: izolați aparatul sau înlocuiți-l. Puneți-l într-un segment fără rută către nimic sensibil și nu lăsați o excepție de confort să devină implicitul pentru întregul client. O partajare oaspete cu copii de siguranță sau acreditări este o problemă de expunere a datelor, nu o pacoste a Windows. Dacă o actualizare de firmware adaugă conturi de utilizator, acesta este răspunsul mai ieftin pe termen lung.

Înregistrați contul acceptat și valorile politicii în tichet. Altfel următoarea persoană va rula din nou testul tunelului și va ajunge la același refuz.