Menambahkan pengguna ke grup VPN tidak memberi akses dengan sendirinya
Keanggotaan grup adalah satu syarat, bukan izin. Periksa apa yang benar-benar dicocokkan gateway, baca catatan terima atau tolak, dan uji kedua hasilnya.
Akun ada di grup yang benar, login berhasil, namun koneksi tetap ditolak atau tersambung tanpa mencapai apa pun. Menambah grup sampai ada yang longgar membuat organisasi memberi jauh lebih banyak dari yang diminta tiket. Keanggotaan grup hanya satu masukan otorisasi, bukan keputusannya: gateway mengumpulkan fakta sesi, mencocokkannya dengan kebijakan berurutan, lalu memutuskan. Bila syarat lain gagal, mengubah grup hanya mengubah paparan.
Keanggotaan grup adalah syarat, bukan izin
Di RADIUS grup adalah atribut otorisasi, dan atribut menggambarkan sesi, bukan mengizinkannya. Server menjawab Access-Accept atau Access-Reject; saat menerima ia dapat melampirkan Filter-Id, Class, atau atribut terowongan RFC 2868, dan perangkat seberang menafsirkannya menurut vendornya. Tidak ada pemetaan grup ke akses penuh; itu ditulis oleh penyusun kebijakan di gateway atau server akses jaringan.
Karena itu nama grup yang sama berperilaku berbeda di dua sistem. Microsoft NPS menyusun kebijakan dari syarat, batasan, dan pengaturan lalu menilainya berurutan. OpenVPN Access Server punya model grup dan aturan sendiri, sedangkan server OpenVPN komunitas sering menyerahkan semuanya ke skrip client-connect atau berkas client-config-dir.
Aturan yang cocok yang menentukan, bukan grup yang diharapkan
Sebagian besar mesin berhenti pada kebijakan pertama yang cocok atau yang paling spesifik. Bila kebijakan 3 menolak dan kebijakan 7 mengizinkan, sesi bisa gagal sebelum mencapai aturan yang meloloskannya. Urutan adalah pengaturan nyata di NPS dan bergeser seiring tahun.
Syarat yang menyertai grup adalah separuh lainnya: postur perangkat, metode autentikasi, MFA selesai, jaringan sumber, subjek sertifikat, atau jendela waktu. Bila satu tidak terpenuhi, kebijakan tidak cocok, mesin jatuh, dan penolakan bawaan berlaku. Dari sisi pengguna grup tampak diabaikan; dari sisi mesin grup tak pernah ditanya.
Detail direktori menciptakan ilusi sama. Kebijakan atas keanggotaan grup Windows membaca SID di token, dan hanya grup keamanan terdaftar; grup distribusi tak pernah muncul. Grup utama ada di bidangnya sendiri, bukan daftar, sehingga kebijakan yang dipatok ke sana bisa gagal diam-diam.
Baca catatan terima atau tolak sebelum menyentuh grup
Tanyakan dulu: apakah permintaan sampai ke tahap otorisasi? Di NPS jawabannya di log peristiwa, tempat 6272 mencatat akses diberikan, 6273 penolakan, dan 6274 permintaan yang dibuang sebelum kebijakan dinilai. Tiga angka itu membagi masalah menjadi tiga penyelidikan, dan hanya satu soal grup.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
Bila log tak terjangkau, tanyakan langsung ke server. Balasan tanpa Filter-Id dan tanpa atribut terowongan berarti server menganggap sesi biasa dan gateway memakai aturannya sendiri. Balasan dengan atribut yang tak diterapkan titik penegakan adalah kesalahan lain: otorisasi lolos dan perangkat mengabaikan hasilnya.
radtest alice 'password' 10.0.0.5 0 testing123Bandingkan atribut yang dikembalikan dengan yang didokumentasikan gateway, bukan dengan yang disiratkan nama grup. Itu biasanya memisahkan masalah kebijakan dari masalah penegakan.
Perubahan grup tidak berlaku surut
Atribut otorisasi dikembalikan sekali, saat sesi diautentikasi. Gateway menyimpannya dan tidak membaca ulang direktori tiap paket, karena itu sesi lama tetap berjalan setelah seseorang dikeluarkan dari grup, dan sesi baru bisa gagal.
Agar perubahan berlaku perlu keputusan otorisasi baru, bukan hanya kunci baru. Bila server mendukung RFC 5176, Disconnect-Request atau CoA-Request ke UDP 3799 memaksa penilaian ulang; jika tidak, putuskan klien dan biarkan menyambung lagi. Negosiasi ulang hanya menyegarkan kunci terowongan.
Perbaiki syaratnya, bukan grupnya
Setelah tahu kebijakan mana yang aktif, perbaikan biasanya kecil: urutkan ulang penolakan yang menutupi izin, tambahkan syarat perangkat atau MFA yang hilang, atau tulis aturan sempit untuk satu sumber daya alih-alih menaikkan pengguna ke grup berisi sepuluh lainnya.
Lingkar singkat menjaga perubahan jujur:
- Reproduksi penolakan dengan akun asli dan catat ID peristiwa sebelum mengubah apa pun.
- Ubah satu objek, urutan kebijakan, satu syarat, atau satu grup, dan catat yang mana.
- Buka sesi baru, pastikan izin muncul di log dan sumber daya benar-benar terbuka.
- Uji pengguna yang seharusnya masih ditolak, agar perbaikan tidak melebarkan kebijakan.
Jika izin benar dan sumber daya tetap tertutup, masalah pindah ke perutean atau resolusi nama saat otorisasi lolos. Pisahkan kedua kegagalan itu dan tiket berikutnya butuh menit, bukan sore.