Pengesahan LDAP OpenVPN berfungsi tetapi semakan kumpulan gagal: ke mana hendak dilihat

Pengesahan boleh lulus sementara semakan kumpulan menolak semua orang. Teliti blok Authorization, atribut keahlian dan titik akhir direktori satu demi satu.

Kelayakan lulus, terowong mula naik, dan kemudian sesi gagal dengan mesej tentang kumpulan dan bukan tentang kata laluan. Gabungan itu meletakkan kegagalan pada separuh kedua kerja pemalam LDAP: pengikatan dan semakan kata laluan berjaya, dan keputusan keahlian yang menyusul tidak. Kedua-dua separuh membaca daripada blok konfigurasi yang sama, sebab itu pembaikan di satu tempat boleh membiarkan yang lain tidak tersentuh. Mulakan dengan baris log yang menamakan langkah itu, bukan dengan akaun yang kebetulan anda uji.

Anggap penolakan sebagai jawapan kebenaran

Pemalam melakukan pengikatan perkhidmatan, mencari akaun, mengesahkan kata laluan yang diberi dan kemudian bertanya sama ada akaun itu tergolong dalam kumpulan yang dibenarkan. Itu empat operasi berasingan, dan hanya yang terakhir berkaitan kumpulan. Oleh itu penolakan yang tiba selepas pengikatan berjaya tidak berkata apa-apa tentang kata laluan, walaupun klien memaparkan ralat pengesahan umum. Menaikkan tahap log pemalam sebelum menukar konfigurasi itulah yang memisahkan keempat-empatnya dalam output.

Cari penilaian kumpulan itu sendiri. Apabila tiada pertanyaan kumpulan muncul sama sekali, blok kebenaran tidak dicapai, yang biasanya bermaksud sesuatu arahan berada di luar blok yang memilikinya atau pilihan wajib tiada. Apabila pertanyaan muncul dan tidak memulangkan apa-apa, titik akhir atau penapis menjawab soalan yang berbeza daripada yang anda maksudkan.

Tentukan sama ada keahlian tinggal dalam penapis atau dalam blok kumpulan

Terdapat dua bentuk yang disokong, dan mencampurkannya ialah cara konfigurasi yang berfungsi berhenti berfungsi. Yang pertama menolak keahlian ke dalam carian pengguna dengan meminta atribut pada objek pengguna; yang kedua membiarkan carian pengguna dan membiarkan pemalam mencari objek kumpulan selepas itu. Pilih satu bagi setiap penggunaan dan catat yang mana 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 penapis menentukan segala-galanya, jadi RequireGroup mesti false atau pemalam akan mencari objek kumpulan yang tidak pernah disebut oleh penapis. Atribut dalam penapis mesti wujud pada objek pengguna dan diisi, yang tidak dijamin apabila kumpulan bersarang.

Bentuk lain mengekalkan carian mudah dan menambah carian kumpulan selepasnya. Objek kumpulan dinamakan secara eksplisit, dan pemalam membandingkan pengguna dengan ahli yang dipulangkan direktori untuknya. Tiada apa berubah pada penapis pengguna, yang menjadikan bentuk ini lebih mudah diaudit apabila pasukan lain menguruskan kumpulan.

<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 dikongsi: perbandingan keahlian biasa tidak mengembangkan kumpulan bersarang, jadi akaun yang aksesnya datang melalui kumpulan induk gagal sementara konsol masih menunjukkan keahlian. Active Directory mendedahkan member pada kumpulan, skema lain menggunakan uniqueMember, dan menunjuk atribut yang salah memulangkan hasil kosong dan bukannya ralat.

Pilih titik akhir yang menyimpan objek kumpulan

URL menentukan direktori mana yang ditanya oleh pemalam, dan pengawal domain pada port 389 hanya menjawab untuk konteks penamaannya sendiri. Katalog global pada port 3268 menjawab untuk seluruh hutan, baca sahaja dan dengan set atribut separa. Apabila akaun berada dalam satu domain dan kumpulan VPN dalam domain lain, pertanyaan satu domain boleh menemui pengguna dan masih terlepas keahlian. Itulah kes di mana memindahkan URL ke port katalog menyelesaikan penolakan, dan itulah juga kes di mana orang membuat generalisasi terlalu jauh.

Set atribut separa ialah hadnya: atribut yang tidak disimpan katalog tidak boleh ditapis, jadi perubahan yang sama boleh membuatkan satu penggunaan berfungsi dan satu lagi memulangkan kosong. Sahkan apa yang sebenarnya dipulangkan titik akhir untuk pengguna dan kumpulan sebenar sebelum menulis semula blok itu. Rujukan dan TLS sekali lagi perkara berasingan, kerana rujukan mesti diikuti dan titik akhir yang memerlukan TLS memerlukan fail kepercayaan yang sepadan.

Simpan keadaan akaun dan skop carian dalam medan masing-masing

Bendera nyahdaya tergolong dalam penapis, bukan dalam semakan kumpulan. Dalam Active Directory ia ialah bit kedua userAccountControl, dan tanpa syarat itu akaun dinyahdayakan dengan kata laluan sah akan disahkan dan kemudian gagal pada langkah kumpulan, yang kelihatan seperti pepijat kebenaran. Skop carian tergolong dalam DN asas, kerana bermula di akar domain lebih perlahan dan boleh memadankan objek di luar unit organisasi yang anda mahu liputi.

Kekalkan hak akaun pengikatan sempit juga. Hak direktori yang luas menjadikan penapis yang salah konfigurasi sebagai pertanyaan yang berjaya dan menyembunyikan pepijat sehingga seseorang mengaudit akaun itu. Tukar keahlian dalam direktori itu sendiri, jangan sekali-kali dalam senarai pengecualian tempatan, supaya menyahdayakan akaun cukup untuk membuang akses. Jika pasukan lain menguruskan kumpulan, persetujui atribut yang mereka isi sebelum menulis penapis terhadapnya.

Buktikan hasilnya dengan tiga akaun

Jalankan konfigurasi terhadap tiga identiti: ahli yang dibenarkan, akaun sah di luar kumpulan dan akaun yang telah dinyahdayakan. Jika ketiga-tiganya ditolak, pengikatan atau pertanyaan kumpulan rosak; jika ketiga-tiganya diterima, tiada syarat kumpulan dikenakan sama sekali. Hasil bercampur ialah satu-satunya hasil yang membuktikan konfigurasi membezakan kes yang anda pentingkan.

Baca tiga jawapan yang sama terus daripada direktori sebelum menyalahkan pemalam. Pertanyaan pertama menunjukkan atribut kumpulan yang menjadi sandaran penapis, dan yang kedua menunjukkan nilai kawalan akaun. Gantikan dengan DN asas, akaun 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 ialah fakta direktori, bukan pepijat pemalam, dan akaun yang masih disahkan selepas dinyahdayakan bermaksud penapis kehilangan syarat kawalan akaun. Betulkan bukti itu dahulu, kemudian jalankan semula ujian tiga akaun. Simpan baris log yang menamakan langkah gagal di sebelah perubahan konfigurasi, supaya orang seterusnya boleh memisahkan kebenaran daripada pengesahan tanpa mengulang carian.

Artikel berkaitan