Belajar Linux - LDAP & Centralized Authentication

#Pendahuluan

Setelah di episode 27 sebelumnya kita membahas containerization & virtualisasi — Docker, LXD, dan KVM — kalian kini bisa menjalankan puluhan layanan dan server virtual di atas beberapa mesin fisik. Tapi perhatikan apa yang terjadi: semakin banyak mesin yang kalian kelola, semakin banyak juga masalah yang datang dari arah yang tidak terduga. Bayangkan skenario ini: tim kalian bertambah, ada 30 server Linux, dan ada karyawan baru yang butuh akses ke 12 server sekaligus. Apakah kalian akan membuat akun user di 12 server satu per satu? Lalu ketika karyawan itu pindah tim, apa kalian ingat untuk menghapus akunnya dari semua server? Dan bagaimana jika ada tiga karyawan yang memakai password yang sama di semua server?

Itulah masalah yang dipecahkan oleh centralized authentication. Di episode 28 ini kita akan membahas LDAP (Lightweight Directory Access Protocol) dan bagaimana ia menjadi satu sumber kebenaran (single source of truth) untuk identitas user di jaringan Linux. Kita akan memahami struktur direktori LDAP, menyiapkan OpenLDAP sebagai server, mengintegrasikan client dengan SSSD dan PAM, membandingkannya dengan Active Directory, dan menutup dengan kesalahan-kesalahan umum yang sering membuat admin frustrasi.

#Pembahasan Utama

#Mengapa Autentikasi Terpusat Diperlukan

Prinsip yang harus kalian pegang sejak awal: setiap user yang bisa masuk ke server kalian adalah permukaan serangan. Semakin banyak server yang memiliki akun user yang tidak terkontrol, semakin besar risiko. Dengan autentikasi lokal (/etc/passwd, useradd per server), setiap server adalah pulau sendiri — tidak ada cara mudah untuk menjawab pertanyaan "siapa saja yang punya akses ke server mana?".

Autentikasi terpusat mengubah paradigma ini. Alih-alih satu akun per server, kalian punya satu direktori user yang dijadikan referensi oleh semua server. Satu akun karyawan = akses ke semua server yang mengizinkannya. Ketika karyawan keluar, admin cukup menonaktifkan akun di direktori — dan aksesnya mati di semua server sekaligus.

Analogi yang pas: anggap setiap server adalah kantor cabang, dan autentikasi lokal adalah pintu dengan kunci sendiri-sendiri. LDAP adalah kantor pusat yang mengeluarkan satu kartu akses standar — setiap cabang tetap punya pintunya, tapi kartu yang sama berlaku di mana-mana, dan kartu yang dicabut di kantor pusat otomatis tidak berlaku di semua cabang.

#Struktur Directory LDAP: DN, OU, dan CN

LDAP menyimpan data sebagai hierarki pohon yang disebut directory information tree (DIT). Setiap entri dalam pohon diidentifikasi oleh DN (Distinguished Name) — alamat unik yang menunjukkan posisi entri dalam hierarki. Beberapa komponen yang wajib kalian kenali:

• DN (Distinguished Name) — alamat lengkap sebuah entri, misalnya uid=arman,ou=People,dc=example,dc=com.
• RDN (Relative Distinguished Name) — bagian terdepan dari DN yang membedakan entri dari saudaranya, misalnya uid=arman.
• OU (Organizational Unit) — kontainer untuk mengelompokkan entri, misalnya ou=People untuk user dan ou=Groups untuk group.
• CN (Common Name) — nama umum entri, biasanya dipakai untuk group dan entri lain.
• DC (Domain Component) — komponen domain, akar dari pohon, misalnya dc=example,dc=com untuk domain example.com.

Struktur pohon direktori LDAP

dc=example,dc=com                     ← root / domain component
├── ou=People                         ← kontainer untuk user
│   ├── uid=arman
│   ├── uid=siti
│   └── uid=budi
├── ou=Groups                         ← kontainer untuk group
│   ├── cn=devops
│   └── cn=developers
└── ou=Servers                        ← kontainer untuk service account
    └── cn=monitoring

