Belajar Kerberos - DNS & Time Synchronization Prerequisites

#Pendahuluan

Di episode 3 kalian melihat alur autentikasi Kerberos secara menyeluruh — dan di sana ada dua hal yang menonjol sebagai fondasi semua alur itu: timestamp yang menjadi bahan authenticator, dan resolusi nama yang menjadi cara client menemukan KDC. Episode 3 menutup dengan peringatan bahwa sinkronisasi waktu adalah bagian dari mekanisme keamanan Kerberos itu sendiri. Sekarang saatnya membuktikannya.

Episode ini akan membedah dua prasyarat infrastruktur yang paling sering merusak implementasi Kerberos di dunia nyata: sinkronisasi waktu dan DNS. Kalian akan menyiapkan NTP dengan chrony, memahami toleransi jam 5 menit dan cara menyesuaikannya, membuat record SRV untuk penemuan KDC, menyiapkan fallback /etc/hosts, serta belajar memecahkan error Clock skew too great yang legendaris. Mari kita mulai dari yang paling kritis: waktu.

#Mengapa Sinkronisasi Waktu Begitu Kritis

Ingat kembali mekanisme di episode 3: authenticator berisi timestamp yang dienkripsi dengan session key, dan server menyimpan timestamp tersebut di replay cache. Keduanya hanya bermakna jika semua pihak memiliki pemahaman waktu yang sama.

#Timestamp dan Replay Protection

Timestamp memiliki dua fungsi:

1. Menjaga kesegaran — jika timestamp terlalu lama, permintaan dianggap basi dan ditolak.
2. Menjaga keunikan — jika timestamp sudah terlihat sebelumnya (tersimpan di replay cache), permintaan dianggap pengulangan (replay) dan ditolak.

Tanpa sinkronisasi jam, fungsi ini hancur. Jam client yang lambat membuat timestamp selalu "di masa lalu", sehingga permintaan valid ditolak. Jam client yang terlalu cepat membuat timestamp "dari masa depan", yang juga dicurigai. Kedua kondisi ini muncul sebagai satu pesan error yang sama.

#Toleransi Default: 5 Menit

Kerberos memiliki toleransi bawaan sebesar 300 detik (5 menit) — nilai clockskew default. Artinya selisih jam antara client, KDC, dan service boleh sampai 5 menit. Ini cukup longgar untuk mengakomodasi penyimpangan jam normal, tapi cukup ketat untuk mencegah replay attack dengan jendela yang tidak masuk akal.

#Error Clock Skew Too Great

Ketika selisih jam melampaui toleransi, KDC atau service menjawab dengan error klasik:

kinit: Preauthentication failed while getting initial credentials

Clock skew too great (37 seconds)

Angka dalam kurung memberi petunjuk besar selisihnya. Perhatikan bahwa error bisa muncul di permukaan sebagai Preauthentication failed — artinya debugging butuh jejak yang lebih dalam. Cara tercepat mengetahuinya: jalankan KRB5_TRACE=1 kinit di lab.

#Setup Sinkronisasi Waktu dengan chrony

Kita akan memakai chrony — implementasi NTP modern yang tersedia di Ubuntu Server. Install di ketiga VM (KDC dan kedua client):

Install chrony di semua VM

sudo apt update
sudo apt install chrony -y

Di lingkungan lab, semua VM bisa menunjuk ke satu sumber waktu yang sama — misalnya server NTP publik atau VM yang bertindak sebagai time server. Konfigurasi default di /etc/chrony/chrony.conf sudah menunjuk ke pool NTP publik:

# Use public servers from the pool.ntp.org project.
pool 2.ubuntu.pool.ntp.org iburst

Untuk lab yang terisolasi, kalian bisa menambahkan server waktu internal. Aktifkan dan verifikasi:

sudo systemctl enable --now chrony
chronyc tracking
timedatectl

Output chronyc tracking menunjukkan status sinkronisasi: field System time menunjukkan selisih jam sistem terhadap sumber waktu. Jika semua VM disinkronkan ke sumber yang sama, selisih antar VM akan sangat kecil — jauh di bawah toleransi 5 menit.

#Konfigurasi clockskew di krb5.conf

Toleransi 5 menit adalah default, tapi bisa diubah melalui file /etc/krb5.conf. Di section [libdefaults], tambahkan nilai clockskew dalam detik:

[libdefaults]
    default_realm = EXAMPLE.COM
    clockskew = 300
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true

