LDAP Adalah: Cara Kerja, Struktur & Bedanya dari AD

Setiap kantor punya daftar orang. Dulu bentuknya buku kontak di meja resepsionis, sekarang bentuknya kolom di spreadsheet HRD. Selama daftar itu hanya dibaca manusia, tidak ada masalah. Persoalan baru muncul ketika daftar yang sama dibutuhkan oleh mesin.

Bayangkan sebuah perusahaan dengan 200 karyawan dan 20 aplikasi internal: email, sistem absensi, aplikasi cuti, berbagi file, VPN, dan seterusnya. Kalau setiap aplikasi menyimpan daftar penggunanya sendiri, satu karyawan yang mengundurkan diri berarti 20 kali proses penghapusan akun secara manual. Terlewat satu saja, mantan karyawan itu masih bisa masuk. Sebaliknya, satu karyawan baru berarti 20 kali pendaftaran.

Di titik inilah organisasi membutuhkan satu sumber identitas yang dipakai bersama, dan protokol yang paling lama dipercaya untuk pekerjaan itu adalah LDAP. LDAP adalah protokol standar yang dipakai aplikasi untuk membaca dan mengubah data di sebuah layanan direktori terpusat. Satu karyawan cukup didaftarkan sekali, lalu 20 aplikasi tadi menanyakan identitasnya ke tempat yang sama.

Apa Itu LDAP?

Kepanjangan LDAP adalah Lightweight Directory Access Protocol, yang bisa kita terjemahkan sebagai protokol ringan untuk mengakses direktori. Nama itu terdiri dari tiga bagian yang masing-masing menjelaskan sesuatu:

1. Directory (direktori): kumpulan data terstruktur berisi informasi tentang orang, perangkat, atau grup di sebuah organisasi. Bukan direktori dalam arti folder di komputer Anda.
2. Access Protocol (protokol akses): sekumpulan aturan tentang bagaimana aplikasi bertanya dan bagaimana server menjawab, berjalan di atas jaringan TCP/IP.
3. Lightweight (ringan): perbandingan terhadap pendahulunya, bukan klaim bahwa LDAP itu sederhana.

Satu hal yang perlu diluruskan sejak awal, karena inilah sumber kebingungan yang paling sering terjadi: LDAP bukan aplikasi dan bukan produk. LDAP adalah bahasa yang disepakati bersama. Perbandingannya seperti ini — HTTP adalah protokol, sedangkan Nginx dan Apache adalah software yang berbicara HTTP. LDAP menempati posisi HTTP, sementara OpenLDAP dan Active Directory menempati posisi Nginx dan Apache.

Kenapa Namanya Disebut "Ringan"

Sebelum LDAP ada, dunia sudah punya standar layanan direktori bernama X.500. Standarnya lengkap dan matang, tetapi untuk mengaksesnya sebuah aplikasi harus memakai protokol bernama DAP (Directory Access Protocol). Masalahnya, DAP menuntut seluruh tumpukan protokol OSI terpasang di komputer klien. Untuk komputer desktop biasa pada masa itu, tuntutan tersebut terlalu berat.

Sekitar tahun 1993, sekelompok peneliti di University of Michigan yang dipimpin Tim Howes merancang jalan pintas. Bersama Steve Kille, Colin Robbins, dan Wengyik Yeong, mereka membuat protokol yang bisa mengakses direktori X.500 langsung lewat TCP/IP tanpa tumpukan OSI. Hasilnya diterbitkan sebagai RFC 1487 pada Juli 1993, dan itulah LDAP versi pertama.

Jadi kata "ringan" di sana bersifat relatif — ringan dibandingkan DAP. Bagi yang baru membaca dokumentasinya hari ini, protokol ini sama sekali tidak terasa sederhana.

Versi yang dipakai semua orang sekarang adalah LDAPv3. IETF meresmikannya lewat RFC 2251 pada 1997, lalu menggantinya dengan RFC 4511 pada Juni 2006. Dokumen terakhir itulah yang masih menjadi acuan resmi sampai sekarang.

