Belajar Kerberos - SPN Management dan Delegation

#Pendahuluan

Di episode 19 kalian menjadikan server Linux warga domain AD: objek computer terdaftar, keytab host dihasilkan, dan SSSD menjembatani autentikasi Kerberos dengan PAM dan NSS. Mesin kini bisa membuktikan identitasnya ke KDC. Tapi bagaimana dengan layanan? Saat sebuah aplikasi menawarkan HTTP atau SSH, KDC perlu tahu service mana yang sedang diminta — di situlah Service Principal Name (SPN) berperan.

Episode 20 membedah SPN sebagai identitas layanan di realm, cara mendaftarkannya dari sisi Windows dan Linux, lalu masuk ke dunia delegation Kerberos: mekanisme yang mengizinkan sebuah service meminta tiket atas nama user. Delegation adalah fitur yang sangat kuat dan sekaligus sangat berbahaya bila dikonfigurasi sembarangan.

#Apa itu Service Principal Name

SPN adalah pengenal unik sebuah layanan di dalam realm. Formatnya selalu tiga bagian: nama layanan, host, dan realm.

Saat klien ingin mengakses layanan HTTP/web01.example.com, klien meminta service ticket untuk SPN itu ke KDC. KDC akan mencari akun mana yang memiliki SPN tersebut, lalu menandatangani tiket dengan kunci akun itu. Ini persis alur yang kalian lihat di episode 3: tanpa SPN yang benar, KDC menjawab KDC_ERR_S_PRINCIPAL_UNKNOWN — "server not found in Kerberos database".

#Mendaftarkan SPN dengan setspn

Di dunia Windows, SPN dikelola dengan setspn. SPN dilekatkan ke sebuah akun user atau computer yang menjadi "identitas" layanan:

setspn -S HTTP/web01.example.com svc-web
setspn -L svc-web
setspn -Q HTTP/web01.example.com

• setspn -S melakukan penambahan sekaligus pengecekan duplikat — perintah ini akan menolak jika SPN sudah dimiliki akun lain.
• setspn -L menampilkan daftar SPN yang dimiliki sebuah akun.
• setspn -Q menanyakan siapa pemilik SPN tertentu; sangat berguna untuk mendeteksi duplikasi.

#Duplicate SPN

SPN di dalam realm wajib unik. Jika dua akun memiliki SPN yang sama, KDC tidak tahu kunci mana yang dipakai untuk menandatangani service ticket. Dampaknya: autentikasi layanan menjadi tidak stabil — kadang berhasil, kadang gagal dengan KRB_AP_ERR_MODIFIED. Perhatikan hal-hal berikut:

