Belajar Kerberos - Service Principals & Keytabs

#Pendahuluan

Di episode 6 kalian mengautentikasi manusia — user dengan password yang diubah menjadi TGT. Namun di dunia enterprise, yang paling sering berkomunikasi dengan KDC bukan manusia, melainkan service: SSH, web server, NFS, database. Service tidak bisa mengetik password saat diminta. Episode 7 ini membahas bagaimana service mendapatkan identitas Kerberos — lewat service principal — dan bagaimana identitas itu disimpan secara aman di keytab sehingga service bisa mengautentikasi diri tanpa password.

Konsep kunci yang harus kalian pegang: service principal adalah pasangan kunci jangka panjang (long-term key) antara service dan KDC. Keytab hanyalah wadah file untuk pasangan kunci itu. Selama KDC dan keytab menyimpan kunci yang sama, service bisa masuk "tanpa berkata-kata".

#Pola Penamaan Service Principal

Setiap service principal berbentuk:

Format service principal

service/hostname@REALM

Bagian service adalah nama layanan, hostname adalah FQDN mesin tempat service berjalan, dan REALM adalah realm Kerberos. Beberapa komponen layanan yang paling umum:

Komponen	Dipakai untuk
`host/`	Autentikasi berbasis host: SSH, login, dan tool system
`HTTP/`	Web server dengan SPNEGO atau Negotiate (episode 15)
`nfs/`	Mount NFS ter-kerberos (episode 14)
`cifs/`	Akses share SMB atau CIFS
`postgres/`, `mysql/`	Database dengan GSSAPI (episode 16)

Satu aturan penting: service principal harus unik. Kalian tidak boleh memiliki dua principal HTTP/web1.example.com@EXAMPLE.COM di dua mesin berbeda — KDC akan menolak atau salah satu akan selalu gagal. hostname pada principal harus persis FQDN yang dipakai klien untuk mengakses service, karena service ticket di-enkripsi untuk hostname itu. Jika klien mengakses web1.example.com tetapi principal hanya dibuat untuk web1, autentikasi akan gagal dengan error server not found in Kerberos database.

Warning

Gunakan FQDN lengkap, bukan hostname pendek — host/web1.example.com, bukan host/web1 — dan jangan pernah memakai nama alias yang berbeda dari yang dipakai klien. Kesalahan sekecil ini adalah penyebab nomor satu kegagalan service authentication di produksi.

#Membuat Service Principal dengan kadmin

Berbeda dari principal user, service principal tidak butuh password yang bisa diketika manusia — ia cukup diberi kunci acak. Karena itu perintahnya memakai opsi -randkey:

Menambah SPN di kadmin

$ sudo kadmin.local
kadmin.local:  addprinc -randkey host/web1.example.com
WARNING: no policy specified for "host/web1.example.com@EXAMPLE.COM";
assigning "default" policy.
Principal "host/web1.example.com@EXAMPLE.COM" created.
kadmin.local:  addprinc -randkey HTTP/web1.example.com
Principal "HTTP/web1.example.com@EXAMPLE.COM" created.

-randkey meminta KDC membangkitkan kunci acak, bukan meminta password. Setiap kunci di database diberi nomor versi — KVNO (Key Version Number). Saat kunci di-reset atau dirotasi, KVNO naik. KVNO inilah yang dipakai service untuk memastikan keytab-nya masih sinkron dengan KDC; jika keytab berisi KVNO lama, muncul error Key version number mismatch.

#Keytab: Rumah Kunci Tanpa Password

Keytab (key table) adalah file yang menyimpan kunci service principal. Karena file ini berisi material kriptografik yang setara password, ia harus diperlakukan seketat file credential:

Lokasi default: /etc/krb5.keytab untuk service berbasis host.
Pemilik root, permission 600 — chmod 600 /etc/krb5.keytab.
Hanya service yang membutuhkannya yang boleh membaca.

Kunci ditulis ke keytab dari dalam kadmin dengan ktadd:

Menulis kunci ke keytab

kadmin.local:  ktadd -k /etc/krb5.keytab HTTP/web1.example.com
Entry for principal "HTTP/web1.example.com" with kvno 3, encryption type
aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.

