Kerberos SSO kaj VPN ĉe Mac: komparu la du ensalutajn vojojn

Du mekanismoj produktas la saman afablan rezulton sur Mac kaj kondutas tute malsame sube. Unu akiras Kerberos-biletojn per SSO-etendaĵo kaj transdonas ilin al partoprenantaj programoj. La alia tenas retumilan sesion ĉe identeca provizanto kaj lasas retajn programojn agnoski ĝin. Ili malsamas en tio, kion ili bezonas en la reto, kiom longe daŭras iliaj akreditaĵoj kaj kio okazas en la momento, kiam la tunelo falas.

Du mekanismoj, unu ensaluta ekrano

La bileta vojo dependas de Kerberos-domajno, ŝlosildisiga centro kaj horloĝo, kiu kongruas kun ĝi. La retumila vojo dependas de atingebla identeca provizanto, kuketo aŭ ĵetono kaj programo, kiu fidas tiun eldonanton. Ambaŭ povas esti agorditaj por komenci ĉe ensaluto, kaj tial oni konfuzas ilin kun la sama funkcio. La programoj decidas, kiun el la du ili akceptas, kaj Mac povas laŭleĝe funkciigi ambaŭ samtempe.

Komparu ilin demandante, kion la programo kontrolas, kiam uzanto malfermas ĝin. Dosier-servo aliĝinta al la Kerberos-domajno volas servan bileton, kaj neniu kvanto da retumila sesio kontentigos ĝin. Reta programo malantaŭ moderna identeca provizanto volas la ĵetonon de tiu provizanto kaj tute ignoras la Kerberos-bileton. Sciante, kiu kontrolo okazas, la demandoj pri deplojo fariĝas specifaj anstataŭ ĝeneralaj.

Kion la Kerberos-etendaĵo bezonas en la reto

La gvidilo de Apple pri la Kerberos SSO-etendaĵo priskribas indiĝenan Active Directory-aŭtentikigon kun proaktiva bileta akiro, kune kun lokaj kontoj anstataŭ domajna ligo. Tio, kion ĝi ne povas, estas elpensi vojon al la domajnaj regiloj. La Mac bezonas solvilon, kiu respondas al la Kerberos-servaj rikordoj, kaj itineron, kiu atingas ilin tra la aprobita tunelo. Profilo, kiu instaliĝas pure, pruvas nenion, ĝis la domajno efektive estas malkovrebla de la kliento.

Kontrolu malkovron antaŭ ol kontroli akreditaĵojn: la SRV-rikordoj por la Kerberos-domajno devas solviĝi, kaj la adresoj, kiujn ili redonas, devas esti atingeblaj post kiam la VPN estas supre. Tempo gravas same kiel atingeblo, ĉar Kerberos malakceptas petojn de horloĝo, kiu drivis preter sia toleremo, kaj la eraro, kiun ĝi produktas, aspektas kiel aŭtentikiga malsukceso. Mac, kiu ne povas atingi tempofonton dum la tunelo estas sube, malsukcesos denove en la momento, kiam ĝi revenos. Riparu la tempofonton kiel parton de la deplojo, ne kiel reagon al incidento.

klist
sudo sntp -sS time.apple.com

VPN laŭ aplikaĵo decidas, ĉu la etendaĵo povas funkcii

Plena tunelo enkursigas ĉion kaj kaŝas ĉi tiun problemon. Agordo laŭ aplikaĵo enkursigas nur la aplikaĵojn nomitajn en la VPN-profilo, kaj la SSO-etendaĵo mem estas procezo, kiu bezonas la reton por akiri biletojn. Se ĝi ne estas en la mapado, loka ensaluto sukcesas, la tunelo leviĝas por la retumilo, kaj bileta akiro ankoraŭ malsukcesas.

Legu la VPN-agordon kaj listigu ĉiun aplikaĵon, kiun ĝi devas kovri, poste aldonu la SSO-komponanton per la dokumentita mapa mekanismo anstataŭ diveni pakaĵan identigilon. Mapigi la videblan klienton kaj ne la komponanton malantaŭ ĝi estas la klasika versio de ĉi tiu eraro. Tenu la mapadon en la sama administrata profilo kiel la etendaĵo, por ke ŝanĝo en la unu ne povu silente malvalidigi la alian. Testu kun uzanto, kiu neniam ensalutis sur tiu Mac, ĉar kaŝmemorita bileto povas igi rompitan vojon aspekti sana, poste testu denove post pasvorta ŝanĝo.

Retumila identeca sesio estas alia kontrakto

Retumila sesio havas neniun Kerberos-domajnon, neniun servan bileton kaj neniun horloĝan toleremon en la Kerberos-senso. Ĝi havas eldonanton, ĵetonan vivdaŭron kaj refreŝigan vojon, kaj ĝiaj malsukcesaj reĝimoj estas alidirektadoj, kiuj neniam finiĝas, kaj kuketoj, kiujn privata fenestro forĵetas. Trakti ĝin kiel anstataŭaĵon por la bileta vojo estas sekura nur tie, kie la programo mem akceptas tiun eldonanton. Kopii aŭtentikigan respondon de la VPN-portalo en nerilatan servon ne estas integriĝo, kiom ajn oportuna la fuŝvojo aspektas.

Kiam ambaŭ mekanismoj estas deplojitaj, dokumentu, kiuj aplikaĵoj uzas kiun, ĉar la subtena konversacio dependas de tio. Uzanto, kiu raportas esti ensalutinta sed ne povas malfermi dosieran kunhavon, priskribas du sistemojn, kaj la respondo estas, ke la bileta vojo neniam funkciis. Uzanto, kiu povas malfermi la kunhavon sed ne la intranet-portalon, priskribas la malon, kaj nomi la mekanismon en la bileto ŝparas unu raundon da demandoj.

Iru laŭ la sinsekvo, ne laŭ la partoj

Iru la tutan ĉenon kun ordinara enskribita konto: loka ensaluto, tunelo, bileta akiro, poste unu reala operacio kontraŭ servo. Ripetu ĝin post kiam la tunelo rekonektiĝas kaj post intenca pasvorta ŝanĝo, ĉar ĉiu el tiuj kazoj ekzercas alian parton de la vivdaŭra logiko. Tio, ke ĉiu etapo sukcesas sola, ne samas al funkcianta ĉeno. La ĉeno estas tio, kion la uzanto spertas, kaj ĝi estas tio, kion la akcepta kazo devas kovri.

Registru la profilan posedanton, la VPN-aŭtentikigan metodon, la domajnan malkovrovojon kaj la aplikaĵan mapadon de la etendaĵo en unu loko. Tiu rikordo estas tio, kio igas la fluon reproduktebla de iu, kiu ne konstruis ĝin. Poste kontrolu la malsukceson, kiun vi plej verŝajne renkontos, eksvalidiĝintan bileton dum la tunelo estas sube, kaj konfirmu, ke la kliento resaniĝas sen restartigo, ĉar deplojo, kiu funkcias nur de malvarma starto, ne estas finita.

Notu ankaŭ la posedanton de ĉiu etapo, ĉar Kerberos-domajno, kiun neniu prizorgas, fariĝas eksdata. Ĉeno, kiun neniu povas priskribi, estas ĉeno, kiun neniu povas sencimigi.