Sertifikat VPN tidak melindungi segmen LDAP

Login VPN yang memeriksa kredensial terhadap direktori melibatkan dua koneksi jaringan yang terpisah. Koneksi pengguna ke gateway dilindungi oleh sertifikat VPN itu sendiri dan konfigurasi protokol. Koneksi gateway ke direktori adalah sesi lain dengan pengaturan TLS-nya sendiri, penyimpanan kepercayaannya sendiri, dan mode kegagalannya sendiri. Tidak ada apa pun pada yang pertama yang menjamin apa pun pada yang kedua.

Asimetri itulah mekanisme di balik login yang tampak terenkripsi dan tetap mengirim kata sandi bind secara terbuka.

Dua koneksi, dua keputusan kepercayaan

Sesi luar adalah apa yang dilihat pengguna: sertifikat yang terikat pada nama host VPN, divalidasi oleh klien, membawa pertukaran autentikasi. Sesi dalam milik klien direktori di dalam gateway, yang membuka koneksinya sendiri dan entah menegosiasikan TLS atau tidak. Setiap sisi memvalidasi lawan bicaranya, menggunakan materi dari berkas konfigurasi yang berbeda. Segmen dalam yang salah konfigurasi tetap tak terlihat dari sisi pengguna, karena segmen luar bekerja persis seperti yang dimaksudkan.

Itulah sebabnya kegagalannya senyap, bukan berisik. Gateway yang tidak pernah memeriksa sertifikat direktori tetap mengautentikasi pengguna dengan benar; ia hanya mengautentikasi mereka melalui kanal yang tidak diverifikasinya.

StartTLS dan LDAPS, dipilih dengan sadar

StartTLS dibuka sebagai LDAP biasa dan ditingkatkan di tempat, biasanya pada port 389. LDAPS memulai TLS bersama koneksi, biasanya pada 636. Keduanya sah dan adaptor harus sesuai dengan apa yang ditawarkan direktori. Mewajibkan StartTLS berbeda dari mencobanya lalu melanjutkan ketika peningkatan gagal, dan perbedaan itulah tepatnya tempat kata sandi bind bisa bocor. Konfigurasikan mode ketat, dan jangan izinkan jalur cadangan tanpa perlindungan untuk bind dengan kata sandi.

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

Opsi -ZZ adalah intinya: kueri gagal alih-alih diam-diam melanjutkan tanpa peningkatan. Nama dan akun pada baris itu adalah contoh. Dokumentasi TLS OpenLDAP mencakup pengaturan kepercayaan di baliknya.

Penyimpanan kepercayaan mana yang dibaca klien LDAP?

Pustaka klien OpenLDAP membaca konfigurasi kepercayaannya sendiri, baik dari berkas sistem maupun dari pengaturan khusus plugin. Direktif CA pada VPN berlaku untuk peer VPN dan bukan bukti bahwa pustaka LDAP membaca berkas yang sama. Gunakan nama host direktori yang benar-benar dicakup sertifikat, ditambah rantai penerbit yang dipercaya pustaka. Di Active Directory, gelar sertifikat layanan direktori dengan penggunaan autentikasi server yang tepat alih-alih menalar dari nama tampilan.

Setiap tujuan failover harus memenuhi kebijakan identitas yang sama. Lingkungan yang primer tervalidasi dan sekundernya tidak lebih buruk daripada yang tanpa failover, karena jalur yang lebih lemah hanya ditemukan saat gangguan.

Akun bind tetap menjadi masalah terpisah

Melindungi transport tidak mengurangi apa yang boleh dilakukan akun bind. Cakupan pencarian direktori, otorisasi grup, dan hak istimewa akun layanan adalah keputusan terpisah, dan akun bind yang luas tetap luas setelah TLS diaktifkan. Gunakan akun layanan dan basis pencarian tersempit yang dibutuhkan integrasi, dan catat endpoint, mode TLS, pemilik kepercayaan, dan proses pembaruan bersama konfigurasi VPN.

Ketika ketidakcocokan sertifikat muncul, gelar sertifikat atau rantai yang benar. Menonaktifkan verifikasi mengubah ketidakcocokan yang terlihat menjadi tak terlihat dan membiarkan hubungan kepercayaan kedua tidak teruji.

Dua koneksi, dua pemilik, dua tanggal pembaruan. Menjaga keduanya terpisah dalam dokumentasi adalah yang membuat login jujur.