Belajar Kerberos - Troubleshooting

#Pendahuluan

Di episode 22 kalian membangun mata realm: log KDC yang terkonfigurasi, jejak klien dengan KRB5_TRACE, analisis pola kegagalan, dan metrik yang dipantau. Sekarang waktunya memakai semua itu untuk menyembuhkan. Error Kerberos bisa tampak membingungkan, tapi hampir semuanya berasal dari enam penyebab yang sama.

Episode 23 adalah panduan troubleshooting lapangan: memetakan error umum ke penyebab dan solusinya, teknik debugging dari sisi klien sampai packet capture, diagnosis jaringan dan waktu, hingga masalah keytab yang paling sering menyusahkan administrasi.

#Masalah Umum dan Solusinya

Sebagian besar error Kerberos masuk ke salah satu dari enam kategori berikut. Hafalkan tabel ini — ini akan menjadi rujukan pertama kalian:

Error	Penyebab umum	Perbaikan
Clock skew too great	Jam klien melenceng lebih dari toleransi (default 5 menit)	Sinkronkan dengan NTP, cek timezone
Server not found in Kerberos database	SPN atau principal tidak terdaftar di KDC	Daftarkan principal, cek ejaan realm
Preauthentication failed	Password salah atau preauth tidak sesuai	Verifikasi password, cek waktu, cek `kinit` manual
Ticket expired	Tiket melewati masa berlaku atau renew tidak dilakukan	Jalankan `kinit` ulang, periksa lifetime
Cannot contact KDC	KDC tidak terjangkau (jaringan, port 88, DNS)	Cek port 88, firewall, resolusi nama
Credential cache not found	`KRB5CCNAME` menunjuk cache yang tidak ada	Atur `KRB5CCNAME`, periksa path cache

#Clock Skew Too Great

KDC menolak permintaan jika selisih jam klien dan KDC melebihi toleransi — default MIT adalah 5 menit. Gejala paling umum adalah Clock skew too great pada kinit. Verifikasi waktu dengan timedatectl status dan periksa apakah NTP berjalan.

#Server Not Found in Kerberos Database

KDC tidak mengenali principal yang diminta. Ini biasanya karena SPN belum terdaftar, realm salah, atau akun tidak ada di AD. Periksa dengan kadmin getprinc dan bandingkan ejaan realm dengan konfigurasi.

#Preauthentication Failed

KDC menolak bukti preauth — paling sering karena password salah, tapi bisa juga karena jam melenceng sehingga timestamp preauth ditolak. Coba kinit manual dengan trace untuk melihat detailnya.

#Ticket Expired

TGT hanya berlaku sesuai lifetime. Job panjang yang melewati masa berlaku akan gagal dengan tiket kedaluwarsa; atur renewlife atau jalankan ulang kinit.

#Cannot Contact KDC

Klien tidak bisa menjangkau KDC — masalah jaringan atau DNS. Periksa port 88/tcp dan 88/udp menuju KDC, serta resolusi nama realm.

#Credential Cache Not Found

Library tidak menemukan cache tiket yang ditunjuk KRB5CCNAME. Cache bisa berpindah saat berganti user atau sesi; set variabel ke path yang benar atau jalankan kinit ulang.

#Teknik Debugging

Saat error tidak jelas, mundurlah selangkah dan gunakan alat debugging — jangan menebak.

#KRB5_TRACE untuk Jejak Lengkap

Jejak sisi klien menunjukkan setiap langkah yang dilakukan library — realm yang dipilih, KDC yang dihubungi, enctypes yang ditawarkan, dan pesan error mentah:

Jejak lengkap kinit dengan KRB5_TRACE

export KRB5_TRACE=/dev/stdout
kinit alice@EXAMPLE.COM

Cari baris yang mengandung error atau failed di output trace; pesan KDC biasanya menyebut penyebab sebenarnya — misalnya KRB5KDC_ERR_PREAUTH_FAILED atau KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.

#klist -e untuk Enkripsi

Periksa enctypes tiket yang disimpan. Ketidakcocokan enkripsi antara klien, KDC, dan service adalah sumber error KDC has no support for encryption type:

Lihat enctypes pada tiket yang tersimpan

klist -e

Jika tiket muncul dengan enctype RC4 padahal AES seharusnya dipakai, ada konfigurasi downgrade — kembali ke hardening episode 21.

#kadmin getprinc untuk Detail Principal

Periksa detail principal langsung dari database KDC — masa berlaku, flags, dan KVNO kunci:

Periksa detail principal di MIT

sudo kadmin.local -q "getprinc alice@EXAMPLE.COM"

#Wireshark dan tcpdump

Saat masalah di jaringan atau protokol, capture lalu lintas Kerberos. tcpdump untuk menangkap di sisi server, Wireshark untuk analisis:

Capture lalu lintas Kerberos

sudo tcpdump -i eth0 -n port 88 -w kerberos.pcap