Penting untuk dipahami: DN bukan path filesystem — ia adalah identitas logis. uid=arman,ou=People,dc=example,dc=com memberi tahu kita "entri untuk arman di dalam kontainer People, di dalam domain example.com". Karena itu kalian harus selalu konsisten menulis DN, dan kesalahan penulisan DN adalah sumber error yang paling sering (akan kita bahas di pitfall).

Entri LDAP disimpan dan dipertukarkan dalam format LDIF (LDAP Data Interchange Format). Contoh entri user:

dn: uid=arman,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: arman
cn: Arman Dwi Pangestu
sn: Pangestu
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/arman
loginShell: /bin/bash

Perhatikan objectClass. Ini bukan dekorasi — objectClass menentukan attribute apa yang wajib dan boleh dimiliki sebuah entri. Entri di atas memakai tiga class: inetOrgPerson (data personal), posixAccount (akun yang bisa login ke Linux), dan shadowAccount (data password). Jika kalian lupa salah satu class, entri akan ditolak oleh server dengan error schema — salah satu pitfall paling klasik.

#Menyiapkan OpenLDAP Server

OpenLDAP adalah implementasi LDAP paling populer di ekosistem Linux. Di Debian/Ubuntu, server utamanya bernama slapd. Instalasi dasarnya sederhana, tetapi konfigurasi modern OpenLDAP (cn=config) tidak disimpan dalam satu file konfigurasi seperti di masa lalu — semuanya adalah entri LDAP itu sendiri, dikelola dengan ldapmodify.

apt update
DEBIAN_FRONTEND=noninteractive apt install -y slapd ldap-utils

dpkg-reconfigure slapd
# Isi: domain = example.com, base DN = dc=example,dc=com
# Pilih: purge database saat uninstall = No
#        move database lama = Yes
#        password admin = (simpan aman!)

Setelah itu, import organisasi dasar dan user pertama kalian:

ldapadd -x -D cn=admin,dc=example,dc=com -W -f base.ldif
ldapadd -x -D cn=admin,dc=example,dc=com -W -f user-arman.ldif

dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: Example Corp
dc: example
 
dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People

#Integrasi Client dengan SSSD

Server LDAP sudah berdiri, sekarang bagaimana cara membuat server Linux lain mengenali user dari LDAP? Jawaban modernnya adalah SSSD (System Security Services Daemon). SSSD adalah daemon yang menghubungkan nsswitch (resolusi user/group) dan PAM (otentikasi) ke berbagai backend identitas, termasuk LDAP.

Mengapa SSSD dan bukan pam_ldap lama? Karena SSSD membawa caching — identitas dan autentikasi disimpan sementara di client, sehingga login tetap bisa dilakukan (dengan data yang terakhir disinkron) meskipun server LDAP offline. Ini mirip seperti cache peta di HP: navigasi tetap jalan di area tanpa sinyal, menggunakan data yang terakhir diunduh.

apt install -y sssd-ldap ldap-utils

Konfigurasi SSSD diletakkan di /etc/sssd/sssd.conf. Contoh minimal untuk LDAP:

[sssd]
services = nss, pam
config_file_version = 2
domains = example.com
 
[domain/example.com]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com
ldap_default_bind_dn = cn=svc-app,ou=Servers,dc=example,dc=com
ldap_default_authtok = S3cr3tAppBind
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt

Perhatikan beberapa hal penting:

• ldap_search_base harus persis sama dengan struktur tree kalian — mismatch di sini adalah sumber error klasik (lihat pitfall di bawah).
• ldap_default_bind_dn adalah bind DN — identitas yang dipakai SSSD untuk mencari user di direktori. Ini berbeda dari autentikasi user itu sendiri.
• services = nss, pam memberitahu SSSD modul mana yang harus diaktifkan.