Seperti Apa Isi Sebuah Direktori LDAP

Bagian ini yang paling sering dilompati, padahal justru di sinilah letak kebingungan sebagian besar pemula. Sulit memahami protokolnya kalau Anda belum pernah melihat wujud datanya.

Entry

Satuan data terkecil di LDAP disebut entry, yaitu satu catatan tentang satu objek. Satu karyawan adalah satu entry. Satu printer di lantai tiga juga satu entry. Satu grup bernama "Divisi Keuangan" pun satu entry.

Atribut

Setiap entry berisi sejumlah attribute (atribut), yaitu pasangan nama dan nilai. Nama atributnya sudah dibakukan, sehingga aplikasi mana pun tahu artinya. Beberapa yang paling umum:

• cn — common name, nama lengkap orangnya
• sn — surname, nama belakang
• uid — nama pengguna untuk login
• mail — alamat email
• telephoneNumber — nomor telepon
• memberOf — daftar grup yang diikuti entry ini

Satu atribut boleh menyimpan lebih dari satu nilai. Seorang karyawan dengan dua alamat email tidak perlu perlakuan khusus, karena mail memang dirancang untuk menerima banyak nilai sekaligus.

objectClass

Atribut apa saja yang boleh dan wajib dimiliki sebuah entry ditentukan oleh objectClass, semacam cetakan atau formulir. Entry dengan objectClass inetOrgPerson, misalnya, diwajibkan punya cn dan sn, sementara mail dan telephoneNumber sifatnya opsional. Kumpulan aturan inilah yang disebut schema (skema) direktori.

DN dan RDN

Setiap entry punya alamat unik bernama DN (Distinguished Name). Bentuknya seperti ini:

uid=budi,ou=karyawan,dc=perusahaan,dc=co,dc=id

Setiap potongan yang dipisah koma disebut RDN (Relative Distinguished Name). Cara membacanya dari kiri ke kanan, mulai dari yang paling spesifik menuju yang paling umum — persis seperti cara Anda membaca sebuah nama domain: budi berada di dalam unit organisasi karyawan, yang berada di dalam domain perusahaan.co.id.

Susunan bertingkat inilah yang membentuk pohon direktori atau DIT (Directory Information Tree). Karena berbentuk pohon, Anda bisa membatasi pencarian hanya pada satu cabang tertentu tanpa harus menyapu seluruh isi direktori.

Diagram anatomi entry LDAP dengan RDN dan atribut cn, sn, uid, mail, serta objectClass.

Kenapa Tidak Memakai Database Biasa Saja?

Pertanyaan yang wajar. Kalau isinya hanya daftar orang beserta atributnya, sebuah tabel di database relasional sebenarnya sanggup menampungnya.

Jawabannya ada pada karakter beban kerjanya. Data direktori punya sifat yang khas:

1. Jauh lebih sering dibaca daripada ditulis: setiap orang login berkali-kali sehari, tetapi datanya mungkin hanya diubah sekali dalam setahun. Server direktori dioptimasi habis-habisan untuk operasi baca.
2. Pencarian berbasis atribut, bukan penggabungan tabel: pertanyaan yang diajukan biasanya "siapa saja yang punya mail berakhiran tertentu", bukan menggabungkan lima tabel sekaligus.
3. Tidak membutuhkan transaksi lintas entry: memindahkan saldo antar rekening menuntut jaminan transaksi yang ketat. Memperbarui nomor telepon karyawan tidak.
4. Disebar ke banyak lokasi: direktori lazim direplikasi ke beberapa kantor cabang supaya proses login tetap berjalan meski jaringan antar kota terputus.

Karena empat sifat itu, layanan direktori tumbuh menjadi kategori software tersendiri dengan pilihan rancangan yang berbeda dari database relasional pada umumnya.

Cara Kerja LDAP Saat Anda Login

