Kerberos SSO at VPN sa Mac: ihambing ang dalawang landas ng pag-sign in

Dalawang mekanismo ang nagbibigay ng parehong magiliw na resulta sa isang Mac at kumikilos nang lubos na naiiba sa ilalim. Ang isa ay kumukuha ng mga tiket ng Kerberos sa pamamagitan ng SSO extension at ibinibigay ang mga ito sa mga kalahok na application. Ang isa naman ay nagpapanatili ng session ng browser sa isang identity provider at hinahayaan ang mga web application na tanggapin ito. Nagkakaiba sila sa kung ano ang kailangan nila sa network, gaano katagal ang kanilang mga kredensyal, at ano ang nangyayari sa sandaling bumagsak ang tunnel.

Dalawang mekanismo, isang screen ng pag-sign in

Ang landas na batay sa tiket ay nakadepende sa isang domain ng Kerberos, isang sentro ng pamamahagi ng key at isang orasan na sumasang-ayon dito. Ang landas ng browser ay nakadepende sa isang maabot na identity provider, isang cookie o token, at isang application na nagtitiwala sa issuer na iyon. Pareho silang maaaring i-configure na magsimula sa pag-sign in, kaya napagkakamalang parehong feature. Ang mga application ang nagpapasya kung alin sa dalawa ang tatanggapin, at ang isang Mac ay legal na makakapagpatakbo ng pareho nang sabay.

Ihambing sila sa pamamagitan ng pagtatanong kung ano ang sinisuri ng application kapag binuksan ito ng user. Ang serbisyo ng file na konektado sa domain ng Kerberos ay nangangailangan ng service ticket, at walang dami ng browser session ang makakasapat dito. Ang web application sa likod ng modernong identity provider ay nangangailangan ng token ng provider na iyon at ganap na binabalewala ang tiket ng Kerberos. Kapag alam mo kung aling pagsusuri ang nangyayari, nagiging tiyak ang mga tanong sa deployment sa halip na pangkalahatan.

Ano ang kailangan ng Kerberos extension sa network

Ang gabay sa Kerberos SSO extension ng Apple ay naglalarawan ng native na authentication ng Active Directory na may proactive na pagkuha ng tiket, na ipinares sa mga lokal na account sa halip na pag-binding sa domain. Ang hindi nito magagawa ay ang mag-imbento ng landas patungo sa mga domain controller. Ang Mac ay nangangailangan ng resolver na sumasagot sa mga service record ng Kerberos at isang ruta na umaabot sa mga ito sa pamamagitan ng aprubadong tunnel. Ang profile na malinis na naka-install ay walang pinapatunayan hanggang sa tunay na matuklasan ang domain mula sa client.

Suriin ang pagtuklas bago suriin ang mga kredensyal: ang mga SRV record ng domain ng Kerberos ay dapat malutas, at ang mga address na ibinabalik nila ay dapat maabot kapag nakataas ang VPN. Ang oras ay kasinghalaga ng pag-abot, dahil tinatanggihan ng Kerberos ang mga kahilingan mula sa orasang lumihis nang lampas sa tolerance nito, at ang error na nagagawa nito ay mukhang pagkabigo sa authentication. Ang isang Mac na hindi makarating sa pinagmulan ng oras habang nakababa ang tunnel ay muli ring mabibigo sa sandaling bumalik ito. Ayusin ang pinagmulan ng oras bilang bahagi ng deployment at hindi bilang tugon sa insidente.

klist
sudo sntp -sS time.apple.com

Ang VPN bawat app ang nagpapasya kung gagana ang extension

Ang buong tunnel ay nagruruta ng lahat at itinatago ang problemang ito. Ang configuration bawat app ay nagruruta lamang ng mga application na pinangalanan sa profile ng VPN, at ang SSO extension mismo ay isang proseso na nangangailangan ng network upang kumuha ng mga tiket. Kung wala ito sa mapping, nagtatagumpay ang lokal na pag-sign in, umaangat ang tunnel para sa browser, at nabibigo pa rin ang pagkuha ng tiket.

