Sijil VPN tidak melindungi bahagian LDAP

Log masuk VPN yang menyemak kelayakan terhadap direktori melibatkan dua sambungan rangkaian yang berasingan. Sambungan pengguna ke gerbang dilindungi oleh sijil VPN itu sendiri dan konfigurasi protokol. Sambungan gerbang ke direktori ialah sesi lain dengan tetapan TLS sendiri, stor kepercayaan sendiri dan cara kegagalannya sendiri. Tiada apa-apa pada yang pertama menjamin apa-apa pada yang kedua.

Asimetri itulah mekanisme di sebalik log masuk yang kelihatan disulitkan dan masih menghantar kata laluan bind secara terbuka.

Dua sambungan, dua keputusan kepercayaan

Sesi luar ialah apa yang dilihat pengguna: sijil yang terikat pada nama hos VPN, disahkan oleh klien, membawa pertukaran pengesahan. Sesi dalam milik klien direktori di dalam gerbang, yang membuka sambungannya sendiri dan sama ada berunding TLS atau tidak. Setiap pihak mengesahkan rakan yang diajaknya bercakap, menggunakan bahan daripada fail konfigurasi yang berbeza. Bahagian dalam yang salah dikonfigurasi kekal tidak kelihatan dari sisi pengguna, kerana bahagian luar berfungsi tepat seperti yang dimaksudkan.

Itulah sebabnya kegagalan itu senyap dan bukan bising. Gerbang yang tidak pernah menyemak sijil direktori tetap mengesahkan pengguna dengan betul; ia hanya mengesahkan mereka melalui saluran yang tidak disahkannya.

StartTLS dan LDAPS, dipilih dengan sedar

StartTLS dibuka sebagai LDAP biasa dan dinaik taraf di tempat, lazimnya pada port 389. LDAPS memulakan TLS bersama sambungan, lazimnya pada 636. Kedua-duanya sah dan penyesuai mesti sepadan dengan apa yang ditawarkan direktori. Mewajibkan StartTLS berbeza daripada mencubanya dan meneruskan apabila naik taraf gagal, dan perbezaan itulah tempat kata laluan bind boleh terlepas. Konfigurasikan mod ketat, dan jangan benarkan laluan sandaran tanpa perlindungan untuk bind dengan kata laluan.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

Pilihan -ZZ ialah intinya: pertanyaan gagal dan bukannya meneruskan secara senyap tanpa naik taraf. Nama dan akaun dalam baris itu ialah contoh. Dokumentasi TLS OpenLDAP merangkumi tetapan kepercayaan di sebaliknya.

Stor kepercayaan mana yang dibaca oleh klien LDAP?

Pustaka klien OpenLDAP membaca konfigurasi kepercayaannya sendiri, sama ada daripada fail sistem atau daripada tetapan khusus pemalam. Arahan CA VPN terpakai kepada rakan VPN dan bukan bukti bahawa pustaka LDAP membaca fail yang sama. Gunakan nama hos direktori yang benar-benar diliputi sijil, serta rantaian pengeluar yang dipercayai pustaka. Dalam Active Directory, gunakan sijil perkhidmatan direktori dengan penggunaan pengesahan pelayan yang betul dan bukannya membuat kesimpulan daripada nama paparan.

Setiap destinasi failover mesti memenuhi dasar identiti yang sama. Persekitaran yang utama disahkan dan yang kedua tidak adalah lebih teruk daripada yang tanpa failover, kerana laluan yang lebih lemah hanya ditemui semasa gangguan.

Akaun bind kekal sebagai masalah berasingan

Melindungi pengangkutan tidak mengurangkan apa yang boleh dilakukan oleh akaun bind. Skop carian direktori, kebenaran kumpulan dan keistimewaan akaun perkhidmatan ialah keputusan berasingan, dan akaun bind yang luas kekal luas selepas TLS didayakan. Gunakan akaun perkhidmatan dan asas carian yang paling sempit yang diperlukan oleh integrasi, dan catat titik akhir, mod TLS, pemilik kepercayaan dan proses pembaharuan bersama konfigurasi VPN.

Apabila ketidakpadanan sijil muncul, gunakan sijil atau rantaian yang betul. Menyahdayakan pengesahan menukar ketidakpadanan yang kelihatan menjadi tidak kelihatan dan membiarkan hubungan kepercayaan kedua tidak diuji.

Dua sambungan, dua pemilik, dua tarikh pembaharuan. Menyimpannya berasingan dalam dokumentasi itulah yang menjaga log masuk itu jujur.