Kerberos SSO dan VPN di Mac: bandingkan dua laluan log masuk

Dua mekanisme menghasilkan hasil mesra yang sama pada Mac dan berkelakuan sangat berbeza di bawah permukaan. Satu memperoleh tiket Kerberos melalui sambungan SSO dan menyerahkannya kepada aplikasi yang menyertai. Yang lain mengekalkan sesi pelayar dengan penyedia identiti dan membenarkan aplikasi web mematuhinya. Kedua-duanya berbeza dalam apa yang diperlukan pada rangkaian, berapa lama kelayakan mereka bertahan dan apa yang berlaku pada saat terowong terputus.

Dua mekanisme, satu skrin log masuk

Laluan berasaskan tiket bergantung pada domain Kerberos, pusat pengedaran kunci dan jam yang bersetuju dengannya. Laluan pelayar bergantung pada penyedia identiti yang boleh dicapai, kuki atau token, dan aplikasi yang mempercayai pengeluar itu. Kedua-duanya boleh dikonfigurasikan untuk bermula semasa log masuk, sebab itulah ia disalah anggap sebagai ciri yang sama. Aplikasi menentukan yang mana satu daripada kedua-duanya diterima, dan Mac boleh menjalankan kedua-duanya secara sah pada masa yang sama.

Bandingkan kedua-duanya dengan bertanya apa yang diperiksa oleh aplikasi apabila pengguna membukanya. Perkhidmatan fail yang menyertai domain Kerberos mahukan tiket perkhidmatan, dan tiada jumlah sesi pelayar akan memuaskannya. Aplikasi web di belakang penyedia identiti moden mahukan token penyedia itu dan mengabaikan tiket Kerberos sepenuhnya. Sebaik sahaja anda tahu pemeriksaan mana yang berlaku, soalan penggunaan menjadi khusus dan bukan umum.

Apa yang diperlukan oleh sambungan Kerberos pada rangkaian

Panduan sambungan Kerberos SSO Apple menerangkan pengesahan Active Directory asli dengan pemerolehan tiket proaktif, dipasangkan dengan akaun tempatan dan bukannya pengikatan domain. Apa yang tidak dapat dilakukannya ialah mencipta laluan ke pengawal domain. Mac memerlukan penyelesai yang menjawab rekod perkhidmatan Kerberos dan laluan yang mencapainya melalui terowong yang diluluskan. Profil yang dipasang dengan bersih tidak membuktikan apa-apa sehingga domain benar-benar boleh ditemui daripada klien.

Periksa penemuan sebelum memeriksa kelayakan: rekod SRV untuk domain Kerberos mesti diselesaikan, dan alamat yang dikembalikannya mesti boleh dicapai apabila VPN dinaikkan. Masa sama pentingnya dengan capaian, kerana Kerberos menolak permintaan daripada jam yang telah menyimpang melebihi toleransinya, dan ralat yang dihasilkannya kelihatan seperti kegagalan pengesahan. Mac yang tidak dapat mencapai sumber masa semasa terowong turun akan gagal lagi pada saat ia kembali. Betulkan sumber masa sebagai sebahagian daripada penggunaan dan bukan sebagai tindak balas insiden.

klist
sudo sntp -sS time.apple.com

VPN setiap aplikasi menentukan sama ada sambungan boleh berfungsi

Terowong penuh menghalakan semuanya dan menyembunyikan masalah ini. Konfigurasi setiap aplikasi hanya menghalakan aplikasi yang dinamakan dalam profil VPN, dan sambungan SSO itu sendiri ialah proses yang memerlukan rangkaian untuk mengambil tiket. Jika ia tiada dalam pemetaan, log masuk tempatan berjaya, terowong naik untuk pelayar, dan pemerolehan tiket masih gagal.

Baca konfigurasi VPN dan senaraikan setiap aplikasi yang sepatutnya diliputi, kemudian tambah komponen SSO melalui mekanisme pemetaan yang didokumenkan dan bukan meneka pengecam bundel. Memetakan klien yang kelihatan dan bukan komponen di belakangnya ialah versi klasik kesilapan ini. Simpan pemetaan dalam profil terurus yang sama dengan sambungan, supaya perubahan pada satu tidak boleh membatalkan yang lain secara senyap. Uji dengan pengguna yang tidak pernah log masuk pada Mac itu, kerana tiket yang dicache boleh membuat laluan rosak kelihatan sihat, kemudian uji semula selepas pertukaran kata laluan.

Sesi identiti pelayar ialah kontrak yang berbeza

Sesi pelayar tidak mempunyai domain Kerberos, tiket perkhidmatan dan toleransi jam dalam erti kata Kerberos. Ia mempunyai pengeluar, jangka hayat token dan laluan penyegaran, dan mod kegagalannya ialah ubah hala yang tidak pernah selesai dan kuki yang dibuang oleh tetingkap peribadi. Menganggapnya sebagai pengganti laluan tiket hanya selamat di tempat aplikasi itu sendiri menerima pengeluar tersebut. Menyalin respons pengesahan daripada portal VPN ke perkhidmatan yang tidak berkaitan bukanlah integrasi, sesenang mana pun pintasan itu kelihatan.

Apabila kedua-dua mekanisme digunakan, dokumentasikan aplikasi mana menggunakan yang mana, kerana perbualan sokongan bergantung padanya. Pengguna yang melaporkan telah log masuk tetapi tidak dapat membuka perkongsian fail sedang menerangkan dua sistem, dan jawapannya ialah laluan tiket tidak pernah dijalankan. Pengguna yang boleh membuka perkongsian tetapi bukan portal intranet menerangkan sebaliknya, dan menamakan mekanisme dalam tiket menjimatkan satu pusingan soalan.

Ikut urutan, bukan bahagian

Ikut seluruh rantaian dengan akaun berdaftar biasa: log masuk tempatan, terowong, pemerolehan tiket, kemudian satu operasi sebenar terhadap perkhidmatan. Ulangi selepas terowong menyambung semula dan selepas pertukaran kata laluan yang disengajakan, kerana setiap kes itu melatih bahagian berbeza logik jangka hayat. Setiap peringkat lulus sendiri bukanlah sama dengan rantaian yang berfungsi. Rantaian itulah yang dialami pengguna, dan itulah yang mesti diliputi oleh kes penerimaan.

Catat pemilik profil, kaedah pengesahan VPN, laluan penemuan domain dan pemetaan aplikasi sambungan di satu tempat. Rekod itulah yang menjadikan aliran boleh dihasilkan semula oleh seseorang yang tidak membinanya. Kemudian periksa kegagalan yang paling mungkin anda temui, tiket tamat tempoh semasa terowong turun, dan sahkan klien pulih tanpa but semula, kerana penggunaan yang hanya berfungsi dari permulaan sejuk belum selesai.

Catat juga pemilik setiap peringkat, kerana domain Kerberos yang tiada siapa menjaga menjadi usang. Rantaian yang tiada siapa dapat menerangkan ialah rantaian yang tiada siapa dapat menyahpepijat.