Sekarang setelah bentuk datanya jelas, alur kerjanya menjadi mudah diikuti. Ketika Anda memasukkan username dan password di sebuah aplikasi internal perusahaan, urutan yang terjadi kira-kira seperti ini:

Diagram alur autentikasi LDAP antara pengguna, aplikasi, dan server hingga login diterima atau ditolak.

Poin yang perlu diperhatikan: aplikasi tidak pernah membandingkan password sendiri. Aplikasi menyerahkan DN dan password ke server direktori lewat operasi bind, lalu server yang memutuskan cocok atau tidak. Password pengguna tidak perlu disimpan di sisi aplikasi sama sekali.

Bind dan search hanyalah dua dari sembilan operasi yang didefinisikan RFC 4511. Berikut daftar lengkapnya:

• Bind — melakukan autentikasi
• Unbind — mengakhiri sesi
• Search — mencari entry
• Add — menambah entry baru
• Modify — mengubah atribut sebuah entry
• Delete — menghapus entry
• Modify DN — mengganti nama atau memindahkan entry
• Compare — memeriksa apakah sebuah atribut bernilai tertentu
• Abandon — membatalkan operasi yang sedang berjalan

Ada pula kerangka extended operation untuk menambah kemampuan baru tanpa mengubah protokol intinya.

Khusus untuk pencarian, Anda menentukan titik awal berupa base DN dan cakupannya. Tiga cakupan yang tersedia: hanya entry itu sendiri, hanya anak langsungnya, atau seluruh cabang di bawahnya. Menyetel cakupan seluas mungkin pada direktori berisi puluhan ribu entry adalah cara tercepat membuat server kewalahan.

Port 389, Port 636, dan Urusan Enkripsinya

Ada tiga cara sebuah aplikasi terhubung ke server LDAP, dan perbedaannya penting untuk keamanan.

1. LDAP polos di port 389: koneksi berjalan tanpa enkripsi. Semua yang lewat, termasuk password saat operasi bind, terkirim dalam bentuk teks yang bisa dibaca siapa pun yang menyadap jalur jaringan.
2. StartTLS di port 389: koneksi dimulai polos, lalu klien meminta server menaikkannya menjadi terenkripsi lewat perintah StartTLS. Inilah metode yang secara resmi distandarkan di RFC 4511.
3. LDAPS di port 636: koneksi sudah terenkripsi sejak detik pertama dibuka, dengan cara yang sama seperti HTTPS bekerja pada web.

Ada satu fakta yang menarik di sini. LDAPS di port 636 sebenarnya tidak pernah masuk ke dalam standar RFC 4511 — yang dibakukan hanyalah StartTLS. Meski begitu, LDAPS didukung praktis oleh seluruh server dan klien LDAP yang beredar, dan banyak praktisi justru lebih memilihnya.

Alasannya masuk akal. Pada StartTLS, ada jeda antara koneksi dibuka dan enkripsi diaktifkan. Kalau konfigurasi klien salah atau perintah upgrade gagal, sebagian klien tetap melanjutkan sesi dalam keadaan polos, dan kredensial sudah terkirim sebelum siapa pun menyadari ada yang keliru. LDAPS tidak memberi celah itu karena tidak ada fase polos sama sekali.

Diagram perbandingan LDAP port 389 tanpa enkripsi, StartTLS di port 389, dan LDAPS di port 636 yang terenkripsi sejak awal.

Rekomendasi konkret: gunakan LDAPS di port 636 sebagai pilihan utama, dan tutup port 389 dari jaringan luar. Sisakan port 389 hanya untuk lalu lintas di jaringan lokal yang sudah terkendali. Pengecualiannya hanya kalau ada aplikasi lawas yang tidak mendukung apa pun selain StartTLS. Sertifikat yang dipakai mengikuti standar TLS yang sama dengan yang dipakai website.

Sebagai catatan tambahan, Active Directory membuka dua port lain di luar keduanya, yaitu 3268 dan 3269, untuk layanan Global Catalog yang melayani pencarian lintas domain.