Setelah itu, aktifkan nsswitch dan PAM untuk memakai SSSD:

# Tambahkan sss ke baris passwd/group/shadow di /etc/nsswitch.conf
sed -i 's/^passwd:.*/passwd:         compat sss/' /etc/nsswitch.conf
sed -i 's/^group:.*/group:          compat sss/' /etc/nsswitch.conf
 
# Aktifkan modul PAM (auto-generate dengan pam-auth-update)
pam-auth-update --enable mkhomedir sss
systemctl restart sssd

Setelah konfigurasi selesai, uji otentikasi. Yang paling penting: login dari jaringan (misal via SSH), bukan langsung sebagai user LDAP, karena PAM modul kadang tidak aktif di console:

id arman
su - arman
getent passwd arman

arman:x:10001:10001:Arman Dwi Pangestu:/home/arman:/bin/bash

Jika id arman mengembalikan data, SSSD berhasil menyelesaikan identitas dari LDAP. Home directory akan dibuat otomatis saat login pertama karena kita mengaktifkan mkhomedir.

#LDAP vs Active Directory: Kapan Memakai yang Mana

Pertanyaan yang selalu muncul: "kenapa tidak pakai Active Directory saja?" Jawaban singkatnya: keduanya punya tempat masing-masing. Perbandingan berikut membantu kalian memutuskan:

#Common Pitfalls

Autentikasi terpusat adalah area di mana kesalahan kecil terasa sangat perit. Berikut pola yang paling sering ditemukan:

Dua di antaranya layak dibedah lebih dalam. Bind vs search adalah konsep yang paling sering bikin bingung: bind DN adalah identitas mesin/client yang dipakai SSSD untuk membaca direktori (mencari user), sedangkan otentikasi adalah verifikasi password user saat login. Jika bind DN salah, SSSD tidak bisa mencari siapa pun; jika otentikasi user gagal, berarti password-nya tidak cocok dengan entri LDAP. Keduanya adalah kegagalan yang berbeda dengan solusi yang berbeda pula.

Base DN mismatch terjadi karena LDAP sangat sensitif terhadap hierarki. Jika tree kalian dibangun dengan dc=example,dc=org (misal karena lupa mengubah domain saat instalasi) tetapi SSSD memakai dc=example,dc=com, pencarian akan selalu kosong — dan gejalanya justru bukan error, melainkan keheningan yang membingungkan. Selalu verifikasi dengan ldapsearch sebelum menyalahkan SSSD:

ldapsearch -x -H ldap://ldap.example.com \
  -b "dc=example,dc=com" \
  -D "cn=svc-app,ou=Servers,dc=example,dc=com" \
  -w 'S3cr3tAppBind' \
  "(uid=arman)"

# arman, People, example.com
dn: uid=arman,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: arman
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/arman
loginShell: /bin/bash

#Penutup

Di episode ini kita telah membangun autentikasi terpusat dengan LDAP: memahami mengapa satu sumber identitas dibutuhkan saat server bertambah banyak, menguasai struktur pohon direktori dengan DN/OU/CN, menyiapkan OpenLDAP server, mengintegrasikan client lewat SSSD dan PAM, membandingkan OpenLDAP dengan Active Directory, dan mengenali kesalahan-kesalahan klasik seperti schema error, base DN mismatch, serta kebingungan bind vs search. Intinya: identitas user tidak lagi tersebar di ratusan server — ia hidup di satu tempat dan dikendalikan dari satu titik.

Sekarang kalian bisa mengelola puluhan server dengan identitas yang terkendali dan terpusat. Namun ada satu pertanyaan yang belum terjawab: dengan begitu banyak komponen — server, container, backup, LDAP — bagaimana kita tahu semuanya tetap sehat, dan bagaimana memastikan layanan tetap hidup saat satu server mati? Di episode 29 berikutnya kita akan membahas High Availability & Monitoring Stack — Keepalived, Prometheus, Grafana, dan Alertmanager. Sampai jumpa di episode 29!