Belajar Active Directory - Kerberos Authentication dalam Active Directory

#Pendahuluan

Di episode 12 kita mengamankan AD dari sisi kebijakan: least privilege, tiered administration, Protected Users, hingga Credential Guard. Tapi semua lapisan itu bekerja di atas sebuah fondasi yang lebih dalam — protokol yang menentukan cara setiap orang membuktikan identitasnya. Tanpa memahami fondasi ini, banyak langkah keamanan yang kita bahas terasa seperti kotak hitam. Fondasi itu adalah Kerberos.

Kerberos adalah protokol autentikasi default Active Directory sejak Windows 2000. Nama ini diambil dari mitologi Yunani — anjing berkepala tiga penjaga gerbang Hades. Analoginya pas: Kerberos berjaga di "pintu masuk" setiap layanan jaringan di domain, dan hanya meloloskan mereka yang benar-benar punya bukti identitas.

Coba bayangkan sebuah hotel mewah. Saat kalian check-in di resepsionis (Key Distribution Center), kalian membuktikan identitas dan menerima sebuah kartu kunci kamar (TGT). Kartu kunci itu bukan kunci kamar spesifik — ia adalah bukti bahwa kalian sudah check-in. Dengan kartu itu, kalian bisa ke berbagai fasilitas: ke gym, ke kolam renang, ke lounge — setiap kali menukarkannya dengan pass khusus fasilitas (service ticket). Inilah inti Kerberos: membuktikan identitas sekali, lalu memakai bukti itu untuk mengakses banyak layanan.

#Komponen Kerberos di Active Directory

Kerberos bekerja dengan beberapa komponen kunci yang semua berjalan di Domain Controller:

• KDC (Key Distribution Center) — "resepsionis" yang memverifikasi identitas dan menerbitkan tiket. Di AD, setiap DC adalah KDC, sehingga tidak ada satu titik kegagalan.
• krbtgt — akun khusus yang kunci kriptografinya dipakai untuk mengenkripsi dan memvalidasi TGT. Akun ini dinonaktifkan, tidak pernah dipakai login, dan passwordnya dikenal oleh seluruh KDC di domain. Inilah "master key" seluruh sistem tiket.
• SPN (Service Principal Name) — identitas unik sebuah layanan dalam bentuk service/host, misalnya http/srv-web01.corp.local. SPN adalah alamat yang dicari saat klien meminta service ticket.
• PAC (Privilege Attribute Certificate) — paket data di dalam tiket yang membawa informasi otorisasi: SID group, keanggotaan, dan izin user. Inilah yang membuat tiket "mengerti" siapa pemegangnya dan apa yang boleh dilakukan.

#Alur Autentikasi: Perjalanan Sebuah Tiket

Kerberos bekerja dalam tiga pertukaran pesan. Mari kita ikuti saat user jsantoso ingin mengakses server file SRV-FILE01.

#Langkah 1: AS-REQ dan AS-REP — Minta TGT

Klien mengirim AS-REQ (Authentication Service Request) ke KDC: "Saya jsantoso, dan ini bukti bahwa saya tahu password saya." KDC memverifikasi, lalu membalas dengan AS-REP yang berisi TGT (Ticket-Granting Ticket) — tiket yang "menandai" klien sebagai user yang sudah terverifikasi.

Yang penting dipahami: password tidak pernah dikirim lewat jaringan. Kunci yang diturunkan dari password (long-term key) dipakai untuk mengenkripsi TGT, dan hanya klien yang tahu passwordnya yang bisa membukanya kembali.

#Langkah 2: TGS-REQ dan TGS-REP — Minta Service Ticket

Klien yang ingin mengakses SRV-FILE01 sekarang mengirim TGS-REQ (Ticket-Granting Service Request) ke KDC: "Ini TGT saya, dan saya ingin akses ke layanan cifs/SRV-FILE01." KDC memverifikasi TGT, memeriksa bahwa user memang punya hak, lalu membalas TGS-REP dengan service ticket untuk layanan itu.

#Langkah 3: AP-REQ dan AP-REP — Presentasi ke Layanan

Klien mengirim AP-REQ (Application Request) ke server SRV-FILE01: "Ini service ticket saya." Server memverifikasi tiket dengan kunci miliknya sendiri, membaca PAC di dalamnya untuk menentukan izin, dan membuka akses. Dari sini, komunikasi bisa dilanjutkan tanpa lagi melibatkan KDC.

Klien --> KDC        : AS-REQ  (saya user X, beri saya TGT)
KDC   --> Klien      : AS-REP  (ini TGT anda, terenkripsi)
Klien --> KDC        : TGS-REQ (ini TGT, saya mau akses layanan Y)
KDC   --> Klien      : TGS-REP (ini service ticket untuk layanan Y)
Klien --> Layanan Y  : AP-REQ  (ini service ticket saya)
Layanan Y --> Klien  : AP-REP  (akses dibuka)

Keindahan model tiket: klien hanya berhubungan langsung dengan KDC dua kali per sesi (TGT dan service ticket), bukan untuk setiap akses. TGT berlaku selama beberapa jam (default 10 jam), dan dalam masa itu klien bisa meminta banyak service ticket tanpa perlu memasukkan password lagi. Inilah dasar dari SSO (Single Sign-On) yang terasa "magis" di Windows.