• Selalu gunakan setspn -S (bukan setspn -A dari era lama) agar duplikat langsung terdeteksi saat pendaftaran.
• Audit berkala dengan setspn -Q */* dan filter hasil yang muncul lebih dari sekali.
• Hapus SPN lama pada akun yang tidak terpakai; SPN yang tertinggal menjadi target Kerberoasting (akan dibahas di episode 21).

#SPN untuk Layanan Linux

Aplikasi Linux juga butuh SPN, dan ada dua jalur utama: menggunakan tool msktutil untuk mengelola machine account beserta SPN-nya dari sisi Linux, atau menghasilkan keytab dari AD dengan ktpass di sisi Windows.

#msktutil: Mengelola Machine Account dan SPN dari Linux

msktutil adalah utilitas yang memungkinkan Linux membuat dan memperbarui machine account di AD, menambah SPN, serta menulis keytab:

msktutil create --computer-name web01 \
  --service HTTP/web01.example.com \
  --upn svc-web@EXAMPLE.COM \
  --server dc01.example.com \
  --keytab /etc/krb5.keytab

• --service menambahkan SPN ke machine account.
• --upn menetapkan User Principal Name akun tersebut.
• --keytab menentukan lokasi file keytab yang dihasilkan.

Setelah keytab tersedia, verifikasi isinya dan uji autentikasi tanpa password:

klist -kt /etc/krb5.keytab
kinit -k -t /etc/krb5.keytab HTTP/web01.example.com

#ktpass: Menghasilkan Keytab dari AD

Pendekatan klasik dari sisi Windows adalah ktpass yang dijalankan di domain controller atau workstation dengan tools RSAT:

ktpass -princ HTTP/web01.example.com@EXAMPLE.COM \
  -mapuser svc-web \
  -crypto AES256-SHA1 \
  -ptype KRB5_NT_PRINCIPAL \
  -out /tmp/web01.keytab

• /princ menentukan SPN yang menjadi identitas utama keytab.
• /mapuser memetakan SPN tersebut ke akun AD svc-web.
• /crypto AES256-SHA1 memastikan hanya enkripsi AES yang dipakai — hindari RC4 (detail di episode 21).
• File keytab yang dihasilkan lalu dipindahkan ke server Linux dengan metode aman, dan diuji dengan klist -kt web01.keytab serta kinit -k -t web01.keytab HTTP/web01.example.com.

Baik lewat msktutil maupun ktpass, hasil akhirnya sama: keytab berisi kunci akun yang SPN-nya cocok, siap dipakai aplikasi untuk menerima tiket.

#Jenis-jenis Delegation Kerberos

Delegation mengizinkan sebuah service meminta tiket atas nama user ke layanan lain. Ada tiga model dengan tingkat risiko berbeda:

#Unconstrained Delegation

Model tertua: front-end menerima TGT user sebagai bagian dari alur dan menyimpannya di memori. Dengan TGT itu, front-end bisa meminta tiket ke layanan mana pun — selama TGT valid. Karena TGT disimpan, satu machine yang disusupi akan langsung memberikan akses ke seluruh domain. Microsoft menyarankan menghindari model ini kecuali untuk kasus khusus yang sangat terisolasi.

#Constrained Delegation (Protocol Transition)

Model kedua membatasi target: front-end hanya bisa mendelegasikan ke daftar layanan tertentu yang diizinkan. Kelebihannya adalah dukungan protocol transition — user yang masuk lewat autentikasi non-Kerberos (misalnya NTLM atau sertifikat) tetap bisa dialihkan ke layanan Kerberos lain. Ini melibatkan dua mekanisme:

• S4U2Self: front-end meminta service ticket untuk dirinya sendiri atas nama user yang belum memiliki tiket Kerberos — seperti "atas nama user ini, beri saya tiket untuk saya". Ini menjadi bukti bahwa user sudah diautentikasi lewat jalur lain.
• S4U2Proxy: dengan tiket hasil S4U2Self, front-end meminta tiket ke layanan backend atas nama user.

#Resource-Based Constrained Delegation

Model paling modern: konfigurasi dilakukan di akun resource (backend), bukan di front-end. Resource menyatakan daftar akun yang diizinkan mendelegasikan padanya. Karena disetel pada resource, ini cocok untuk skenario di mana tim pemilik backend ingin mengontrol siapa yang boleh menyambung ke layanannya. Resource-based delegation juga memakai S4U2Self dan S4U2Proxy, tapi arah konfigurasinya terbalik.

#Mengonfigurasi Delegation di AD

Untuk mengaktifkan constrained delegation di AD:

1. Buka properties akun computer front-end di Active Directory Users and Computers.
2. Buka tab Delegation, lalu pilih "Trust this computer for delegation to specified services only".
3. Centang "Use Kerberos only" (tanpa protocol transition) atau "Use any authentication protocol" (dengan protocol transition).
4. Klik Add, pilih service accounts target, lalu pilih SPN yang boleh dituju, misalnya cifs/file01.example.com.
5. Uji akses layanan dari sisi klien dan amati tiket yang di-forward.

Resource-based delegation dikonfigurasi lewat PowerShell pada akun resource:

Set-ADComputer file01 -PrincipalsAllowedToDelegateToAccount web01$

Perintah di atas menyatakan: akun computer file01 mengizinkan web01 mendelegasikan padanya. Arah kontrol kini di tangan pemilik resource.

#Testing Delegation

Untuk memastikan delegation bekerja, jalankan klist di sesi front-end dan periksa keberadaan service ticket untuk backend. Saat alur S4U2Proxy berjalan, front-end akan memiliki tiket cifs/file01 yang diperoleh atas nama user. Jika tiket tidak muncul padahal semua konfigurasi sudah benar, periksa kembali apakah SPN backend sudah terdaftar pada akun resource, dan apakah opsi "use any authentication protocol" benar-benar dibutuhkan.

#Pertimbangan Keamanan Delegation

Delegation adalah tambang emas bagi penyerang yang sudah punya akses ke satu service:

• Golden Ticket: dengan kunci krbtgt yang dicuri, penyerang memalsukan TGT untuk akun mana pun, termasuk akun istimewa. Delegation memperluas dampaknya karena tiket palsu itu bisa dipakai untuk meniru user.
• Silver Ticket: penyerang memalsukan service ticket langsung untuk satu layanan dengan kunci akun layanan yang dicuri — tanpa perlu menyentuh KDC. Kunci yang bocor dari satu server cukup untuk membuat tiket valid bagi layanan itu.
• Akun dengan unconstrained delegation yang disusupi memberi penyerang TGT semua user yang melewatinya. Pantau machine dengan delegation aktif sebagai aset paling sensitif.
• Kunci layanan yang dipakai delegation juga merupakan target Kerberoasting; pastikan mengikuti hardening dari episode 21.

Mitigasi penting yang bisa langsung kalian terapkan:

• Protected Users group: anggota grup ini tidak pernah menerima delegation, tidak bisa memakai RC4, dan kredensialnya tidak di-cache. Masukkan admin dan akun sensitif ke sini.
• Batasi delegation: hanya gunakan constrained atau resource-based; hindari unconstrained. Prinsipnya: layanan hanya boleh mendelegasikan ke layanan yang benar-benar dibutuhkan.
• Pisahkan peran: jangan menggabungkan unconstrained delegation dengan layanan publik.
• Monitoring: catat setiap perubahan delegation dan setiap service ticket yang diminta dalam pola tidak biasa — ini akan menjadi topik besar di episode 22.

#Penutup

Episode 20 ini memberi kalian peta lengkap identitas layanan dan delegation: SPN sebagai pengenal unik layanan, pendaftaran via setspn di Windows serta msktutil dan ktpass di Linux, perbandingan tiga jenis delegation, hingga risiko Golden Ticket dan Silver Ticket yang membayangi konfigurasi yang ceroboh.

Inti yang harus dibawa pulang:

• SPN berformat service/host@REALM dan wajib unik; gunakan setspn -S dan audit setspn -Q */* secara rutin.
• Keytab dihasilkan dari AD lewat msktutil (dari Linux) atau ktpass (dari Windows), dan wajib menggunakan enkripsi AES.
• Unconstrained delegation berbahaya; utamakan constrained atau resource-based dengan S4U2Self dan S4U2Proxy.
• Masukkan admin ke Protected Users, batasi daftar layanan yang boleh didelegasikan, dan pantau semua perubahan delegation.

Di episode 21 kalian akan mengubah pandangan dari "fitur" ke "senjata": Kerberos Security Best Practices — hardening enkripsi, keamanan KDC, membedah serangan Kerberos seperti Kerberoasting dan Pass-the-Ticket, serta strategi deteksinya. Sampai jumpa!