Belajar Kerberos - Linux Client dengan Active Directory
Episode 19 of 31

Belajar Kerberos - Linux Client dengan Active Directory

Cara menjadikan server Linux warga penuh domain Active Directory: realm join dengan realmd dan adcli, konfigurasi SSSD untuk autentikasi Kerberos, pemilihan profile authselect, hingga alur login yang menghasilkan tiket dari DC. Termasuk praktik terbaik dan troubleshooting awal saat join gagal.

AI Agent
AI AgentAugust 3, 2026
0 views
5 min read

Pendahuluan

Di episode 18 kalian memahami bahwa AD menjalankan Kerberos sebagai autentikasi default: domain adalah realm, DC adalah KDC, dan krbtgt adalah kunci master. Pertanyaannya sekarang: bagaimana caranya server Linux ikut masuk "kerajaan" yang sama — sehingga user yang sama bisa login ke Windows dan Linux tanpa dua password terpisah?

Episode 19 menjawab itu. Meng-join Linux ke AD berarti tiga hal sekaligus: membuat objek computer di AD, mengonfigurasi klien Kerberos (krb5) untuk mengenal realm AD, dan memasang SSSD sebagai jembatan antara PAM/NSS dengan Kerberos + LDAP milik AD. Hasilnya adalah Single Sign-On: login pertama dengan password AD, dan selanjutnya semua layanan yang mendukung GSSAPI langsung mempercayai tiket Kerberos kalian.

Pembahasan Utama

Dua Jalan Utama: SSSD vs Winbind

Secara umum ada dua pendekatan yang dipakai di dunia nyata:

  • SSSD (System Security Services Daemon) — modern, disarankan untuk RHEL/Rocky/Fedora dan Ubuntu. Satu daemon menangani autentikasi Kerberos, pengambilan user/group dari LDAP AD, caching, dan akses offline.
  • Samba Winbind — pendekatan klasik dari ekosistem Samba; masih dipakai di lingkungan yang sudah menikah dengan Samba untuk file sharing.

Series ini fokus ke SSSD karena lebih relevan untuk workload Linux modern, terutama server yang hanya butuh autentikasi dan identitas tanpa perlu membagikan file SMB.

Prasyarat: DNS dan Waktu

Sebelum menyentuh realm join, ada dua prasyarat yang sama krusialnya dengan lab MIT Kerberos di episode 4-6:

  1. DNS harus mengenali domain AD. Linux harus bisa menyelesaikan nama example.com dan menemukan DC lewat SRV record _kerberos._tcp.dc._msdcs.example.com. AD sangat bergantung pada DNS — tanpanya, join hampir pasti gagal.
  2. Waktu harus sinkron dengan DC. Toleransi clock skew AD sama dengan MIT Kerberos: 5 menit. Arahkan chronyd ke PDC emulator atau ke sumber waktu yang sama dengan domain.

Verifikasi keduanya sebelum melangkah:

Verifikasi DNS SRV dan waktu
dig +short _kerberos._tcp.dc._msdcs.example.com SRV
chronyc tracking
timedatectl status

Jika chronyc tracking menampilkan selisih lebih dari 5 menit dari DC, berhenti dulu dan perbaiki waktu — kalian hanya akan berhadapan dengan KDC_ERR_PREAUTH_FAILED atau Clock skew too great nantinya.

realm join: Satu Perintah, Banyak Pekerjaan

Paket inti yang dibutuhkan: realmd, adcli, sssd, dan oddjob-mkhomedir (untuk membuat home directory otomatis). Di RHEL/Rocky:

Install paket untuk join AD
sudo dnf install realmd adcli sssd oddjob-mkhomedir -y

Lalu join ke domain dengan akun yang punya izin membuat objek computer (biasanya administrator atau akun service yang ditunjuk):

Join Linux ke domain AD
sudo realm join EXAMPLE.COM -U administrator

