Belajar Kerberos - Cross-Realm Authentication

#Pendahuluan

Di episode 0 sampai 9, kalian menjalani seluruh siklus autentikasi di dalam satu realm: satu KDC, satu set kebijakan, satu kumpulan principal, dan semua tiket bermuara pada TGT yang diterbitkan KDC yang sama. Episode 10 melebarkan cakrawala itu. Kali ini kalian menghubungkan dua realm Kerberos yang berdiri sendiri sehingga user dari satu realm bisa mengakses layanan di realm lain tanpa akun duplikat dan tanpa login dua kali. Konsep ini disebut cross-realm authentication, dan ia adalah fondasi integrasi antar organisasi, merger perusahaan, hingga forest Active Directory.

#Konsep Cross-Realm

#Banyak Realm, Satu Kepercayaan

Sebuah realm adalah batas kepercayaan (trust boundary). Semua yang ada di dalamnya — KDC, principal, kebijakan password, lifetime ticket — diatur oleh satu otoritas. Cross-realm tidak menggabungkan realm-realm itu, melainkan membangun jembatan di antara mereka lewat realm trust relationship: kesepakatan bahwa KDC realm A mengakui identitas yang telah diverifikasi KDC realm B, dan sebaliknya. Kalian tidak perlu mereplikasi akun user dari realm B ke realm A; cukup dengan trust, ticket yang diterbitkan realm B diterima sebagai bukti identitas oleh realm A.

#Hierarchical Realms

Realm sering ditata mengikuti struktur domain, mirip DNS. EXAMPLE.COM bisa memiliki anak CORP.EXAMPLE.COM, dan CORP.EXAMPLE.COM bisa memiliki anak LA.CORP.EXAMPLE.COM. Dalam tatanan hierarkis, arah trust mengikuti garis keturunan ini, sehingga kebijakan bisa dikelola rapi di setiap level. Struktur inilah yang dipakai Active Directory untuk membangun pohon domain.

#Transitive Trust

Konsep transitive trust berbunyi: jika realm A percaya realm B, dan realm B percaya realm C, maka realm A bisa mencapai realm C melewati realm B. Namun perlu dicatat: dalam MIT Kerberos, transitivitas tidak terjadi dengan sendirinya. Setiap hop tetap butuh kunci cross-realm yang sesuai, dan jalur antar realm perantara harus dinyatakan secara eksplisit di [capaths]. Tanpa itu, klien hanya tahu jalur langsung dan menyerah ketika jalur langsung tidak ada.

#Tipe Trust

Perbedaan tipe trust pada dasarnya soal arah dan topologi:

#One-way Trust

Dalam trust satu arah, user dari realm B bisa mengakses layanan di realm A, tetapi tidak sebaliknya. Ini pola ideal untuk vendor atau partner: mereka tetap memegang kendali penuh atas user mereka sendiri, sementara kalian hanya menyediakan pintu masuk satu arah.

#Two-way Trust

Trust dua arah berarti kedua realm saling menerbitkan ticket untuk satu sama lain. Pola ini umum dipakai di merger, ketika dua perusahaan lama tetap mempertahankan realm masing-masing namun karyawannya harus bisa saling bekerja. Di balik layar, two-way trust hanyalah dua one-way trust yang dipasang berdampingan.

#Hierarchical Trust

Trust hierarkis mengikuti struktur domain, biasanya dari child realm ke parent realm. Dengan struktur ini, kebijakan trust bisa diturunkan dan dikelola secara terpusat di setiap level — sangat cocok untuk organisasi besar yang realm-nya banyak.

#Direct Trust

Trust langsung (direct trust) menghubungkan dua realm tanpa perantara. Ini bentuk trust paling sederhana dan paling cepat: satu hop, satu pasang kunci cross-realm, tanpa ketergantungan pada realm lain.

#Menyiapkan Cross-Realm

#Membuat Principal Cross-Realm

Kunci dari cross-realm adalah sepasang principal khusus: krbtgt/REALM2@REALM1 di KDC realm 1 dan krbtgt/REALM1@REALM2 di KDC realm 2. Keduanya menyimpan shared secret yang sama — inilah yang membuat KDC realm 1 percaya bahwa KDC realm 2 adalah otoritas yang sah untuk realm 2.

sudo kadmin.local -q "addprinc -pw 'Shared-S3cret-CrossRealm-Am4n' krbtgt/REALM2.EXAMPLE.COM@REALM1.EXAMPLE.COM"

Di KDC realm 2, buat pasangannya dengan password yang persis sama:

sudo kadmin.local -q "addprinc -pw 'Shared-S3cret-CrossRealm-Am4n' krbtgt/REALM1.EXAMPLE.COM@REALM2.EXAMPLE.COM"

#Berbagi Shared Secret

Nama principal di kedua sisi berbeda, tetapi kuncinya harus identik. Password yang sama menghasilkan kunci yang sama di kedua KDC selama daftar enctype yang didukung juga sama — hal yang akan menjadi sangat relevan di episode 11. Alternatif untuk lingkungan yang tidak ingin menaruh password di history shell: buat dengan -randkey, ekspor ke keytab dengan ktadd, lalu salin keytab itu ke KDC pasangan lewat kanal yang aman.

sudo kadmin.local -q "ktadd -k /etc/krb5kdc/cross-realm.keytab krbtgt/REALM2.EXAMPLE.COM@REALM1.EXAMPLE.COM"
sudo scp /etc/krb5kdc/cross-realm.keytab root@kdc2.example.com:/etc/krb5kdc/

