Belajar LDAP - Konfigurasi TLS/SSL

#Pendahuluan

Di episode 15 kalian menyadari bahwa simple bind tanpa pengamanan mengirim password polos, dan olcSecurity: ssf=1 hanya masuk akal jika ada lapisan keamanan untuk ditegakkan. Episode 16 ini memasang lapisan itu sendiri: TLS. Kalian akan menyiapkan sertifikat, memutuskan antara StartTLS dan LDAPS, mengonfigurasi server dan klien, lalu membuktikan enkripsinya bekerja dengan ldapsearch -ZZ.

#Mengapa TLS untuk LDAP

TLS mengubah LDAP dari protokol teks menjadi saluran terenkripsi. Manfaatnya ada empat:

Encryption in transit — password dan data tidak bisa diendus di jaringan.
Server authentication — klien memverifikasi bahwa yang dihadapi adalah server yang benar, bukan penyamar.
Client authentication (opsional) — dengan mutual TLS, server juga memverifikasi sertifikat klien; ini menjadi dasar SASL EXTERNAL di episode 17.
Integrity protection — perubahan data di tengah perjalanan terdeteksi karena setiap pesan dilindungi checksum kriptografis.

Tanpa TLS, ancaman di episode 15 — eavesdropping dan man-in-the-middle — berlaku penuh bahkan di jaringan internal.

#Persyaratan Sertifikat

Untuk menjalankan TLS pada slapd, kalian butuh sekumpulan file sertifikat:

Komponen	Isi	Contoh path
CA certificate	sertifikat otoritas penerbit (atau root CA sendiri)	`/etc/ssl/certs/ca.crt`
Server certificate	sertifikat untuk nama host server	`/etc/ssl/certs/slapd.crt`
Certificate key	kunci privat milik sertifikat server	`/etc/ssl/private/slapd.key`
Certificate chain	CA menengah sampai ke root, bila ada	gabung ke server cert
Validation	klien memeriksa sertifikat terhadap CA yang dipercaya	lewat `TLS_CACERT`

Di lab, kalian bisa menjadi CA sendiri. Buat sertifikat self-signed untuk server dengan openssl:

Membuat sertifikat self-signed

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout slapd.key -out slapd.crt -days 365 \
  -subj "/CN=ldap.example.com"
sudo chown root:ssl-cert slapd.key

Di Debian dan Ubuntu, grup ssl-cert mengizinkan slapd membaca /etc/ssl/private; pastikan kunci privat masuk grup tersebut. Nama umum (CN) atau Subject Alternative Name harus cocok dengan hostname yang dipakai klien saat koneksi, jika tidak validasi akan gagal.

#StartTLS versus LDAPS

Dua cara memasang TLS di LDAP:

StartTLS (port 389) — koneksi dimulai polos, lalu klien meminta upgrade ke TLS dengan perintah StartTLS pada koneksi yang sama.
LDAPS (port 636) — TLS aktif sejak koneksi terbentuk, tanpa langkah upgrade.

Aspek	StartTLS (389)	LDAPS (636)
Port	389	636
Inisiasi	upgrade di tengah koneksi	langsung terenkripsi
Standard	standar LDAP, interoperable	praktik lama, bukan standar RFC
Keunggulan	satu port untuk semua, bisa tanpa TLS bila dibuka	sederhana secara mental
Kapan dipakai	default modern	sistem lama atau koneksi yang butuh TLS eksplisit dari awal

StartTLS lebih disukai karena hanya memakai satu port dan tetap bisa melayani koneksi tanpa TLS bila olcSecurity diizinkan. Namun banyak integrasi lama menuntut LDAPS. OpenLDAP 2.5 mendukung keduanya sekaligus, jadi kalian tidak harus memilih.

#Konfigurasi TLS di Server

Sertifikat dan pengaturan TLS diletakkan di entry cn=config:

olcTLSCertificateFile dan olcTLSCertificateKeyFile — wajib; pasangan sertifikat dan kunci server.
olcTLSCACertificateFile — CA yang memvalidasi klien saat mutual TLS diaktifkan.
olcTLSCipherSuite — daftar cipher yang diizinkan; ini contoh umum, sesuaikan dengan kebijakan organisasi.
olcTLSVerifyClient — never untuk autentikasi satu arah; try atau demand bila klien juga harus punya sertifikat.

#Konfigurasi TLS di Klien

Di sisi klien, konfigurasi ada di /etc/ldap/ldap.conf (dan file per-user ~/.ldaprc):

TLS_CACERT menunjuk CA yang dipercaya klien. TLS_REQCERT menentukan sikap terhadap sertifikat server:

Nilai	Perilaku
`never`	tidak memverifikasi sertifikat sama sekali
`allow`	verifikasi jika disajikan, lanjut jika tidak
`try`	verifikasi bila bisa, lanjut bila gagal
`demand`	wajib sertifikat valid, putus koneksi bila tidak

demand adalah nilai yang benar untuk produksi — apa pun di bawahnya membuka pintu untuk man-in-the-middle.

#Menguji TLS

Buktikan bahwa enkripsi benar-benar bekerja:

Menguji dengan ldapsearch dan openssl

ldapsearch -x -H ldap://ldap.example.com -ZZ \
  -b dc=example,dc=com cn
openssl s_client -connect ldap.example.com:636 \
  -CAfile /etc/ssl/certs/ca.crt

ldapsearch -ZZ menuntut StartTLS — koneksi gagal jika server tidak mendukung upgrade. openssl s_client -connect ...:636 memeriksa handshake LDAPS secara langsung dan menampilkan rantai sertifikat; verifikasi bahwa verify return code bernilai ok. Untuk debug negosiasi, jalankan slapd dengan olcLogLevel: conns,stats dan amati pesan TLS di log.

Warning

Jangan pernah menyebarkan TLS_REQCERT never atau -Z (tunggal, yang hanya mengizinkan TLS) ke produksi. -Z bersifat opsional — koneksi tetap diteruskan polos jika TLS tidak tersedia. Selalu pakai -ZZ saat memaksa, dan demand sebagai TLS_REQCERT.

#Penutup

Pada episode 16 ini kalian mengamankan LDAP dengan TLS: empat manfaat enkripsi transport, persiapan CA, sertifikat server, kunci, dan validasi; perbedaan StartTLS di port 389 dan LDAPS di port 636; konfigurasi olcTLSCertificateFile, olcTLSCertificateKeyFile, olcTLSCACertificateFile, olcTLSCipherSuite, dan olcTLSVerifyClient; pengaturan klien dengan TLS_CACERT dan TLS_REQCERT; serta pengujian memakai ldapsearch -ZZ dan openssl s_client.

Inti yang harus dibawa pulang:

Sertifikat harus cocok dengan hostname — mismatch membuat validasi gagal walau CA benar.
StartTLS di 389, LDAPS di 636 — keduanya valid; StartTLS adalah pilihan modern.
TLS_REQCERT demand dan -ZZ — tidak ada kompromi untuk produksi.
Kunci privat dijaga aksesnya — grup ssl-cert di Debian melindungi /etc/ssl/private.

Di episode 17 berikutnya, lapisan TLS yang baru kalian pasang menjadi panggung bagi SASL & external authentication — autentikasi GSSAPI berbasis Kerberos dan SASL EXTERNAL memakai sertifikat klien, lalu integrasi dengan PAM, NSS, dan SSSD.