Belajar Kerberos - Active Directory Kerberos

#Pendahuluan

Di episode 17 kalian melihat bagaimana LDAP menjadi tempat tinggal identitas — dan di akhir episode itu kita menyebut bahwa Active Directory bisa bertindak sebagai KDC. Episode ini membuka sisi itu sepenuhnya: Active Directory memakai Kerberos sebagai protokol autentikasi default, dan memahami cara AD "membungkus" Kerberos adalah kunci untuk menguasai identitas di dunia Windows.

Kenapa ini penting? Karena hampir semua peristiwa di AD — login user, akses file share, autentikasi aplikasi lewat SPNEGO, hingga delegation — berjalan di atas Kerberos. Jika kalian mengelola server Linux, kalian juga pasti akan bertemu AD di episode 19. Dan semua istilah yang sering viral di dunia keamanan — golden ticket, silver ticket, Kerberoasting — adalah eksploitasi dari cara AD mengimplementasikan protokol yang sudah kalian pelajari sejak episode 2.

#Pembahasan Utama

#Domain AD Adalah Realm Kerberos

Konsep pertama yang harus diinternalisasi: sebuah domain AD adalah sebuah realm Kerberos. Ketika kalian membuat domain EXAMPLE.COM, AD secara otomatis menciptakan realm Kerberos dengan nama yang sama. Nama NETBIOS seperti EXAMPLE tetap dipakai untuk format login EXAMPLE\User, tetapi identitas Kerberos penuh selalu berbentuk user@EXAMPLE.COM.

Di atas realm itu berdiri komponen-komponen yang sudah kalian kenal dari episode 2:

• Setiap Domain Controller (DC) adalah KDC. Layanan KDC berjalan sebagai bagian dari proses lsass.exe di semua DC dalam domain. Tidak ada konsep KDC "master" yang terpisah seperti MIT Kerberos — setiap DC bisa melayani AS_REQ dan TGS_REQ secara mandiri.
• Akun krbtgt adalah kunci TGT realm. Di database AD ada sebuah akun user bernama krbtgt yang password-nya tidak pernah dipakai untuk login. Hash password akun inilah yang menjadi kunci enkripsi semua TGT di realm. Ini analog dengan master key pada MIT KDC yang kalian buat di episode 5, tetapi disimpan sebagai objek user di AD.
• Penemuan DC via DNS. Klien menemukan DC terdekat dengan query SRV record di zona khusus _msdcs. Ini prinsip yang sama dengan SRV record yang kalian buat di episode 4, hanya dengan namespace yang berbeda:

dig +short _kerberos._tcp.dc._msdcs.example.com SRV

Setiap jawaban SRV berisi nama DC dan prioritas — klien memilih yang terdekat, dan otomatis beralih ke DC lain saat satu DC tidak merespons. Inilah mengapa AD tahan terhadap kegagalan satu DC tanpa perlu HA yang rumit.

#Alur Autentikasi: Tiga Langkah yang Sama, dengan PAC

Secara protokol, alur autentikasi AD identik dengan yang kalian pelajari di episode 3:

1. AS_REQ / AS_REP — client mengirim username; DC (berperan sebagai AS) membalas dengan TGT yang dienkripsi kunci krbtgt plus session key yang dienkripsi kunci user.
2. TGS_REQ / TGS_REP — client menukar TGT untuk service ticket menuju SPN (misalnya cifs/fileserver01.example.com).
3. AP_REQ / AP_REP — client mempresentasikan service ticket ke server target; server memverifikasi dan mengizinkan akses.

Bedanya dengan MIT Kerberos ada di satu lapisan ekstra: setiap ticket yang diterbitkan AD membawa PAC (Privilege Attribute Certificate).

#PAC: Keanggotaan Grup yang Ikut Dalam Ticket

PAC adalah struktur data Microsoft yang didokumentasikan di MS-PAC dan disisipkan sebagai field authorization-data di dalam ticket. Isinya antara lain:

• SID user dan SID domain tempat user berada.
• Daftar SID keanggotaan grup user — inilah mengapa keanggotaan grup AD "ikut terbawa" di setiap ticket.
• Informasi logon: waktu login, domain controller, dan atribut lain yang dipakai sistem otorisasi.

Mengapa AD repot membawa ini di dalam ticket? Jawabannya adalah efisiensi. Ketika user mengakses file server, server tidak perlu membuka koneksi ke DC untuk bertanya "user ini masuk grup apa saja?" — jawabannya sudah tersedia dan tertanda tangan di dalam ticket. Server cukup memverifikasi dua tanda tangan PAC: satu ditandatangani dengan kunci service itu sendiri, dan satu lagi dengan kunci DC. Karena PAC ditandatangani KDC, server bisa percaya bahwa keanggotaan grup di dalamnya sah tanpa bertanya ke mana-mana. Inilah yang membuat file share AD terasa instan bahkan di jaringan yang padat.

#SPN dan Service Ticket di AD

Service ticket di AD tidak ditujukan ke "hostname" abstrak, melainkan ke Service Principal Name (SPN) — atribut servicePrincipalName yang menempel pada objek computer atau user. Formatnya persis dengan yang kalian kenal di episode 7: service/hostname, misalnya cifs/fileserver01.example.com atau HTTP/webapp01.example.com.

Beberapa hal penting yang perlu kalian tahu:

