Kerberos SSO dan VPN di Mac: bandingkan dua jalur masuk

Dua mekanisme menghasilkan hasil ramah yang sama di Mac dan berperilaku sangat berbeda di baliknya. Satu memperoleh tiket Kerberos melalui ekstensi SSO dan menyerahkannya kepada aplikasi yang berpartisipasi. Yang lain mempertahankan sesi peramban dengan penyedia identitas dan membiarkan aplikasi web menghormatinya. Keduanya berbeda dalam apa yang mereka butuhkan di jaringan, berapa lama kredensialnya bertahan, dan apa yang terjadi saat terowongan putus.

Dua mekanisme, satu layar masuk

Jalur berbasis tiket bergantung pada domain Kerberos, pusat distribusi kunci, dan jam yang sepakat dengannya. Jalur peramban bergantung pada penyedia identitas yang dapat dijangkau, cookie atau token, dan aplikasi yang memercayai penerbit itu. Keduanya dapat dikonfigurasi untuk mulai saat masuk, itulah sebabnya keduanya dikira fitur yang sama. Aplikasi memutuskan mana dari keduanya yang diterima, dan Mac dapat menjalankan keduanya sekaligus secara sah.

Bandingkan keduanya dengan bertanya apa yang diperiksa aplikasi saat pengguna membukanya. Layanan berkas yang tergabung ke domain Kerberos menginginkan tiket layanan, dan berapa pun sesi peramban tidak akan memuaskannya. Aplikasi web di balik penyedia identitas modern menginginkan token penyedia itu dan sama sekali mengabaikan tiket Kerberos. Setelah tahu pemeriksaan mana yang terjadi, pertanyaan penerapan menjadi spesifik, bukan umum.

Apa yang dibutuhkan ekstensi Kerberos di jaringan

Panduan ekstensi Kerberos SSO dari Apple menjelaskan autentikasi Active Directory asli dengan perolehan tiket proaktif, dipasangkan dengan akun lokal alih-alih pengikatan domain. Yang tidak dapat dilakukannya adalah mengarang jalur ke pengontrol domain. Mac memerlukan penyelesai yang menjawab catatan layanan Kerberos, dan rute yang mencapainya melalui terowongan yang disetujui. Profil yang terpasang bersih tidak membuktikan apa pun sampai domain benar-benar dapat ditemukan dari klien.

Periksa penemuan sebelum memeriksa kredensial: catatan SRV untuk domain Kerberos harus terselesaikan, dan alamat yang dikembalikannya harus dapat dijangkau setelah VPN menyala. Waktu sama pentingnya dengan keterjangkauan, karena Kerberos menolak permintaan dari jam yang melenceng melewati toleransinya, dan galat yang dihasilkannya tampak seperti kegagalan autentikasi. Mac yang tidak dapat mencapai sumber waktu saat terowongan mati akan gagal lagi pada saat terowongan kembali. Perbaiki sumber waktu sebagai bagian dari penerapan, bukan sebagai tanggapan insiden.

klist
sudo sntp -sS time.apple.com

VPN per aplikasi menentukan apakah ekstensi dapat bekerja

Terowongan penuh merutekan semuanya dan menyembunyikan masalah ini. Konfigurasi per aplikasi hanya merutekan aplikasi yang disebutkan dalam profil VPN, dan ekstensi SSO sendiri adalah proses yang memerlukan jaringan untuk mengambil tiket. Jika tidak ada dalam pemetaan, masuk lokal berhasil, terowongan naik untuk peramban, dan perolehan tiket tetap gagal.

Baca konfigurasi VPN dan daftar setiap aplikasi yang seharusnya dicakupnya, lalu tambahkan komponen SSO melalui mekanisme pemetaan yang terdokumentasi, bukan dengan menebak pengenal bundel. Memetakan klien yang terlihat dan bukan komponen di belakangnya adalah versi klasik dari kesalahan ini. Simpan pemetaan dalam profil terkelola yang sama dengan ekstensi, agar perubahan pada satu tidak dapat membatalkan yang lain secara diam-diam. Uji dengan pengguna yang belum pernah masuk di Mac itu, karena tiket yang tersimpan dapat membuat jalur rusak tampak sehat, lalu uji lagi setelah perubahan kata sandi.

Sesi identitas peramban adalah kontrak yang berbeda

Sesi peramban tidak memiliki domain Kerberos, tidak memiliki tiket layanan, dan tidak memiliki toleransi jam dalam arti Kerberos. Ia memiliki penerbit, masa hidup token, dan jalur penyegaran, dan mode kegagalannya adalah pengalihan yang tidak pernah selesai serta cookie yang dibuang oleh jendela privat. Memperlakukannya sebagai pengganti jalur tiket hanya aman bila aplikasi itu sendiri menerima penerbit tersebut. Menyalin respons autentikasi dari portal VPN ke layanan yang tidak terkait bukanlah integrasi, sebanyak apa pun jalan pintas itu tampak nyaman.

Saat kedua mekanisme diterapkan, dokumentasikan aplikasi mana memakai yang mana, karena percakapan dukungan bergantung padanya. Pengguna yang melaporkan sudah masuk tetapi tidak dapat membuka berbagi berkas sedang menjelaskan dua sistem, dan jawabannya adalah jalur tiket tidak pernah berjalan. Pengguna yang dapat membuka berbagi tetapi tidak portal intranet sedang menjelaskan sebaliknya, dan menyebut mekanismenya di tiket menghemat satu putaran pertanyaan.

Jalani urutannya, bukan bagian-bagiannya

Jalani seluruh rantai dengan akun terdaftar biasa: masuk lokal, terowongan, perolehan tiket, lalu satu operasi nyata terhadap layanan. Ulangi setelah terowongan tersambung kembali dan setelah perubahan kata sandi yang disengaja, karena setiap kasus itu melatih bagian berbeda dari logika masa hidup. Lulusnya setiap tahap secara sendiri tidak sama dengan rantai yang bekerja. Rantai itulah yang dialami pengguna, dan itulah yang harus dicakup oleh kasus penerimaan.

Catat pemilik profil, metode autentikasi VPN, jalur penemuan domain, dan pemetaan aplikasi ekstensi di satu tempat. Catatan itulah yang membuat alur dapat direproduksi oleh orang yang tidak membangunnya. Lalu periksa kegagalan yang paling mungkin Anda temui, tiket kedaluwarsa saat terowongan mati, dan pastikan klien pulih tanpa boot ulang, karena penerapan yang hanya bekerja dari awal dingin belum selesai.

Catat juga pemilik setiap tahap, karena domain Kerberos yang tidak dirawat siapa pun menjadi usang. Rantai yang tidak dapat dijelaskan siapa pun adalah rantai yang tidak dapat di-debug siapa pun.