Setelah ini, web server bisa membaca kunci HTTP/web1.example.com dari /etc/krb5.keytab setiap kali klien meminta autentikasi — tanpa pernah menyimpan atau mengetik password. Inilah inti "passwordless authentication" untuk service.

#Memeriksa Isi Keytab: klist -kte

Untuk memverifikasi isi keytab, gunakan klist dengan opsi -k (keytab), -t (tampilkan waktu modifikasi), dan -e (enctype):

Melihat entri keytab

sudo klist -kte /etc/krb5.keytab

Output klist -kte

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   3 08/03/2026 09:00  host/web1.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   3 08/03/2026 09:00  HTTP/web1.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)

Perhatikan kolom KVNO dan enctype di setiap baris. Saat troubleshooting, bandingkan KVNO di keytab dengan KVNO di database KDC (getprinc) — kalau tidak sama, kunci service-nya sudah dirotasi dan keytab perlu diperbarui.

#Mengelola Keytab dengan ktutil

ktutil adalah utilitas interaktif untuk manipulasi keytab: melihat, menghapus, atau menggabungkan entri.

Sesi ktutil

$ sudo ktutil
ktutil:  read_kt /etc/krb5.keytab
ktutil:  list
ktutil:  delete_entry 1
ktutil:  write_kt /etc/krb5.keytab
ktutil:  quit

Alur umumnya: read_kt memuat isi keytab ke memori, list menampilkan entri dengan indeks 0, 1, 2, dan seterusnya, delete_entry menghapus entri berdasarkan indeks, lalu write_kt menulis kembali hasilnya. Ini berguna untuk membersihkan principal lama dari keytab — misalnya saat service di-rename atau mesin di-decommission. Di beberapa sistem, perintah ktab menyediakan fungsi serupa yang lebih sederhana: ktab -l untuk list dan ktab -d untuk delete.

Untuk keytab terpisah (misalnya satu file per service), buat dengan -k menunjuk ke path lain, lalu distribusikan secara aman ke mesin yang membutuhkan. Gabungkan beberapa file keytab bila perlu lewat ktutil — KDC akan mencocokkan principal mana pun yang ada di dalamnya.

#Menguji Autentikasi Service

Setelah keytab tersedia, uji apakah service bisa mendapatkan ticket tanpa password:

Tes autentikasi service

kinit -kt /etc/krb5.keytab HTTP/web1.example.com
klist

kinit -kt membaca kunci dari keytab tanpa menampilkan prompt password, lalu memperoleh TGT untuk principal service tersebut. Jika berhasil, klist menampilkan ticket HTTP/web1.example.com@EXAMPLE.COM — bukti bahwa KDC mengenali kunci di keytab.

Important

Keytab adalah file rahasia: siapa pun yang membacanya bisa bertindak sebagai service tersebut. Enkripsi disk, permission 600, dan rotasi kunci berkala adalah praktik wajib. Jangan pernah menyalin keytab ke direktori publik atau mengunggahnya ke repositori.

#Penutup

Pada episode 7 ini, kalian belajar bagaimana service memperoleh identitas tanpa password: service principal bernama service/hostname@REALM dibuat dengan addprinc -randkey, kuncinya disimpan ke keytab lewat ktadd, dan service mengautentikasi diri dengan kinit -kt.

Inti yang harus dibawa pulang:

Pola penamaan service/hostname@REALM harus unik dan FQDN-nya harus sama persis dengan yang dipakai klien.
Keytab adalah file rahasia — perlakukan seperti password, permission 600 milik root.
KVNO adalah penanda versi kunci; mismatch KVNO berarti keytab ketinggalan zaman.
klist -kte untuk inspeksi, ktutil untuk mengelola entri, kinit -kt untuk menguji.

Di episode 8 berikutnya, kita naik ke level admin penuh: manajemen principal dan administrasi — mengelola principal secara masal, kebijakan password, ACL admin di kadm5.acl, hingga praktik audit aktivitas kadmin. Siapkan keytab dari episode ini, karena kita akan membangun alat kelola identitas di atasnya.