Belajar Kerberos - Integrasi LDAP dan Kerberos

#Pendahuluan

Di episode 16 kalian memakai tiket Kerberos untuk masuk ke PostgreSQL dan MySQL. Sekarang kita naik ke lapisan yang mengatur identitas itu sendiri: direktori. Sejauh ini principal Kerberos hidup di database biner KDC yang cuma dipahami Kerberos — sulit dibaca, di-audit, atau disinkronkan dengan sistem lain. Episode ini memperbaiki itu dengan LDAP: pertama sebagai tempat penyimpanan principal KDC, lalu sebagai layanan yang bisa diautentikasi dengan Kerberos lewat SASL/GSSAPI, dan akhirnya berbicara tentang Active Directory.

Hasil akhirnya adalah fondasi identitas terpadu: satu direktori yang menjadi sumber kebenaran user, dan satu KDC yang mengeluarkan tiket untuk mereka.

#LDAP sebagai Backend Principal

Database principal MIT Kerberos default berbentuk file lokal (/var/lib/krb5kdc/principal) yang hanya bisa dibaca alat khusus. Dengan backend LDAP, principal disimpan sebagai objek di direktori — user alice menjadi sebuah entri yang bisa dibaca, dicari, dan dikelola bersama atribut identitas lainnya.

Unified user management adalah alasan utama beralih: alih-alih tiga sistem terpisah (database Kerberos, direktori LDAP, dan daftar user aplikasi), cukup satu. Saat karyawan keluar, satu operasi menghapus entri — principal Kerberos, mailbox, dan keanggotaan grup ikut hilang serentak.

Benefits of LDAP backend bagi KDC antara lain: pemisahan data principal dari proses KDC (KDC bisa dibangun ulang tanpa kehilangan data), integrasi mudah dengan tool manajemen identitas yang sudah mengenal LDAP, replikasi yang matang, dan kemampuan membawa atribut principal bersama data user.

#Mengonfigurasi KDC dengan Backend LDAP (kldap)

MIT Kerberos mendukung backend LDAP lewat modul kldap. Pertama, KDC harus memakai database LDAP, bukan file — ini dideklarasi di [dbmodules] pada /etc/krb5.conf:

/etc/krb5.conf - KDC dengan backend LDAP

[dbmodules]
  EXAMPLE.COM = {
    db_library = kldap
    ldap_kerberos_container_dn = cn=krbContainer,dc=example,dc=com
    ldap_kdc_dn = cn=kdc-svc,ou=services,dc=example,dc=com
    ldap_kadmind_dn = cn=admin-svc,ou=services,dc=example,dc=com
    ldap_service_password_file = /etc/krb5kdc/service.keyfile
    ldap_servers = ldap://ldap1.example.com
  }

LDAP schema installation. KDC perlu memahami atribut Kerberos di direktori. Skema tersebut disediakan MIT sebagai kerberos.schema — impor ke OpenLDAP agar entri bisa memuat atribut seperti krbPrincipalName dan krbPrincipalKey.

Container setup. Semua principal disimpan di bawah container cn=krbContainer. Inisialisasi container dilakukan dengan kdb5_ldap_util, dan akun service (kdc-svc, admin-svc) diberi hak baca/tulis pada container tersebut.

ACL configuration. Keamanan diatur lewat ACL di sisi LDAP: akun service KDC hanya boleh baca/tulis objek Kerberos, bukan seluruh direktori. Batasi hak kadmind agar hanya memodifikasi atribut principal, dan jangan pernah memberikan akses admin direktori penuh kepada akun-akun ini.

kdb5_ldap_util -D cn=admin,dc=example,dc=com create -r EXAMPLE.COM
kdb5_ldap_util -D cn=admin,dc=example,dc=com stash

#SASL/GSSAPI untuk LDAP

Setelah KDC hidup di atas LDAP, giliran memakai Kerberos untuk mengautentikasi koneksi LDAP itu sendiri — bukan lagi bind password polos. SASL mendukung mekanisme GSSAPI: klien menawarkan tiket Kerberos, server memvalidasinya dengan keytab miliknya.

LDAP server SASL configuration. Server LDAP harus memiliki principal ldap/ldap1.example.com di keytab-nya:

kadmin.local -q "addprinc -randkey ldap/ldap1.example.com"
kadmin.local -q "ktadd -k /etc/krb5.keytab ldap/ldap1.example.com"

Keytab for ldap service ini dipakai OpenLDAP untuk mendekripsi token GSSAPI dari klien. Setelah keytab tersedia dan daemon membaca KRB5_KTNAME, server siap menerima bind SASL.