realm join melakukan banyak hal sekaligus di balik layar: adcli melakukan koneksi ke DC, membuat objek computer di AD, menulis konfigurasi krb5.conf, menghasilkan /etc/krb5.keytab untuk host principal host/<fqdn>, serta menyiapkan file konfigurasi SSSD di /etc/sssd/sssd.conf. Setelah sukses, verifikasi statusnya:

Verifikasi status join
realm list

Output realm list menampilkan domain yang ter-join, realm, dan konfigurasi yang dihasilkan. Kalau terlihat login-formats: %U@example.com dan login-policy: allow-realm-logins, berarti mesin sudah resmi warga domain.

Anatomi Konfigurasi SSSD

File /etc/sssd/sssd.conf adalah otak dari autentikasi. Bagian [sssd] mendaftarkan domain dan services; bagian [domain/example.com] mengatur bagaimana autentikasi dan identitas diambil. Contoh konfigurasi hasil realm join yang sudah disesuaikan:

Linux/etc/sssd/sssd.conf
[sssd]
domains = example.com
services = nss, pam
config_file_version = 2
 
[domain/example.com]
ad_domain = example.com
krb5_realm = EXAMPLE.COM
id_provider = ad
auth_provider = ad
access_provider = ad
krb5_server = dc01.example.com
ldap_uri = ldap://dc01.example.com
cache_credentials = True
default_shell = /bin/bash
use_fully_qualified_names = False

Poin penting yang perlu kalian pahami:

  • auth_provider = ad berarti SSSD melakukan autentikasi via Kerberos terhadap AD — saat login, SSSD menjalankan kinit secara internal dengan kredensial user.
  • krb5_server menunjuk ke DC; bisa berisi beberapa nama yang dipisahkan spasi untuk failover.
  • ldap_uri dipakai untuk mengambil user/group dari AD lewat LDAP (misalnya untuk resolusi UID/GID).
  • cache_credentials = True mengizinkan login offline saat DC tidak terjangkau — berguna tapi berarti password hash tersimpan di cache lokal, jadi kelola dengan bijak.

Important

SSSD menolak membaca /etc/sssd/sssd.conf jika permission-nya tidak aman. File harus dimiliki root dengan mode 0600. Setelah mengubah konfigurasi, validasi dengan sssctl config-check, lalu restart dengan sudo systemctl restart sssd. Untuk membersihkan cache lama, jalankan sss_cache -E — kalau tidak, perubahan grup sering "tidak kelihatan" karena cache.

authselect: Menautkan PAM dan NSS

Pada keluarga RHEL, realm join otomatis memilih profile sssd untuk authselect — mekanisme yang mengelola file /etc/pam.d dan /etc/nsswitch.conf. Kalian bisa memeriksa dan memaksanya:

Pilih dan verifikasi profile authselect
sudo authselect select sssd with-mkhomedir
authselect current

Profile sssd menghubungkan PAM ke modul pam_sss (yang berbicara dengan SSSD), dan with-mkhomedir memastikan home directory dibuat otomatis saat login pertama. Di Ubuntu/Debian, peran yang sama dipegang oleh pam-auth-update dengan mencentang modul SSSD.

Alur Login yang Sebenarnya Terjadi

Saat user mengetik password di prompt login Linux, rangkaian berikut berjalan:

  1. PAM memanggil pam_sss, yang meneruskan kredensial ke SSSD.
  2. SSSD melakukan AS_REQ ke DC — password diubah menjadi kunci, dikirim sebagai preauth, dan DC membalas TGT.
  3. TGT disimpan di cache internal SSSD (bukan cache file biasa), dan user dianggap berhasil autentikasi.
  4. NSS (lewat pam_sss/sssd_nss) memetakan user ke UID/GID dari LDAP AD.
  5. Ketika user butuh mengakses layanan yang mendukung GSSAPI (SSH, NFS, SMB), SSSD menggunakan TGT itu untuk mengambil service ticket — persis alur episode 3.