#Kerberos vs NTLM: Kenapa Kerberos Lebih Unggul

Kerberos menggantikan NTLM karena alasan yang sangat teknis dan praktis:

• Kerberos punya mutual authentication — kedua pihak (klien dan server) saling membuktikan identitas. NTLM hanya memverifikasi klien ke server, sehingga server palsu bisa "menyamar" untuk mencuri kredensial.
• Kerberos tidak pernah mengirim kredensial — yang dikirim adalah tiket terenkripsi dengan masa berlaku terbatas. NTLM mengirim hash yang bisa ditangkap dan dipakai ulang.
• Kerberos mendukung delegation — layanan bisa "mewakili" user untuk mengakses layanan lain (dengan batasan, akan dibahas nanti). NTLM sama sekali tidak mendukung skenario multi-hop.
• Kerberos memakai enkripsi modern — AES128 dan AES256, sedangkan NTLM bergantung pada struktur legacy yang lemah.

Itulah mengapa strategi keamanan yang kita bahas di episode 12 — dan detail NTLM di episode 14 — selalu bermuara pada satu arah: jauhkan NTLM, jadikan Kerberos satu-satunya jalur.

#Enkripsi Tiket: Dari RC4 ke AES

Tiket Kerberos dienkripsi dengan kunci yang diturunkan dari password. Keluarga enkripsi (encryption type) menentukan seberapa kuat proteksinya. Sepanjang evolusi Windows, jenis enkripsi yang didukung berevolusi:

Di lingkungan produksi, target kalian adalah semua ticket memakai AES. Akun di Protected Users (episode 12) otomatis ditolak jika mencoba RC4/DES — inilah salah satu alasan kelompok itu begitu efektif. Cara cepat memeriksa enkripsi yang dipakai user setelah login adalah dengan klist:

klist
klist tgt

Untuk memeriksa SPN sebuah akun service, gunakan setspn -Q:

setspn -Q http/srv-web01.corp.local

#Kegagalan Kerberos yang Paling Umum

Kerberos sangat sensitif terhadap beberapa hal. Kenali gejalanya agar tidak berputar-putar saat troubleshooting:

1. Clock skew — waktu tidak sinkron. Ticket Kerberos berisi stempel waktu; jika selisih jam klien dan DC lebih dari 5 menit (default), KDC menolak tiket. Ini adalah penyebab paling umum error aneh seperti "Kerberos: KRB_AP_ERR_SKEW" atau logon failure yang membingungkan. Solusinya: pastikan seluruh mesin domain menyinkronkan waktu ke DC, dan DC ke sumber waktu eksternal.

2. SPN tidak ditemukan atau duplikat. Ketika klien mencari cifs/SRV-FILE01 dan SPN itu tidak ada — atau malah ada dua — autentikasi gagal atau tertuju ke layanan yang salah. SPN duplikat membuat KDC bingung menentukan kunci mana yang dipakai. Pemeriksaan rutin dengan setspn -Q dan penelusuran event log adalah kebiasaan yang baik.

3. Tiket kedaluwarsa. TGT default berlaku 10 jam, service ticket 1 jam. Jika sesi dibiarkan sangat lama atau waktu sistem berubah drastis, tiket dianggap basi. klist purge menghapus semua tiket dan memaksa klien mengambil tiket baru — langkah penyelamat yang wajib kalian ingat.

4. Kredensial salah pada akun service. Jika password akun service berubah (misalnya di-reset), tiket lama langsung invalid. Inilah alasan rekomendasi memakai Group Managed Service Accounts (gMSA) yang password-nya dikelola otomatis oleh AD — tidak ada lagi "server reboot setelah reset password".

Event log adalah saksi terbaik: di log System dan Security, pesan dengan kode seperti 4771 (Kerberos pre-authentication failed) atau event di bawah sumber Kerberos memberi petunjuk langsung. Untuk penyelidikan jaringan yang sangat dalam, Wireshark dengan filter kerberos memperlihatkan seluruh pertukaran tiket secara mentah.

#Penutup

Pada episode ini kita telah membedah Kerberos — protokol autentikasi default AD: peran KDC dan akun krbtgt sebagai jantung penerbitan tiket, alur AS-REQ/AS-REP untuk mendapatkan TGT, TGS-REQ/TGS-REP untuk service ticket, serta AP-REQ/AP-REP saat tiket dipresentasikan ke layanan. Kita juga membandingkan Kerberos dengan NTLM, mempelajari enkripsi AES128/AES256 yang menjadi standar modern, dan mengenali kegagalan paling umum beserta cara menanganinya.

Inti dari episode ini: Kerberos adalah protokol berbasis tiket yang tidak pernah mengirim kredensial — kekuatan inilah yang membuatnya menjadi fondasi keamanan AD, sekaligus alasan mengapa akun seperti Protected Users dan enkripsi AES begitu krusial.

Di episode 14 selanjutnya, kita membalik koin dan mempelajari sisi lama yang harus ditinggalkan: NTLM — mengapa protokol warisan ini masih ada, bagaimana ia bekerja, mengapa ia berbahaya, dan bagaimana menonaktifkannya dengan aman. Pastikan tetap semangat!