Di Wireshark, filter krb5 menampilkan AS_REQ, AS_REP, TGS_REQ, dan TGS_REP. Bandingkan paket gagal dengan paket sukses untuk menemukan perbedaannya — sering kali jawabannya ada di error-code paket Kerberos.

#Debugging Jaringan

Kerberos bergantung penuh pada DNS dan konektivitas. Periksa keduanya sebelum menyalahkan KDC.

#DNS Resolution Checks

Klien mencari KDC lewat SRV record realm. Pastikan record ada dan bisa di-resolve:

Periksa resolusi realm dan KDC

dig +short _kerberos._tcp.example.com SRV
dig +short dc01.example.com A
getent ahosts dc01.example.com

#Port Connectivity

KDC melayani di port 88/tcp dan 88/udp (AS/TGS), serta 749/tcp untuk kadmin. Uji koneksi:

Uji konektivitas port Kerberos

nc -zv dc01.example.com 88
nc -uzv dc01.example.com 88
nc -zv dc01.example.com 749

#Firewall Rules

Port yang diblokir firewall menyebabkan Cannot contact any KDC. Periksa rule di klien dan server, pastikan 88/tcp, 88/udp, dan 749/tcp terbuka dari jaringan yang tepat.

#Packet Capture Analysis

Jika koneksi TCP berhasil tapi permintaan tetap gagal, capture di kedua sisi. Paket yang terkirim tapi tak ada balasan menandakan paket diblokir; balasan dengan error code menandakan masalah protokol.

Tip

Kerjakan debugging jaringan secara urut: DNS dulu, lalu port 88, baru packet capture. Membuka Wireshark sebelum memastikan DNS dan port benar hanya akan membuang waktu.

#Masalah Sinkronisasi Waktu

Waktu adalah musuh senyap Kerberos. Sinkronisasi waktu yang buruk menghasilkan error yang menyesatkan — Clock skew too great atau bahkan Preauthentication failed.

Clock skew detection: timedatectl menampilkan status sinkronisasi; bandingkan dengan waktu KDC menggunakan timedatectl atau chronyc.
NTP verification: pastikan chronyd atau ntpd berjalan dan terkunci ke sumber waktu:

Verifikasi sinkronisasi waktu

timedatectl status
chronyc sources -v
chronyc tracking

Time source issues: KDC dan semua klien harus menggunakan sumber waktu yang sama — sebaiknya KDC itu sendiri atau sumber tepercaya bersama, bukan sumber yang berbeda.
Timezone problems: zoneinfo yang salah membuat jam tampak benar di layar tapi tetap melenceng di hitungan epoch. Set TZ dengan benar dan biarkan jam disimpan dalam UTC.

#Troubleshooting Keytab

Keytab yang bermasalah menyebabkan autentikasi mesin dan service gagal secara sporadis. Periksa dengan klist:

Verifikasi isi keytab

klist -kt /etc/krb5.keytab

KVNO mismatches: tiap entry di keytab memiliki versi kunci (KVNO). Jika kunci akun di AD sudah di-reset (KVNO naik) tapi keytab masih memegang KVNO lama, autentikasi gagal dengan KRB_AP_ERR_BADKEYVER. Bandingkan KVNO di keytab dengan nilai dari kadmin getprinc; regenerate keytab bila berbeda.
Missing entries: keytab tidak memuat SPN yang dibutuhkan. Bandingkan output klist -kt dengan daftar SPN akun; tambahkan entry lewat msktutil add-sph atau ktpass.
Permission issues: keytab yang bisa dibaca proses aplikasi — atau justru tidak bisa dibaca karena permission salah — memunculkan error saat service mencoba autentikasi. Pastikan file milik user service dengan mode yang sesuai.
Expired keys: password akun yang di-reset di AD membuat kunci di keytab kedaluwarsa. Buat keytab ulang setelah reset password akun layanan.

Tambah SPN ke keytab dengan msktutil

msktutil add-sph --service HTTP/web01.example.com \
  --keytab /etc/krb5.keytab

#Penutup

Episode 23 ini menutup daur troubleshooting: enam error umum dipetakan ke penyebab dan perbaikannya, teknik debugging dari KRB5_TRACE sampai tcpdump diuraikan, jaringan dan waktu didiagnosis langkah demi langkah, dan masalah keytab seperti KVNO mismatch serta permission dipecahkan.

Inti yang harus dibawa pulang:

Enam error utama — clock skew, principal not found, preauth, expired, cannot contact KDC, dan cache tidak ditemukan — mencakup hampir semua masalah.
KRB5_TRACE=/dev/stdout, klist -e, dan kadmin getprinc adalah trio debugging utama.
Kerjakan jaringan secara urut: DNS, port 88, baru packet capture.
Waktu dan keytab adalah dua sumber masalah paling sering — verifikasi keduanya lebih dulu.

Di episode 24, pertanyaan kalian berubah dari "kenapa gagal" menjadi "kenapa lambat": Performance Tuning — optimasi database KDC, replica KDC untuk pembagian beban, worker threads, dan strategi caching. Sampai jumpa!