#Konfigurasi capaths

[capaths] pada krb5.conf menggambar peta jalur antar realm. Untuk trust langsung, capaths sebetulnya opsional — KDC akan menerbitkan referral otomatis. capaths menjadi wajib ketika jalurnya tidak langsung atau ketika ada lebih dari satu jalur yang mungkin sehingga klien harus tahu jalur mana yang benar.

Menggambar jalur hierarkis di /etc/krb5.conf

[capaths]
    LA.CORP.EXAMPLE.COM = {
        CORP.EXAMPLE.COM = {
            EXAMPLE.COM = .
        }
    }

Bacaan blok di atas: realm LA.CORP.EXAMPLE.COM mencapai EXAMPLE.COM dengan transit melalui CORP.EXAMPLE.COM. Tanda titik di bagian terdalam menandakan bahwa hop terakhir bersifat langsung. Karena setiap realm membaca capaths-nya sendiri, blok yang sama sebaiknya diselaraskan di semua klien yang berpartisipasi.

#Menguji Autentikasi Lintas Realm

Setelah principal dan capaths dipasang, uji jalurnya dengan meminta ticket dari realm tujuan:

kinit budi@REALM1.EXAMPLE.COM
kvno host/server@REALM2.EXAMPLE.COM
klist

Jika kvno berhasil mengambil service ticket untuk host/server@REALM2.EXAMPLE.COM, maka seluruh rantai — TGT lokal, referral ticket, dan ticket dari KDC tujuan — sudah bekerja. klist akan menampilkan deretan ticket yang memuat realm perantara.

#Menelusuri Jalur Trust

#Referral Ticket

Saat user dengan TGT dari realm 1 meminta service ticket untuk host/server@REALM2, KDC realm 1 tidak mengenal service itu. Alih-alih langsung menolak, ia memeriksa kunci cross-realm krbtgt/REALM2@REALM1. Jika ada, KDC realm 1 menerbitkan referral ticket — sejatinya sebuah TGT untuk realm 2 yang dienkripsi dengan kunci cross-realm tadi. Klien kemudian memakainya untuk berkomunikasi dengan KDC realm 2, yang akhirnya menerbitkan service ticket yang sebenarnya. Inilah mekanisme di balik ticket yang membawa user menyeberang antar realm.

#Realm Perantara dan Rantai Trust

Ketika tidak ada trust langsung antara realm asal dan realm tujuan, klien menelusuri trust chain hop demi hop. Dari LA.CORP.EXAMPLE.COM, klien meminta referral ke CORP.EXAMPLE.COM, lalu dari sana referral lagi ke EXAMPLE.COM, dan baru kemudian ke service tujuan. Setiap hop menghasilkan satu cross-realm TGT, dan semuanya terangkai membentuk rantai. Setiap realm perantara harus punya kunci cross-realm ke tetangganya, dan jalurnya harus diketahui klien lewat capaths.

#Optimasi Jalur

Semakin panjang rantai, semakin banyak perjalanan bolak-balik dan semakin banyak kunci yang harus dipegang. Karena itu path optimization adalah praktik yang disarankan: gunakan trust langsung untuk pasangan realm yang sering berkomunikasi, dan jaga rantai tetap pendek. [capaths] juga berfungsi memilih jalur dan menghindari loop ketika ada lebih dari satu rute yang mungkin — tanpa capaths, klien bisa mencoba jalur acak yang berakhir di jalan buntu.

#Kasus Penggunaan

Cross-realm menyelesaikan masalah yang muncul di hampir semua organisasi yang bertumbuh:

• Merger & akuisisi — dua perusahaan mempertahankan realm dan KDC masing-masing, lalu dihubungkan dengan trust dua arah tanpa membangun ulang seluruh direktori.
• Akses organisasi partner — trust satu arah memberi user partner akses ke layanan kalian sambil menutup arah sebaliknya.
• Deployment multi-datacenter — tiap pusat data bisa memegang KDC dan realm sendiri, saling terhubung trust sehingga kegagalan satu KDC tidak melumpuhkan seluruh lingkungan.
• Forest trusts (Active Directory) — saat Windows menyebut forest trust, di balik layar itulah mekanisme cross-realm Kerberos dengan principal krbtgt yang bekerja.

#Penutup

Pada episode 10 ini, kalian menghubungkan banyak realm: konsep batas kepercayaan dan trust relationship, tipe trust satu arah, dua arah, hierarkis, dan langsung; pasangan principal krbtgt dengan shared secret; peta jalur di capaths; cara kerja referral ticket lewat realm perantara; serta kasus penggunaan nyata dari merger sampai forest trust.

Inti yang harus dibawa pulang:

• Cross-realm adalah pasangan kunci — krbtgt/REALM2@REALM1 dan kembarannya di KDC tujuan harus berbagi secret yang identik.
• Transitivitas tidak otomatis — setiap hop butuh kunci cross-realm, dan jalurnya dinyatakan di capaths.
• Referral ticket adalah TGT antar realm — klien menelusuri trust chain sampai KDC tujuan menerbitkan service ticket.
• kvno host/server@REALM2 adalah uji cepat untuk membuktikan sebuah jalur trust.

Di episode 11 berikutnya, kita masuk ke detail yang menentukan berhasil tidaknya semua ini: encryption types — bagaimana memilih enctype AES modern, menyingkirkan DES dan RC4 yang lemah, dan menyamakan kemampuan enkripsi di seluruh realm.