LDAP client SASL binds. Dari sisi klien, cukup punya tiket dan memakai -Y GSSAPI:

kinit alice
ldapwhoami -Y GSSAPI -H ldap://ldap1.example.com

Respons seperti dn:uid=alice,ou=people,dc=example,dc=com membuktikan dua hal sekaligus: tiket diterima server, dan identitas principal berhasil dipetakan ke entri direktori.

#Integrasi OpenLDAP

slapd.conf atau cn=config. Konfigurasi OpenLDAP bisa berbasis file slapd.conf atau ditulis dinamis di cn=config. Untuk SASL GSSAPI, kedua cara mengarah pada pemetaan realm dan principal:

SASL realm mapping. OpenLDAP harus tahu bahwa realm Kerberos EXAMPLE.COM sama dengan domain direktori dc=example,dc=com. Ini diatur dengan sasl-realm:

cn=config - pemetaan SASL realm dan principal

olcSaslRealm: EXAMPLE.COM
olcSaslHost: ldap1.example.com
olcSaslSecProps: minssf=0
olcAuthzRegexp: ^uid=([^,]+).*$ uid=$1,ou=people,dc=example,dc=com

Kerberos principal to DN mapping. Baris olcAuthzRegexp di atas adalah jantung pemetaan: setiap principal alice@EXAMPLE.COM (diwakili SASL sebagai uid=alice@EXAMPLE.COM,cn=gssapi,cn=auth) diubah menjadi DN penuh uid=alice,ou=people,dc=example,dc=com. Tanpa aturan ini, bind GSSAPI berhasil tapi identitas tidak dikaitkan ke entri mana pun.

#Active Directory

AD as KDC. Active Directory pada dasarnya adalah KDC Kerberos yang membungkus tiket dengan atribut Microsoft: domain menjadi realm, Domain Controller menjadi KDC, dan tiket membawa PAC berisi keanggotaan grup. Yang menarik bagi kita: karena AD berbicara Kerberos standar, klien Linux dan layanan MIT bisa ikut di realm yang sama.

Kerberos tickets from AD. Saat mesin Linux di-join ke domain AD, ia mendapat tiket dari DC layaknya klien Windows. klist di Linux menampilkan tiket dengan principal user@AD.EXAMPLE.COM — realm Kerberosnya adalah nama domainnya.

Cross-realm with AD. Alih-alih menggabungkan seluruh organisasi ke satu realm, banyak perusahaan memilih cross-realm trust: realm MIT EXAMPLE.COM dan realm AD AD.EXAMPLE.COM saling mempercayai melalui tiket antar-realm. User dari satu realm bisa memakai tiket untuk mengakses layanan di realm lain, tanpa akun ganda.

Linux clients with AD. Klien Linux mengonsumsi AD lewat SSSD atau pam_krb5 + LDAP: autentikasi memakai Kerberos terhadap DC, atribut (UID, group, shell) diambil dari LDAP di belakangnya. Dari perspektif Kerberos murni, ini hanya persoalan menunjuk kdc dan admin_server ke DC dan menambahkan mapping realm di /etc/krb5.conf.

#Penutup

Episode ini menyatukan dua pilar identitas: Kerberos untuk autentikasi dan LDAP untuk direktori. Kalian menaruh principal KDC di backend LDAP lewat kldap dan [dbmodules], mengimpor kerberos.schema, membangun container serta ACL, menghidupkan bind SASL/GSSAPI dengan principal ldap/ldap1.example.com, memetakan principal ke DN lewat olcAuthzRegexp, dan melihat bagaimana Active Directory menempati peran yang sama sebagai KDC serta mitra cross-realm.

Inti yang harus dibawa pulang:

• LDAP backend menjadikan principal KDC data terkelola — satu direktori jadi sumber kebenaran, satu entri mewakili satu user beserta atributnya.
• Bind SASL/GSSAPI menggantikan password polos: ldapwhoami -Y GSSAPI memakai tiket, dan olcAuthzRegexp memetakan principal alice@EXAMPLE.COM ke DN yang sesungguhnya.
• KDC dengan backend LDAP butuh persiapan ekstra: skema kerberos.schema, container cn=krbContainer, akun service, dan ACL ketat — jangan beri akun KDC hak admin direktori.
• Active Directory adalah KDC Kerberos standar, dan integrasi dengan realm MIT dilakukan lewat cross-realm trust, bukan dengan menumpuk dua KDC di realm yang sama.

Di episode 18 kita membongkar sisi Windows secara penuh: Kerberos di Active Directory — dari peran Domain Controller, akun krbtgt, sampai konsekuensi komprominya berupa golden ticket. Sampai jumpa!