Dasar Kumpulan tiada pada VPN? Semak skop sebelum terowong

Sesuatu yang digunakan pada rangkaian pejabat berhenti digunakan pada minggu pengguna mula bekerja melalui VPN, dan terowong dipersalahkan sebelum sesiapa membuka laporan. Dasar Kumpulan menentukan tetapan mana yang sampai kepada pengguna dan komputer Windows, mengambil bahan daripada domain dan menjalankan pemprosesan di sebelah klien, dan ketiga-tiga langkah itu gagal dengan tiga cara berbeza. Terowong hanya menukar laluan yang dimiliki klien. Menjalankan semakan mengikut urutan mengelakkan masalah kebenaran fail dikejar sebagai masalah penghalaan.

Mulakan dengan tetapan, bukan terowong

Catat satu GPO yang dijangka dan satu tetapan konkrit di dalamnya, kemudian tentukan sama ada tetapan itu berada dalam Konfigurasi Pengguna atau Konfigurasi Komputer. Ini menganggap klien Windows sah yang menyertai domain pada VPN yang diluluskan, bukan peranti tidak diurus atau hanya awan yang dijadikan ahli domain. Jawapan skop menentukan siapa boleh membaca hasil dan sama ada penaikan hak diperlukan, jadi selesaikannya sebelum menjalankan apa-apa.

Tanya pentadbir domain pautan, lokasi objek, penapis keselamatan dan penapis WMI yang sepatutnya berkuat kuasa. Menukar kawalan itu supaya ujian lulus ialah projek lain dengan pemilik lain.

Baca laporan dengan akaun yang memiliki tetapan itu

Dalam sesi pengguna terjejas sendiri, jalankan whoami /user dan kemudian gpresult /scope user /r. Akaun yang mengesahkan VPN bukan secara automatik akaun Windows yang dasarnya anda baca, dan semakan daripada akaun pentadbir menjawab soalan yang berbeza. Simpan garis dasar di bawah nama fail baharu, seperti %TEMP%\vpn-policy-user-before.html. rujukan gpresult mendokumenkan suis skop dan output, dan elok diketahui bahawa menjana laporan tidak menyegarkan apa-apa.

Dasar komputer mempunyai skop dan konteks kebenaran tersendiri, jadi periksanya secara berasingan dengan penaikan yang diperlukan. Menggabungkan kedua-dua skop dalam satu laporan ialah cara tetapan pengguna diisytiharkan hilang sedangkan ia tidak pernah berada dalam skop itu.

Penemuan bukan akses: rekod SRV dahulu, kemudian SMB

Dengan VPN yang diluluskan disambungkan, sahkan bahawa klien menyelesaikan pengawal domain melalui laluan DNS yang dimaksudkan; laman web awam yang dimuatkan tidak mengatakan apa-apa tentang penemuan pengawal. Bagi domain contoh corp.example, nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example menjawab soalan yang benar-benar anda ada. Rekod perkhidmatan yang dikembalikan hanyalah bukti penemuan, kerana alamat pengawal yang dipilih masih perlu boleh dicapai dengan pengesahan yang diperlukan dan perkhidmatan direktori yang dibenarkan. Bahan dasar kemudian datang dari SYSVOL, iaitu bacaan SMB terhadap pengawal tertentu itu dan bukan ujian ICMP.

Bukti yang lebih lemah mudah disalah anggap sebagai bukti. Balasan ICMP daripada pengawal, di sebelah bacaan templat dasar yang ditolak, menghasilkan laporan yang kelihatan kosong atas sebab yang belum disambungkan oleh sesiapa.

Kekalkan kebenaran perkhidmatan AD, laluan pulangan dan penyegerakan masa penggunaan secara konsisten dan bukannya menggantikannya dengan pembukaan tembok api menyeluruh atau pelayan DNS awam. Data dasar yang berbeza antara pengawal ialah persoalan replikasi bagi pemilik direktori.

Satu muat semula, dua laporan, satu perbandingan

Setelah laluan terbukti, minta muat semula yang berkaitan dengan gpupdate /target:user dan baca hasilnya dan bukannya menganggapnya. Muat semula lalai menggunakan dasar yang berubah manakala /force meminta penggunaan semula; kedua-duanya tidak membaiki DNS, kebenaran fail atau penapisan. Sesetengah sambungan hanya selesai pada log masuk kemudian atau peristiwa latar hadapan lain, jadi satu larian bukan keputusan. Menambah suis log keluar atau mula semula pada sesi pengguna jauh sebagai diagnostik rutin membuang apa yang terbuka.

Jana laporan kedua di bawah nama fail berbeza dan bandingkan masa pemprosesan, GPO yang dijangka, statusnya yang digunakan atau ditolak dan tetapan itu sendiri. Laporan daripada sesi berjaya terdahulu tidak membuktikan apa-apa tentang muat semula ini. Dasar yang ditapis menunjukkan kebolehgunaan dan bukannya pengangkutan, yang menukar siapa memiliki langkah seterusnya.

Ikat kegagalan kepada satu aktiviti sahaja

Dalam Penampil Peristiwa, mulakan dengan amaran atau ralat Dasar Kumpulan dalam log Sistem, kemudian beralih ke log operasi GroupPolicy di bawah Log Aplikasi dan Perkhidmatan. Tapis log operasi itu mengikut pengecam aktiviti muat semula yang baru anda jalankan, kerana muat semula baharu mendapat pengecam baharu dan mencampurkannya dengan peristiwa semalam menghasilkan kesimpulan yang yakin tetapi salah. Catat masa, konteks pengguna atau komputer, pengawal yang dipilih, GPO, kod ralat dan kebergantungan yang gagal.

Catatan itulah yang boleh ditindaklanjuti oleh pemilik rangkaian atau direktori. Bersambung ke VPN dan menjalankan gpupdate beberapa kali bukan bukti, dan kedua-duanya tidak bertahan dalam penyerahan.

Kekalkan laporan HTML sebagai peribadi, kerana ia mendedahkan nama dalaman, keahlian kumpulan dan konfigurasi keselamatan. Setelah tetapan disahkan, buang kebenaran sementara yang anda tambah dan bukannya membiarkannya.