Menambah pengguna ke kumpulan VPN tidak memberi akses dengan sendirinya
Keahlian kumpulan ialah satu syarat, bukan kebenaran. Lihat apa yang benar-benar dipadankan oleh get laluan, baca rekod terima atau tolak, dan uji kedua-dua hasil.
Akaun dalam kumpulan betul, log masuk berjaya, tetapi sambungan ditolak. Menambah kumpulan sampai ada yang longgar memberi hak jauh melebihi tiket. Keahlian kumpulan hanya satu input kebenaran: get laluan mengumpul fakta sesi, memadankannya dengan dasar tersusun, lalu memutuskan. Jika syarat lain gagal, menukar kumpulan hanya mengubah pendedahan.
Keahlian kumpulan ialah syarat, bukan kebenaran
Dalam RADIUS kumpulan datang sebagai atribut kebenaran, dan atribut menerangkan sesi, bukan membenarkannya. Pelayan menjawab Access-Accept atau Access-Reject; apabila menerima ia boleh melampirkan Filter-Id, Class atau atribut terowong RFC 2868, dan peranti seberang mentafsirnya mengikut pengeluar. Tiada apa dalam protokol memetakan kumpulan kepada akses penuh; pemetaan itu ditulis oleh penyusun dasar di get laluan atau pelayan akses rangkaian.
Sebab itu nama kumpulan sama berkelakuan berbeza pada dua sistem. Microsoft NPS menyusun dasar daripada syarat, had dan tetapan lalu menilainya mengikut urutan. OpenVPN Access Server ada model kumpulan dan peraturan akses sendiri, manakala pelayan OpenVPN komuniti sering menyerahkan segala-galanya kepada skrip client-connect atau fail client-config-dir.
Peraturan yang padan yang menentukan, bukan kumpulan yang dijangka
Kebanyakan enjin berhenti pada dasar pertama yang padan atau yang paling khusus. Jika dasar 3 menolak dan dasar 7 membenarkan, sesi boleh gagal sebelum sampai kepada peraturan yang sepatutnya meloloskannya. Urutan ialah tetapan sebenar pada NPS dan kebanyakan produk kawalan akses rangkaian.
Syarat yang menyertai kumpulan ialah separuh lagi: keadaan peranti, kaedah pengesahan, MFA selesai, rangkaian sumber, subjek sijil atau tetingkap masa. Jika satu tidak dipenuhi, dasar tidak padan, enjin jatuh dan penolakan lalai terpakai. Dari sisi pengguna kumpulan nampak diabaikan; dari sisi enjin kumpulan tidak pernah ditanya.
Butiran direktori mencipta ilusi sama. Dasar atas keahlian kumpulan Windows membaca SID dalam token, dan hanya kumpulan keselamatan disenaraikan; kumpulan pengedaran tidak pernah muncul. Kumpulan utama ada dalam medan sendiri, jadi dasar yang terikat padanya boleh gagal senyap.
Baca rekod terima atau tolak sebelum menyentuh kumpulan
Tanya dahulu: adakah permintaan sampai ke peringkat kebenaran? Pada NPS jawapannya dalam log peristiwa, tempat 6272 mencatat akses diberi, 6273 penolakan, dan 6274 permintaan yang dibuang sebelum dasar dinilai. Tiga nombor itu membahagi masalah kepada tiga siasatan, dan hanya satu tentang kumpulan.
| 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 |
Jika log tidak dapat dicapai, tanya pelayan terus dan baca balasannya. Balasan tanpa Filter-Id dan atribut terowong bermakna pelayan menganggap sesi biasa dan get laluan memakai peraturannya sendiri. Balasan dengan atribut yang tidak dilaksanakan titik penguatkuasaan ialah kerosakan lain: kebenaran lulus dan peranti mengabaikan hasilnya.
radtest alice 'password' 10.0.0.5 0 testing123Bandingkan atribut yang dikembalikan dengan yang didokumenkan get laluan, bukan dengan yang disiratkan nama kumpulan. Perbandingan itu biasanya memisahkan masalah dasar daripada masalah penguatkuasaan.
Perubahan kumpulan tidak berkuat kuasa ke belakang
Atribut kebenaran dikembalikan sekali, semasa sesi disahkan. Get laluan menyimpannya pada sesi dan tidak membaca semula direktori bagi setiap paket, jadi sesi sedia ada terus berjalan selepas seseorang dikeluarkan dari kumpulan.
Agar perubahan berkuat kuasa perlu keputusan kebenaran baharu, bukan hanya kunci baharu. Jika pelayan menyokong RFC 5176, Disconnect-Request atau CoA-Request ke UDP 3799 memaksa penilaian semula; jika tidak, putuskan klien dan biarkan ia menyambung semula. Rundingan semula hanya menyegarkan kunci terowong.
Baiki syaratnya, bukan kumpulannya
Setelah tahu dasar mana yang bertindak, pembaikan biasanya kecil: susun semula penolakan yang menutupi kebenaran yang dimaksudkan, tambah syarat peranti atau MFA yang hilang, atau tulis peraturan sempit untuk satu sumber daya dan bukan menaikkan pengguna ke kumpulan yang membawa sepuluh lagi.
Gelung pendek menjaga perubahan jujur:
- Hasilkan semula penolakan dengan akaun asal dan catat ID peristiwa sebelum mengubah apa pun.
- Ubah satu objek, urutan dasar, satu syarat atau satu kumpulan, dan catat yang mana.
- Buka sesi baharu, pastikan kebenaran muncul dalam log dan sumber daya benar-benar terbuka.
- Uji pengguna yang sepatutnya masih ditolak, agar pembaikan tidak meluaskan dasar secara tidak sengaja.
Jika kebenaran betul dan sumber daya tetap tidak terbuka, masalah berpindah ke penghalaan atau penyelesaian nama ketika kebenaran lulus. Asingkan kedua kegagalan itu dan tiket seterusnya mengambil minit, bukan petang.