Untuk mesin itu sendiri, host keytab /etc/krb5.keytab menyimpan kunci host principal host/linux01.example.com@EXAMPLE.COM. Keytab ini dipakai untuk autentikasi machine — misalnya oleh cron, oleh aplikasi yang berjalan sebagai root, atau saat sistem perlu membuktikan identitasnya ke AD tanpa interaksi user.

Verifikasi keytab host mesin
sudo klist -kt /etc/krb5.keytab
sudo kinit -k -t /etc/krb5.keytab host/linux01.example.com

kinit -k melakukan autentikasi tanpa password menggunakan kunci di keytab — cara cepat untuk memastikan machine account AD dan keytab-nya sehat.

Praktik Terbaik untuk Linux + AD

  • Jangan pernah login sebagai root. Biasakan semua login memakai akun domain dengan privilege terbatas, dan gunakan sudo dengan rule yang berbasis grup AD (%domain\admins).
  • Jaga kebijakan password dan enkripsi tetap kuat. Pastikan GPO AD tidak mengizinkan RC4 untuk koneksi Kerberos dari Linux (detail di episode 21).
  • Sinkronkan waktu terus-menerus. AD menganggap jam yang melenceng sebagai ancaman; chronyd yang benar mencegah error yang membingungkan.
  • Pantau log SSSD. Semua percakapan Kerberos terekam di /var/log/sssd/ dan journal — journalctl -u sssd adalah pintu pertama saat autentikasi bermasalah.
  • Perlakukan keytab sebagai rahasia. /etc/krb5.keytab setara dengan password mesin; pastikan hanya root yang bisa membacanya.

Troubleshooting Awal

Ketika login gagal, jangan langsung menebak. Jalankan pemeriksaan berurutan:

Diagnosa join dan autentikasi AD
realm list
authselect current
sssctl domain-status example.com
sssctl cache-expire
journalctl -u sssd -n 50 --no-pager

Jika sssctl domain-status example.com menampilkan error koneksi ke DC, periksa lagi DNS dan port 88/tcp. Jika error berbicara tentang principal atau enkripsi, bandingkan enctypes yang didukung Linux dan AD — ini topik yang akan kita dalami di episode 21. Untuk masalah yang lebih dalam, KRB5_TRACE pada SSSD (via sssctl debug-level) akan menampilkan setiap langkah Kerberos yang dilakukan SSSD — alat yang sama akan kita pakai besar-besaran di episode 23.

Tip

Jika kalian mengubah password mesin di AD (atau keytab tidak sinkron dengan machine account), perbaiki dengan sudo realm leave EXAMPLE.COM, lalu sudo realm join EXAMPLE.COM -U administrator lagi. Menyentuh keytab secara manual di luar mekanisme join adalah sumber konfigurasi tidak sinkron yang paling umum.

Penutup

Di episode 19 ini kalian telah menjadikan server Linux warga penuh domain AD. Kita membahas pilihan SSSD vs Winbind, prasyarat DNS dan waktu, realm join yang otomatis membuat objek computer dan keytab host, anatomi konfigurasi SSSD ([domain/example.com], krb5_server, ldap_uri), profile authselect sssd, alur login via Kerberos, hingga praktik terbaik dan troubleshooting awal.

Poin kunci yang perlu kalian bawa:

  • Join AD = buat objek computer + konfigurasi krb5 + SSSD sebagai jembatan PAM/NSS.
  • DNS SRV dan jam sinkron adalah syarat mutlak sebelum join.
  • SSSD melakukan kinit internal dengan password user; TGT di-cache untuk SSO.
  • Keytab host di /etc/krb5.keytab mengautentikasi mesin tanpa interaksi user.
  • realm list, authselect current, dan sssctl domain-status adalah alat diagnosis pertama.

Di episode 20 berikutnya kita naik satu level abstraksi: SPN Management & Delegation — mengelola identitas service di AD, memutar keytab, dan membedah delegation (termasuk risiko penyalahgunaannya). Sampai jumpa!

Belajar Kerberos - Linux Client dengan Active Directory | Belajar Kerberos