Log masuk tetamu SMB melalui VPN: Windows masih mahukan identiti

Menyertai VPN pejabat menjadikan pelayan fail boleh dicapai dan perkongsian masih enggan memberi akses, yang menggalakkan kesimpulan bahawa terowong rosak. Biasanya ia tidak. SMB mengesahkan setiap sesi secara berasingan, dan Windows semakin mengetatkan apa yang diterimanya sebagai log masuk tanpa nama. Laluan rangkaian dan identiti pengguna ialah dua keperluan yang berbeza, dan ralat itu mengenai yang kedua.

Mengapa terowong tidak boleh menggantikan identiti SMB

Berkongsi subnet dengan pelayan tidak pernah bermakna kebenaran membaca failnya; ia hanya menghapuskan masalah penghalaan. Windows merekodkan peristiwa 31017 apabila kliennya menyekat log masuk tetamu yang tidak selamat, dan itu keputusan yang dibuat pada mesin anda, bukan pada pelayan. Terowong membawa paket SMB dengan setia sementara sesi tetamu ditolak. Itulah sebabnya satu komputer riba pada rangkaian rumah yang sama berfungsi dan satu lagi tidak.

Anggap peristiwa itu sebagai bukti dasar, bukan kerosakan rangkaian. Pembetulan terletak pada identiti atau pada peranti.

Baca dasar klien dan peristiwa penolakan

Dua output menyelesaikan persoalan dengan cepat: konfigurasi klien yang berkesan dan peristiwa penolakan terkini.

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

Tetapan tetamu palsu digabungkan dengan keperluan tandatangan menjelaskan kegagalan sebelum sebarang siasatan lanjut. Log peristiwa mengesahkan klien menolak sesi itu, bukan pelayan menolak kelayakan. Catat laluan kongsi dan akaun yang digunakan dalam percubaan berjaya pada mesin lain, kerana sesi yang dicache boleh membuat dua ujian kelihatan serupa sedangkan ia tidak. Kosongkan sambungan sedia ada dengan net use sebelum membandingkan, supaya sesi lama tidak menjawab bagi yang baharu.

Gunakan akaun bernama dan kekalkan tandatangan

Pembetulan yang tahan lama ialah akaun yang dikenali pelayan, diberikan secara eksplisit, dengan dasar tandatangan dan penyulitan dibiarkan seperti sedia ada. Berikan kelayakan pada sambungan dan bukannya menaip nama rawak dalam dialog.

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

Log masuk bernama menghasilkan sesi yang boleh diaudit oleh pelayan, dan Get-SmbConnection menunjukkan dialek dan sama ada tandatangan aktif. Sesi tetamu tidak dapat memenuhi keperluan tandatangan atau penyulitan, jadi mendayakan bendera tetamu tidak dapat menyelamatkan dasar yang menuntutnya. Jika peranti lama tiada model akaun, anggap akses tetamu sebagai pengecualian eksplisit yang didokumenkan dengan pelan penggantian. Jangan lemahkan tandatangan pada setiap sambungan semata-mata untuk satu peranti.

Apabila peranti hanya mengenal tetamu

Sesetengah kotak NAS pengguna mendedahkan perkongsian tanpa sebarang konsep akaun, yang meninggalkan dua pilihan jujur: asingkan peranti atau gantikannya. Letakkan pada segmen tanpa laluan ke apa-apa yang sensitif, dan jangan biarkan pengecualian kemudahan menjadi lalai untuk seluruh klien. Perkongsian tetamu yang menyimpan sandaran atau kelayakan ialah masalah pendedahan data, bukan gangguan Windows. Jika kemas kini firmware menambah akaun pengguna, itulah jawapan jangka panjang yang lebih murah.

Catat akaun yang diterima dan nilai dasar dalam tiket. Jika tidak, orang seterusnya akan menjalankan semula ujian terowong dan sampai pada penolakan yang sama.