Nilai 300 sama dengan default, tapi menuliskannya secara eksplisit membuat konfigurasi kalian jelas dan mudah disesuaikan. Dalam praktik, admin yang teliti kadang memperbesar nilai ini di lingkungan dengan jam yang sulit dijaga — tetapi hati-hati: semakin besar toleransi, semakin lebar jendela replay attack yang diperbolehkan.

#DNS untuk Kerberos

DNS adalah cara client menemukan KDC. Tanpa DNS yang benar, client tidak akan pernah menemukan server yang harus diajak bicara — bahkan jika waktu sudah sempurna.

#Forward dan Reverse Lookup

Kerberos sangat bergantung pada nama:

• Forward lookup — nama host menjadi alamat IP.
• Reverse lookup — alamat IP menjadi nama host.

Service principal menggunakan nama host seperti host/kdc.example.com@EXAMPLE.COM, dan service perlu memvalidasi bahwa client menghubungi nama yang benar. DNS yang tidak konsisten — nama hostname berbeda dengan record DNS, atau reverse lookup yang tidak sesuai — adalah sumber error Server not found in Kerberos database.

#SRV Records: Penemuan KDC

Untuk menemukan KDC, client membaca SRV record di zona DNS realm. Tiga record utama yang harus ada:

Contoh di zona BIND (db.example.com):

$ORIGIN example.com.
_kerberos._udp        SRV 0 0 88 kdc.example.com.
_kerberos._tcp        SRV 0 0 88 kdc.example.com.
_kerberos-master._tcp SRV 0 0 88 kdc.example.com.
_kpasswd._udp         SRV 0 0 464 kdc.example.com.

#TXT Record: Informasi Realm

Satu record TXT lagi membantu client mengetahui realm mana yang sesuai dengan domain:

$ORIGIN example.com.
_kerberos.example.com. TXT "EXAMPLE.COM"

#Testing dengan dig

Setelah record dibuat, verifikasi dengan dig:

dig +short _kerberos._udp.example.com SRV
dig +short -x 192.168.10.10
dig +short _kerberos.example.com TXT

Jika dig +short _kerberos._udp.example.com SRV mengembalikan 0 0 88 kdc.example.com., client akan menemukan KDC dengan benar. Kalian juga bisa menguji resolusi client langsung lewat getent hosts kdc.example.com.

#Fallback: /etc/hosts

Untuk lab kecil atau environment tanpa DNS penuh, Kerberos bisa memakai /etc/hosts sebagai fallback. Di setiap VM, tambahkan baris berikut:

192.168.10.10   kdc.example.com     kdc
192.168.10.21   client1.example.com client1
192.168.10.22   client2.example.com client2

#Troubleshooting Time Skew

Ketika error muncul, gunakan urutan periksa berikut:

date --set="2026-08-03 10:00:00"

Jika ditemukan selisih besar, perbaiki jam sistem — di lab sering cukup menulis ulang jam dengan date --set, lalu pastikan chrony menjaga konsistensi setelahnya. Di produksi, perbaiki sumber NTP dan biarkan sinkronisasi bekerja otomatis.

#Penutup

Episode ini menangani dua prasyarat infrastruktur yang paling sering menghancurkan Kerberos: sinkronisasi waktu dan DNS. Kalian sudah menyiapkan chrony di semua VM, memahami toleransi clockskew 5 menit dan cara mengubahnya di krb5.conf, membuat record SRV _kerberos, _kerberos-master, dan _kpasswd beserta record TXT realm, memakai /etc/hosts sebagai fallback lab, serta belajar urutan troubleshooting error Clock skew too great.

Poin penting yang harus kalian bawa:

• Timestamp adalah bagian dari mekanisme keamanan Kerberos — waktu harus sinkron.
• Toleransi default 300 detik; diperkecil untuk keamanan ketat, diperbesar hanya bila perlu.
• SRV record adalah cara client menemukan KDC; TXT record menghubungkan domain ke realm.
• dig adalah alat verifikasi DNS tercepat; /etc/hosts adalah penyelamat lab kecil.
• Error Clock skew too great biasanya bersembunyi di balik Preauthentication failed — gali dengan KRB5_TRACE=1.

Di episode 5 selanjutnya kita akan merakit semuanya: menginstall MIT Kerberos KDC — dari instalasi paket, konfigurasi realm di krb5.conf dan kdc.conf, pembuatan database dengan kdb5_util, pembuatan principal pertama, sampai verifikasi kinit dan klist. Inilah episode di mana lab kalian benar-benar hidup. Sampai jumpa!