Autentikasi LDAP OpenVPN berhasil tetapi pemeriksaan grup gagal: ke mana harus melihat

Autentikasi bisa lolos sementara pemeriksaan grup menolak semua orang. Telusuri blok Authorization, atribut keanggotaan, dan titik akhir direktori satu per satu.

Kredensial lolos, terowongan mulai naik, lalu sesi gagal dengan pesan tentang grup alih-alih tentang kata sandi. Kombinasi itu menempatkan kegagalan di paruh kedua kerja plugin LDAP: pengikatan dan pemeriksaan kata sandi berhasil, sedangkan keputusan keanggotaan yang menyusul tidak. Kedua paruh membaca dari stanza konfigurasi yang sama, karena itu perbaikan di satu tempat bisa membiarkan yang lain tak tersentuh. Mulailah dari baris log yang menyebut langkahnya, bukan dari akun yang kebetulan Anda uji.

Perlakukan penolakan sebagai jawaban otorisasi

Plugin melakukan pengikatan layanan, mencari akun, memverifikasi kata sandi yang diberikan, lalu menanyakan apakah akun itu termasuk grup yang diizinkan. Itu empat operasi berbeda, dan hanya yang terakhir tentang grup. Karena itu penolakan yang datang setelah pengikatan berhasil tidak mengatakan apa pun tentang kata sandi, bahkan ketika klien menampilkan kesalahan autentikasi umum. Menaikkan tingkat log plugin sebelum mengubah konfigurasi adalah yang memisahkan keempatnya di keluaran.

Cari evaluasi grup itu sendiri. Ketika tidak ada kueri grup yang muncul sama sekali, blok otorisasi tidak tercapai, yang biasanya berarti sebuah direktif berada di luar blok yang memilikinya atau sebuah opsi wajib hilang. Ketika kueri muncul dan tidak mengembalikan apa pun, titik akhir atau filter menjawab pertanyaan yang berbeda dari yang Anda maksud.

Putuskan apakah keanggotaan berada di filter atau di blok grup

Ada dua bentuk yang didukung, dan mencampurnya adalah cara konfigurasi yang berfungsi berhenti bekerja. Yang pertama mendorong keanggotaan ke pencarian pengguna dengan meminta atribut pada objek pengguna; yang kedua membiarkan pencarian pengguna dan membuat plugin mencari objek grup sesudahnya. Pilih satu per penerapan dan catat mana yang Anda pilih.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

Dengan bentuk itu filter menentukan segalanya, jadi RequireGroup harus false atau plugin akan mencari objek grup yang tidak pernah disebut filter. Atribut di filter harus ada pada objek pengguna dan terisi, yang tidak dijamin begitu grup bersarang.

Bentuk lain menjaga pencarian tetap sederhana dan menambahkan pencarian grup setelahnya. Objek grup dinamai secara eksplisit, dan plugin membandingkan pengguna dengan anggota yang dikembalikan direktori untuknya. Tidak ada yang berubah pada filter pengguna, yang membuat bentuk ini lebih mudah diaudit ketika tim lain mengelola grup.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

Titik buta itu sama: perbandingan keanggotaan biasa tidak mengurai grup bersarang, sehingga akun yang aksesnya datang melalui grup induk gagal sementara konsol masih menampilkan keanggotaan. Active Directory mengekspos member pada grup, skema lain memakai uniqueMember, dan menunjuk atribut yang salah mengembalikan hasil kosong alih-alih kesalahan.

Pilih titik akhir yang memuat objek grup

URL menentukan direktori mana yang ditanyakan plugin, dan pengendali domain pada port 389 hanya menjawab untuk konteks penamaannya sendiri. Katalog global pada port 3268 menjawab untuk seluruh hutan, hanya-baca dan dengan kumpulan atribut sebagian. Ketika akun berada di satu domain dan grup VPN di domain lain, kueri satu domain bisa menemukan pengguna dan tetap melewatkan keanggotaan. Itulah kasus di mana memindahkan URL ke port katalog menyelesaikan penolakan, dan itu juga kasus yang orang generalisasi terlalu jauh.

Kumpulan atribut sebagian adalah batasnya: atribut yang tidak dimuat katalog tidak dapat difilter, jadi perubahan yang sama bisa membuat satu penerapan berhasil dan penerapan lain mengembalikan kosong. Pastikan apa yang benar-benar dikembalikan titik akhir untuk pengguna dan grup nyata sebelum menulis ulang stanza. Rujukan dan TLS lagi-lagi urusan terpisah, karena rujukan harus diikuti dan titik akhir yang memerlukan TLS membutuhkan berkas kepercayaan yang sesuai.

Simpan status akun dan cakupan pencarian di bidangnya sendiri

Tanda nonaktif termasuk di filter, bukan di pemeriksaan grup. Di Active Directory itu bit kedua dari userAccountControl, dan tanpa syarat itu akun nonaktif dengan kata sandi sah akan terautentikasi lalu gagal di langkah grup, yang terbaca seperti bug otorisasi. Cakupan pencarian termasuk di DN dasar, karena memulai dari akar domain lebih lambat dan bisa mencocokkan objek di luar unit organisasi yang ingin Anda cakup.

Jaga juga hak akun pengikatan tetap sempit. Hak direktori yang luas mengubah filter yang salah konfigurasi menjadi kueri yang berhasil dan menyembunyikan bug sampai seseorang mengaudit akun itu. Ubah keanggotaan di direktori itu sendiri, jangan pernah di daftar pengecualian lokal, agar menonaktifkan akun cukup untuk mencabut akses. Jika tim lain mengelola grup, sepakati atribut yang mereka isi sebelum menulis filter terhadapnya.

Buktikan hasilnya dengan tiga akun

Jalankan konfigurasi terhadap tiga identitas: anggota yang diizinkan, akun sah di luar grup, dan akun yang telah dinonaktifkan. Jika ketiganya ditolak, pengikatan atau kueri grup rusak; jika ketiganya diterima, tidak ada syarat grup yang diterapkan sama sekali. Hasil campuran adalah satu-satunya hasil yang membuktikan konfigurasi membedakan kasus yang Anda pedulikan.

Baca ketiga jawaban yang sama langsung dari direktori sebelum menyalahkan plugin. Kueri pertama menunjukkan atribut grup yang menjadi sandaran filter, dan yang kedua menunjukkan nilai kendali akun. Ganti dengan DN dasar, akun, dan titik akhir Anda sendiri:

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

Pengguna yang memberOf-nya kembali kosong adalah fakta direktori, bukan bug plugin, dan akun yang masih terautentikasi setelah dinonaktifkan berarti filter kehilangan syarat kendali akun. Perbaiki bukti itu dulu, lalu jalankan lagi uji tiga akun. Simpan baris log yang menyebut langkah gagal di samping perubahan konfigurasi, agar orang berikutnya dapat memisahkan otorisasi dari autentikasi tanpa mengulang pencarian.

Artikel terkait