LDAP dan Active Directory Bukan Dua Hal Sejenis

Ini kekeliruan yang paling sering kami temui: menganggap LDAP dan Active Directory sebagai dua produk yang harus dipilih salah satu. Keduanya berada di lapisan yang berbeda.

Active Directory adalah layanan direktori buatan Microsoft yang menyediakan beberapa antarmuka sekaligus, dan LDAP adalah salah satunya. Di samping LDAP, Active Directory juga berbicara Kerberos untuk autentikasi dan DNS untuk penemuan layanan. Artinya, aplikasi Linux yang memakai pustaka LDAP standar bisa melakukan autentikasi ke Active Directory tanpa perlu software khusus dari Microsoft.

Jadi pertanyaan "sebaiknya pakai LDAP atau Active Directory" sebenarnya salah bentuk. Pertanyaan yang tepat adalah "server direktori mana yang akan kami jalankan", dan LDAP tetap menjadi cara Anda berbicara dengan server itu, apa pun pilihannya.

Pilihan Server LDAP yang Bisa Anda Pakai

Software yang menjalankan direktori dan melayani permintaan tadi disebut server direktori, atau lazim juga ditulis LDAP server. Beberapa nama yang layak dipertimbangkan:

1. OpenLDAP: implementasi open source paling dikenal, tersedia di hampir semua distribusi Linux, sangat cepat, tetapi konfigurasinya terkenal tidak ramah pemula. Perlu dicatat bahwa Red Hat dan SUSE telah mengeluarkan OpenLDAP dari platform inti mereka dan beralih ke 389 Directory Server.
2. 389 Directory Server: ditulis dalam bahasa C, dirancang untuk skala besar dengan replikasi multi-master, dan kini menjadi pilihan bawaan di ekosistem Red Hat.
3. FreeIPA: bukan sekadar server direktori, melainkan paket manajemen identitas lengkap yang membundel 389 Directory Server dengan Kerberos, DNS, dan otoritas sertifikat. Pilihan paling praktis kalau lingkungan Anda didominasi Linux.
4. Samba AD: menyediakan pengendali domain yang kompatibel dengan Active Directory, berguna kalau Anda punya banyak komputer Windows tetapi ingin menghindari biaya lisensi Windows Server.

Panduan singkat untuk memilih: kalau seluruh komputer klien Anda berjalan di Windows, Active Directory hampir selalu jawaban termurah dalam hal waktu pengelolaan. Kalau lingkungan Anda didominasi server Linux, mulailah dari FreeIPA. Pilih OpenLDAP hanya kalau Anda memang membutuhkan kendali penuh atas skema dan punya orang yang siap merawatnya.

Perlu diperhatikan bahwa keempatnya membutuhkan akses root dan kendali atas port jaringan, sehingga tidak bisa dijalankan di shared hosting. Anda memerlukan VPS Indonesia atau server fisik sendiri untuk menjalankannya.

Keuntungan Memakai LDAP

1. Satu sumber identitas untuk semua aplikasi: menonaktifkan satu akun otomatis menutup akses ke seluruh sistem yang terhubung. Inilah manfaat yang paling terasa saat ada karyawan berhenti.
2. Netral terhadap vendor: protokolnya terbuka dan pustakanya tersedia di semua bahasa pemrograman utama. Anda tidak terkunci pada satu penyedia.
3. Sangat cepat untuk operasi baca: server direktori sanggup melayani ribuan permintaan pencarian per detik pada perangkat keras yang sederhana.
4. Sudah terpasang di mana-mana: aplikasi bisnis mapan seperti GitLab, Jenkins, Nextcloud, Moodle, dan Zabbix nyaris semuanya menyediakan pengaturan LDAP sejak awal.
5. Menjadi fondasi bagi single sign on: sistem SSO modern berbasis SAML atau OIDC umumnya tetap menaruh LDAP di lapisan paling bawah sebagai penyimpan identitas.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Setiap teknologi punya sisi yang jarang disebut di brosur, dan LDAP punya beberapa.

