Belajar Kerberos - Kerberos Client Configuration

#Pendahuluan

Pada episode 5 kemarin kalian berhasil membangun KDC MIT Kerberos: database principal dibuat, master key di-stash, dan service krb5kdc berjalan. Sekarang waktunya membalik posisi — kalian pindah ke sisi klien. Episode ini membahas konfigurasi klien secara menyeluruh: instalasi paket, anatomi /etc/krb5.conf sebagai "peta jalan" menuju realm, autentikasi pertama dengan kinit, membaca cache dengan klist, mengatur credential cache, hingga integrasi login sistem lewat pam_krb5 dan sssd.

Kenapa episode ini penting? Sebagian besar kegagalan Kerberos di lapangan — Cannot contact any KDC, No credentials cache found, Clock skew too great — berakar pada konfigurasi klien yang salah, bukan di sisi server. Pahami satu hal sejak awal: /etc/krb5.conf tidak menyimpan rahasia apa pun. Ia hanya berisi alamat dan preferensi. Semua rahasia tetap berada di KDC dan di cache ticket di sisi kalian.

#Instalasi Paket Klien

Nama paketnya berbeda antar distro. Di keluarga Red Hat paketnya krb5-workstation, di Debian dan Ubuntu krb5-user.

# RHEL / Rocky / AlmaLinux
sudo dnf install krb5-workstation
 
# Debian / Ubuntu
sudo apt install krb5-user

Paket ini membawa tiga tool inti yang menjadi "kartu akses" harian kalian:

• kinit — meminta ticket ke KDC (login).
• klist — melihat ticket yang tersimpan di cache.
• kdestroy — menghapus ticket dari cache (logout).

#Anatomi /etc/krb5.conf

File konfigurasi /etc/krb5.conf dibaca oleh semua tool Kerberos, baik klien maupun KDC. Bagian yang paling sering diutak-atik klien ada empat:

Contoh minimal untuk satu realm:

/etc/krb5.conf (klien)

[libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_kdc = true
    dns_lookup_realm = true
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    rdns = false
 
[realms]
    EXAMPLE.COM = {
        kdc = kdc1.example.com
        admin_server = kdc1.example.com
    }
 
[domain_realm]
    .example.com = EXAMPLE.COM
    example.com = EXAMPLE.COM
 
[logging]
    default = FILE:/var/log/krb5libs.log

Poin yang perlu kalian cermati:

• default_realm adalah realm yang dipakai saat kalian menjalankan kinit budi tanpa menyebutkan realm — ini "alamat rumah" default.
• dns_lookup_kdc meminta klien menemukan KDC lewat SRV record _kerberos._udp yang kita bangun di episode 4. Jika DNS salah, klien tidak akan pernah menemukan KDC.
• kdc dan admin_server adalah jaring pengaman eksplisit; admin_server dipakai oleh kadmin dan perintah perubahan password.
• [domain_realm] memetakan domain DNS (misalnya web1.example.com) ke realm — berguna saat realm tidak mengikuti pola DNS.

#Membuat Principal User

Sebelum bisa kinit, principal user harus ada di database KDC. Dari mesin klien yang punya akses admin, kalian bisa menambahkannya lewat kadmin remote. Dari KDC itu sendiri, pakai kadmin.local yang tidak butuh autentikasi:

$ sudo kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local:  addprinc budi
Enter password for principal "budi@EXAMPLE.COM":
Re-enter password for principal "budi@EXAMPLE.COM":
Principal "budi@EXAMPLE.COM" created.
kadmin.local:  quit

Perhatikan bahwa kadmin.local berbicara langsung ke database KDC, jadi ia hanya boleh dijalankan di mesin KDC oleh root. Untuk pengelolaan dari jauh, kalian harus kinit admin/admin terlebih dahulu lalu menjalankan kadmin. Rincian kewenangan ini akan dibahas lebih dalam di episode 8.

#Autentikasi Pertama: kinit, klist, kdestroy

Setelah principal dibuat, autentikasi pertama cuma tiga perintah:

kinit budi
klist
kdestroy

kinit budi meminta password, lalu mengirimnya sebagai preauthentication terenkripsi ke KDC (bukan password polos). klist menampilkan TGT yang baru diperoleh beserta waktu kedaluwarsanya. kdestroy membersihkan cache — wajib dilakukan saat kalian meninggalkan mesin bersama.

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: budi@EXAMPLE.COM
 
Valid starting       Expires              Service principal
08/03/2026 09:00:00  08/03/2026 10:00:00  krbtgt/EXAMPLE.COM@EXAMPLE.COM

#Credential Cache: Tempat Ticket Disimpan

Ticket tidak disimpan di KDC — ia dibawa pulang klien dan ditaruh di credential cache. Pilihan lokasinya bisa memengaruhi keamanan dan kenyamanan:

Tipe FILE adalah default klasik: /tmp/krb5cc_1000 berarti cache milik user dengan UID 1000. Lokasi cache dikontrol variabel lingkungan KRB5CCNAME. Kalian bisa mengarahkannya ke file atau keyring sendiri:

export KRB5CCNAME=FILE:/tmp/mycache
kinit budi
klist -c /tmp/mycache

Pada desktop modern, KEYRING:persistent:UID adalah pilihan favorit karena kredensial tersimpan di kernel keyring — lebih sulit dibaca proses lain dan otomatis dibersihkan saat sesi berakhir.

#Login Sistem: pam_krb5 dan SSSD

Untuk Single Sign-On penuh — satu password, login ke sistem sekaligus mendapat ticket — kalian perlu menautkan Kerberos ke PAM. Dua pendekatan umum:

• pam_krb5: modul PAM yang mengautentikasi password terhadap KDC dan langsung menyimpan ticket ke cache saat login.
• SSSD: daemon yang menyatukan autentikasi, identitas, dan cache offline; mendukung provider krb5 untuk autentikasi dan ldap untuk data user.

Contoh domain SSSD yang memakai Kerberos sebagai provider autentikasi:

/etc/sssd/sssd.conf (contoh)

[sssd]
    services = nss, pam
    domains = example.com
 
[domain/example.com]
    id_provider = ldap
    auth_provider = krb5
    chpass_provider = krb5
    krb5_realm = EXAMPLE.COM
    krb5_server = kdc1.example.com

Dengan krb5_realm dan krb5_server yang benar, user bisa login sistem dengan password Kerberos mereka, dan ticket-nya otomatis tersedia untuk aplikasi. Ini fondasi dari SSO di Linux.

#Forwardable dan Renewable

Di [libdefaults] tadi ada dua flag yang akan sering kalian temui: forwardable dan renewable.

• forwardable{:ini} = true mengizinkan ticket di-forward ke host lain — dasar untuk SSH delegation (dibahas di episode 13).
• renewable memungkinkan ticket diperpanjang tanpa memasukkan password lagi — krusial untuk job batch yang berjalan berhari-hari (detail di episode 9).

#Troubleshooting Sisi Klien

Ketika autentikasi gagal, kenali polanya dari pesan error:

Untuk melihat apa yang sebenarnya dikirim klien, aktifkan trace:

KRB5_TRACE=/dev/stdout kinit budi

Trace akan menunjukkan setiap langkah — mencari realm, menghubungi KDC, memilih enctype, menerima ticket — sehingga kalian bisa langsung melihat di langkah mana autentikasi gagal.

#Penutup

Pada episode 6 ini, kalian sudah menyiapkan fondasi sisi klien: paket krb5-workstation, /etc/krb5.conf sebagai peta realm, siklus kinit-klist-kdestroy, pengelolaan credential cache dengan KRB5CCNAME, integrasi login lewat pam_krb5 dan SSSD, serta keterampilan membaca pesan error.

Inti yang harus dibawa pulang:

• /etc/krb5.conf tidak menyimpan rahasia — ia hanya alamat dan preferensi.
• kinit, klist, kdestroy adalah siklus hidup ticket di sisi klien.
• Cache bisa berupa FILE, KEYRING, DIR, atau KCM — pilih sesuai kebutuhan keamanan.
• Sebagian besar error klien adalah masalah DNS, waktu, atau realm yang salah.

Di episode 7 berikutnya, kita membalik fokus ke layanan: bagaimana memberi identitas tanpa password kepada service (SSH, web, NFS) lewat service principals dan keytabs. Pastikan kalian nyaman dengan kinit dulu, karena semua yang akan kita lakukan di episode 7 berangkat dari konsep identitas Kerberos ini.