Basahin ang configuration ng VPN at ilista ang bawat application na dapat nitong saklawin, pagkatapos ay idagdag ang SSO component sa pamamagitan ng dokumentadong mekanismo ng mapping sa halip na hulaan ang bundle identifier. Ang pag-map sa nakikitang client at hindi sa component sa likod nito ang klasikong bersyon ng pagkakamaling ito. Panatilihin ang mapping sa parehong pinamamahalaang profile tulad ng extension, upang ang pagbabago sa isa ay hindi tahimik na magpawalang-bisa sa isa. Subukan sa isang user na hindi pa nag-sign in sa Mac na iyon, dahil ang naka-cache na tiket ay maaaring magpakita ng sirang landas na parang malusog, pagkatapos ay subukan muli pagkatapos ng pagbabago ng password.

Ang session ng pagkakakilanlan sa browser ay ibang kontrata

Ang session ng browser ay walang domain ng Kerberos, walang service ticket at walang tolerance ng orasan sa kahulugan ng Kerberos. Mayroon itong issuer, tagal ng buhay ng token at landas ng refresh, at ang mga paraan ng pagkabigo nito ay mga redirect na hindi natatapos at mga cookie na itinatapon ng pribadong window. Ang ituring ito bilang kapalit ng landas ng tiket ay ligtas lamang kung saan tinatanggap ng application mismo ang issuer na iyon. Ang pagkopya ng tugon ng authentication mula sa portal ng VPN patungo sa isang walang kaugnayang serbisyo ay hindi integration, gaano man kaginhawa ang shortcut.

Kapag naka-deploy ang parehong mekanismo, idokumento kung aling mga application ang gumagamit ng alin, dahil nakadepende dito ang usapan sa suporta. Ang user na nag-uulat na naka-sign in ngunit hindi mabuksan ang file share ay naglalarawan ng dalawang sistema, at ang sagot ay hindi kailanman tumakbo ang landas ng tiket. Ang user na makakabukas ng share ngunit hindi ang intranet portal ay naglalarawan ng kabaligtaran, at ang pagbanggit sa mekanismo sa tiket ay nakakatipid ng isang round ng mga tanong.

Lakarin ang pagkakasunod-sunod, hindi ang mga bahagi

Lakarin ang buong chain gamit ang ordinaryong naka-enroll na account: lokal na pag-sign in, tunnel, pagkuha ng tiket, pagkatapos ay isang tunay na operasyon laban sa isang serbisyo. Ulitin ito pagkatapos ng muling pagkonekta ng tunnel at pagkatapos ng sadyang pagbabago ng password, dahil ang bawat isa sa mga kasong iyon ay nagsasanay ng ibang bahagi ng lohika ng tagal ng buhay. Ang bawat yugto na pumasa nang mag-isa ay hindi kapareho ng gumaganang chain. Ang chain ang karanasan ng user, at ito ang dapat saklawin ng acceptance case.

Itala ang may-ari ng profile, ang paraan ng authentication ng VPN, ang landas ng pagtuklas ng domain at ang mapping ng application ng extension sa isang lugar. Ang rekord na iyon ang nagpapaging-muling-maipakita ng daloy para sa isang taong hindi ito itinayo. Pagkatapos ay suriin ang pagkabigong malamang na makaharap mo, isang nag-expire na tiket habang nakababa ang tunnel, at kumpirmahin na gumagaling ang client nang walang reboot, dahil ang deployment na gumagana lamang mula sa malamig na pagsisimula ay hindi pa tapos.

Itala rin ang may-ari ng bawat yugto, dahil ang domain ng Kerberos na walang nag-aalaga ay nagiging lipas na. Ang chain na walang makapaglalarawan ay chain na walang makapag-debug.