1. Skema yang kaku: menambahkan satu atribut baru berarti menyunting definisi skema di sisi server, dan perubahan ini tidak semudah menambah kolom di tabel database. Perencanaan di awal sangat menentukan.
2. Tidak ada transaksi lintas entry: kalau Anda perlu mengubah lima entry sekaligus dan salah satunya gagal, tidak ada mekanisme bawaan untuk membatalkan empat perubahan sebelumnya.
3. Replikasi yang menyusul, bukan seketika: pada direktori yang direplikasi, perubahan password di satu server memerlukan waktu sebelum sampai ke server lain. Pengguna bisa mengalami kebingungan karena password barunya belum berlaku di semua tempat.
4. Password melewati jaringan saat bind: karena verifikasi dilakukan di sisi server, password dikirimkan dari klien. Tanpa enkripsi yang benar, ini berubah menjadi kerentanan serius. Enkripsi bukan pilihan tambahan pada LDAP, melainkan keharusan.
5. Kurva belajar yang curam: sintaks filter pencarian dan format LDIF untuk ekspor-impor data memakai notasi yang tidak intuitif. Filter sesederhana "cari pengguna aktif bernama Budi" saja sudah membutuhkan tanda kurung bersarang.
6. Rentan terhadap LDAP injection: kalau aplikasi menyisipkan input pengguna langsung ke dalam filter pencarian tanpa penyaringan, penyerang bisa memanipulasi filter tersebut untuk melewati proses login. Polanya sama persis dengan SQL injection, begitu pula pencegahannya: jangan pernah merangkai filter dari input mentah.

Pertanyaan yang Sering Muncul

Apakah LDAP masih relevan di era layanan cloud? Masih, terutama di organisasi yang punya infrastruktur sendiri seperti kampus, rumah sakit, instansi pemerintah, dan perusahaan manufaktur. Banyak layanan identitas berbasis cloud pun tetap menyediakan antarmuka LDAP demi kompatibilitas dengan aplikasi lama yang tidak mengenal protokol modern.

Apakah LDAP bisa dipakai di Windows? Bisa, dan sebenarnya sudah berjalan di sana. Active Directory yang terpasang di Windows Server melayani permintaan LDAP secara bawaan. Anda juga dapat menjalankan OpenLDAP di Windows, meski dukungan resminya jauh lebih baik di Linux.

Apa bedanya LDAP dengan SSO? LDAP menjawab pertanyaan "di mana data identitas ini disimpan dan bagaimana cara membacanya". SSO menjawab pertanyaan "bagaimana caranya pengguna cukup login sekali untuk banyak aplikasi". Keduanya saling melengkapi, dan sistem SSO sering memakai LDAP sebagai sumber datanya.

Apakah LDAP sama dengan autentikasi? Tidak. Autentikasi hanya satu dari sembilan operasi yang dimiliki LDAP, yaitu operasi bind. Sisanya berurusan dengan pencarian dan pengelolaan data direktori.

Kesimpulan

LDAP adalah protokol standar untuk mengakses layanan direktori. Nilainya baru benar-benar terasa ketika sebuah organisasi punya cukup banyak aplikasi internal, sampai mengelola akun satu per satu menjadi pekerjaan yang merepotkan. Kuncinya ada pada memahami bentuk datanya lebih dulu — entry, atribut, dan DN — karena setelah itu operasi protokolnya jauh lebih mudah diikuti.

Kalau organisasi Anda baru menjalankan dua atau tiga aplikasi internal, LDAP kemungkinan besar belum diperlukan. Namun begitu jumlahnya melewati lima aplikasi dan tim Anda mulai kehilangan jejak siapa punya akses ke mana, direktori terpusat berubah dari kemewahan menjadi kebutuhan. Apa pun server yang Anda pilih nanti, pastikan koneksinya terenkripsi sejak hari pertama.

Semoga artikel ini membantu.