Pag-login ng bisita sa SMB sa VPN: hinihingi pa rin ng Windows ang pagkakakilanlan

Ang pagkonekta sa VPN ng opisina ay nagpapalabas sa file server at gayon pa man ay tumatanggi ang share sa pag-access, na nag-uudyok sa konklusyon na sira ang tunnel. Karaniwang hindi. Ang SMB ay nagpapatunay ng bawat session nang hiwalay, at pinaghihigpitan ng Windows nang higit ang tinatanggap nito bilang anonymous na login. Ang landas ng network at ang pagkakakilanlan ng user ay magkaibang pangangailangan, at ang error ay tungkol sa pangalawa.

Bakit hindi mapapalitan ng tunnel ang pagkakakilanlang SMB

Ang pagbabahagi ng subnet sa isang server ay hindi kailanman nangangahulugan ng pahintulot na basahin ang mga file nito; inaalis lamang nito ang problema sa routing. Itinatala ng Windows ang event 31017 kapag hinaharangan ng kliyente nito ang isang hindi secure na pag-login ng bisita, at iyon ay desisyong ginawa sa iyong makina, hindi sa server. Tapat na dinadala ng tunnel ang mga packet ng SMB habang tinatanggihan ang session ng bisita. Ito ang dahilan kung bakit gumagana ang isang laptop sa magkatulad na home network at ang isa ay hindi.

Ituring ang event bilang ebidensya ng isang patakaran, hindi bilang sira ng network. Nasa pagkakakilanlan o sa device ang pagwawasto.

Basahin ang patakaran ng kliyente at ang event ng pagtanggi

Dalawang output ang mabilis na nagtatapos sa tanong: ang epektibong configuration ng kliyente at ang mga kamakailang event ng pagtanggi.

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

Ang maling setting ng bisita na sinamahan ng pangangailangan sa lagda ay nagpapaliwanag sa kabiguan bago ang anumang karagdagang pagsisiyasat. Kinukumpirma ng event log na tinanggihan ng kliyente ang session, hindi na tinanggihan ng server ang credential. Itala ang landas ng share at account na ginamit sa matagumpay na pagtatangka sa ibang makina, dahil ang naka-cache na session ay maaaring magpakita ng dalawang pagsubok na magkapareho kung hindi naman. Linisin ang mga umiiral na koneksyon gamit ang net use bago ihambing, upang ang lumang session ay hindi sumagot para sa bago.

Gumamit ng pinangalanang account at panatilihin ang lagda

Ang matatag na solusyon ay isang account na kilala ng server, na ibinigay nang tahasan, habang ang patakaran sa lagda at encryption ay hinahayaang gaya ng dati. Ibigay ang credential sa koneksyon sa halip na mag-type ng random na pangalan sa dialog.

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

Ang pinangalanang pag-login ay gumagawa ng session na maaaring i-audit ng server, at Get-SmbConnection ipinapakita ang dialect at kung aktibo ang lagda. Hindi matutugunan ng mga session ng bisita ang mga pangangailangan sa lagda o encryption, kaya ang pagpapagana ng bandila ng bisita ay hindi makakasalba sa patakarang nangangailangan ng mga iyon. Kung ang lumang device ay walang modelo ng account, ituring ang access ng bisita bilang tahasang dokumentadong eksepsyon na may planong kapalit. Huwag pahinain ang lagda sa bawat koneksyon para pagbigyan ang isang device.

Kapag kilala lang ng device ang bisita

Ang ilang consumer NAS box ay naglalabas ng mga share na walang anumang konsepto ng account, na nag-iiwan ng dalawang tapat na opsyon: ihiwalay ang device o palitan ito. Ilagay ito sa segment na walang ruta patungo sa anumang sensitibo, at huwag hayaang maging default ng buong kliyente ang isang eksepsyon para sa kaginhawahan. Ang share ng bisita na may backup o credential ay problema sa paglantad ng data, hindi abala ng Windows. Kung ang firmware update ay nagdaragdag ng mga user account, iyon ang mas murang pangmatagalang sagot.

Itala ang tinanggap na account at ang mga halaga ng patakaran sa ticket. Kung hindi, muling patatakbuhin ng susunod na tao ang pagsubok sa tunnel at darating sa parehong pagtanggi.