• Setiap objek computer otomatis mendapat SPN host/<FQDN> dan restrictedKrbHost/<FQDN> — setara dengan host principal yang kalian buat untuk server Linux di episode 7.
• SPN layanan tambahan (misal cifs atau HTTP) diregistrasikan secara eksplisit, biasanya otomatis oleh layanan yang berjalan dengan domain account, atau manual lewat setspn.
• Saat client meminta ticket ke cifs/fileserver01, TGS mencari SPN itu di database AD, mengambil kunci service-nya dari password akun terkait, lalu menerbitkan service ticket. Jika SPN tidak ditemukan atau duplikat, proses gagal — topik yang akan kita bedah jauh lebih dalam di episode 20.

#Port dan Enkripsi yang Dipakai AD

Kerberos di AD berjalan di port yang sama dengan standar:

Mengenai jenis enkripsi, AD punya cerita panjang. Untuk kompatibilitas, Windows lama masih mengandalkan RC4-HMAC — warisan era NT 4.0 yang bertahan karena satu mesin tua saja bisa memaksa seluruh domain menurunkan standar enkripsi. Implementasi modern sudah mendukung AES128-CTS-HMAC-SHA1-96 dan AES256-CTS-HMAC-SHA1-96, dan Windows Server 2019 ke atas menambahkan enctypes berbasis SHA-2 seperti AES256-CTS-HMAC-SHA384-192. Enkripsi yang diizinkan diatur lewat GPO di Security Options: Network security: Configure encryption types allowed for Kerberos — penonaktifan RC4 dan DES akan kita bahas tuntas di episode 21.

#Kebijakan Kerberos di GPO

Masa hidup ticket default AD diatur lewat Kerberos policy pada Account Policies:

Angka-angka ini bukan hiasan — mereka menentukan jendela serangan. TGT selama 10 jam berarti credential yang dicuri tetap berguna seharian, dan toleransi jam 5 menit adalah batas waktu yang sama dengan default MIT Kerberos yang kalian konfigurasi di episode 6.

#Golden Ticket: Ketika Kunci Realm Bocor

Ini bagian yang paling sering membuat administrator AD tidak bisa tidur. Karena semua TGT dienkripsi dengan kunci krbtgt, siapa pun yang berhasil mengekstrak hash password akun krbtgt bisa memalsukan TGT untuk user mana pun — termasuk user yang tidak pernah ada di domain. Inilah golden ticket: tiket "emas" yang membuka seluruh realm tanpa perlu password asli.

Dampaknya jauh lebih parah daripada mencuri password satu user:

• Golden ticket valid untuk masa hidup yang ditentukan pembuatnya — bisa bertahun-tahun jika lifetime sengaja diatur besar.
• Mengganti password user korban tidak menghentikan serangan, karena kunci yang dipalsukan adalah milik realm, bukan milik user.
• Serangan hanya butuh sekali akses admin ke DC, atau akses ke backup ntds.dit bersama hive SYSTEM.

Mitigasi utama yang harus kalian hafal: jika krbtgt diduga bocor, reset password akun krbtgt dua kali berurutan (dengan jeda antar reset agar replikasi selesai) supaya hash lama mati permanen. Deteksi dan pemantauan serangan ini akan kita bahas di episode 22, dan pengerasan lengkapnya di episode 21.

#Praktik Singkat: Memeriksa Ticket dan SPN di Windows

Untuk melihat tiket Kerberos yang sedang aktif di sesi Windows, jalankan klist:

Lihat tiket Kerberos aktif di Windows

klist

Dan untuk memeriksa SPN yang terdaftar pada sebuah akun atau komputer, gunakan setspn -L fileserver01:

Cek SPN milik sebuah komputer

setspn -L fileserver01

Jika ingin memastikan DC mana yang sedang dipakai, Get-ADDomainController -Discover -ServiceName Kerberos memberi tahu DC terdekat — berguna saat mendiagnosis kenapa autentikasi lambat atau gagal.

#Penutup

Di episode 18 ini kalian telah memetakan Active Directory sebagai implementasi Kerberos paling luas di dunia. Kita membahas domain sebagai realm, DC sebagai KDC, akun krbtgt sebagai kunci TGT, alur AS/TGS/AP dengan tambahan PAC yang membawa keanggotaan grup, SPN sebagai identitas service, port dan enkripsi (RC4 hingga AES 256), kebijakan lifetime via GPO, serta dampak kompromi krbtgt berupa golden ticket.

Poin kunci yang perlu kalian bawa:

• AD dan Kerberos tidak terpisahkan: domain = realm, DC = KDC, krbtgt = kunci master realm.
• PAC (MS-PAC) membuat keanggotaan grup ikut dalam ticket, ditandatangani KDC agar service percaya.
• SPN adalah target service ticket; masalah SPN = masalah autentikasi (dibahas di episode 20).
• KDC di port 88/tcp dan 88/udp; enkripsi modern AES 256, warisan RC4 sebaiknya dimatikan.
• Kompromi krbtgt = golden ticket; reset dua kali adalah obat wajib saat diduga bocor.

Di episode 19 berikutnya kita akan menyambungkan dunia ini ke dunia Linux: Linux Client dengan Active Directory — cara menjadikan server Linux warga penuh domain AD lewat realmd dan SSSD, konfigurasi autentikasi Kerberos dari AD, hingga alur login dan troubleshooting ketika join gagal. Sampai jumpa!