Mac-Kerberos-SSO en VPN: vergelyk die twee aanmeldroetes

Twee meganismes lewer dieselfde vriendelike resultaat op 'n Mac en gedra hulle onderlangs heeltemal anders. Die een kry Kerberos-kaartjies deur 'n SSO-uitbreiding en gee dit aan deelnemende programme. Die ander hou 'n blaaier-sessie by 'n identiteitsverskaffer en laat webprogramme dit erken. Hulle verskil in wat hulle op die netwerk nodig het, hoe lank hulle geloofsbriewe hou, en wat gebeur die oomblik wanneer die tonnel val.

Twee meganismes, een aanmeldskerm

Die kaartjie-gebaseerde pad hang af van 'n Kerberos-domein, 'n sleutelverspreidingsentrum en 'n klok wat daarmee saamstem. Die blaaierpad hang af van 'n bereikbare identiteitsverskaffer, 'n koekie of teken, en 'n program wat daardie uitreiker vertrou. Albei kan opgestel word om by aanmelding te begin, en daarom word hulle vir dieselfde funksie aangesien. Programme besluit watter van die twee hulle aanvaar, en 'n Mac kan wettiglik albei gelyktydig laat loop.

Vergelyk hulle deur te vra wat die program nagaan wanneer 'n gebruiker dit oopmaak. 'n Lêerdiens wat by die Kerberos-domein aangesluit is, wil 'n dienskaartjie hê, en geen hoeveelheid blaaier-sessie sal dit bevredig nie. 'n Webprogram agter 'n moderne identiteitsverskaffer wil daardie verskaffer se teken hê en ignoreer die Kerberos-kaartjie heeltemal. Sodra jy weet watter kontrole plaasvind, word die ontplooiingsvrae spesifiek eerder as algemeen.

Wat die Kerberos-uitbreiding op die draad nodig het

Apple se gids vir die Kerberos-SSO-uitbreiding beskryf inheemse Active Directory-verifikasie met proaktiewe kaartjieverkryging, gepaard met plaaslike rekeninge eerder as 'n domeinbinding. Wat dit nie kan doen nie, is om 'n pad na die domeinbeheerders te versin. Die Mac het 'n oplosser nodig wat die Kerberos-diensrekords beantwoord, en 'n roete wat hulle deur die goedgekeurde tonnel bereik. 'n Profiel wat skoon installeer, bewys niks totdat die domein werklik vanaf die kliënt ontdek kan word nie.

Kontroleer ontdekking voordat jy geloofsbriewe kontroleer: die SRV-rekords vir die Kerberos-domein moet oplos, en die adresse wat hulle teruggee, moet bereikbaar wees sodra die VPN op is. Tyd maak net soveel saak soos bereikbaarheid, want Kerberos verwerp versoeke van 'n klok wat buite sy tolerans gedryf het, en die fout wat dit lewer, lyk soos 'n verifikasiefout. 'n Mac wat nie 'n tydbron kan bereik terwyl die tonnel af is nie, sal weer misluk die oomblik wanneer dit terugkom. Maak die klokbron reg as deel van die ontplooiing eerder as as 'n insidentreaksie.

klist
sudo sntp -sS time.apple.com

Per-toepassing-VPN bepaal of die uitbreiding kan werk

’n Volle tonnel roeteer alles en verberg hierdie probleem. ’n Per-toepassing-opstelling roeteer net die toepassings wat in die VPN-profiel genoem word, en die SSO-uitbreiding is self ’n proses wat die netwerk nodig het om kaartjies te haal. As dit nie in die kartering is nie, slaag plaaslike aanmelding, kom die tonnel op vir die blaaier, en misluk kaartjieverkryging steeds.

Lees die VPN-opstelling en lys elke toepassing wat dit veronderstel is om te dek, en voeg dan die SSO-komponent by deur die gedokumenteerde karteringsmeganisme eerder as deur 'n bundelidentifiseerder te raai. Om die sigbare kliënt te karteer en nie die komponent agter hom nie, is die klassieke weergawe van hierdie fout. Hou die kartering in dieselfde bestuurde profiel as die uitbreiding, sodat 'n verandering aan die een nie die ander stilweg ongeldig kan maak nie. Toets met 'n gebruiker wat nog nooit op daardie Mac aangemeld het nie, want 'n gekasde kaartjie kan 'n stukkende pad gesond laat lyk, en toets dan weer ná 'n wagwoordverandering.

’n Blaaier-identiteitsessie is ’n ander kontrak

’n Blaaier-sessie het geen Kerberos-domein nie, geen dienskaartjie nie en geen kloktoleransie in die Kerberos-sin nie. Dit het ’n uitreiker, ’n tekenlewensduur en ’n herlaaipad, en sy mislukkingsmodusse is herleidings wat nooit voltooi nie en koekies wat ’n privaat venster weggooi. Om dit as ’n plaasvervanger vir die kaartjiepad te behandel, is net veilig waar die program self daardie uitreiker aanvaar. Om ’n verifikasie-antwoord van die VPN-portaal na ’n onverwante diens te kopieer, is nie integrasie nie, hoe gerieflik die kortpad ook lyk.

Wanneer albei meganismes ontplooi is, dokumenteer watter toepassings watter gebruik, want die ondersteuningsgesprek hang daarvan af. ’n Gebruiker wat rapporteer dat hy aangemeld is maar nie ’n lêerdeling kan oopmaak nie, beskryf twee stelsels, en die antwoord is dat die kaartjiepad nooit geloop het nie. ’n Gebruiker wat die deling kan oopmaak maar nie die intranetportaal nie, beskryf die omgekeerde, en om die meganisme in die kaartjie te noem, spaar ’n ronde vrae.

Stap die volgorde, nie die dele nie

Stap die hele ketting met ’n gewone ingeskrewe rekening: plaaslike aanmelding, tonnel, kaartjieverkryging, dan een werklike bewerking teen ’n diens. Herhaal dit nadat die tonnel weer verbind het en ná ’n doelbewuste wagwoordverandering, want elkeen van daardie gevalle oefen ’n ander deel van die lewensduurlogika. Elke stadium wat op sy eie slaag, is nie dieselfde as ’n ketting wat werk nie. Die ketting is wat die gebruiker ervaar, en dit is wat die aanvaardingstoets moet dek.

Teken die profieleienaar, die VPN-verifikasiemetode, die domeinontdekkingspad en die uitbreiding se toepassingkartering op een plek aan. Daardie rekord is wat die vloei reproduceerbaar maak vir iemand wat dit nie gebou het nie. Kontroleer dan die mislukking wat jy die waarskynlikste sal teëkom, ’n vervalle kaartjie terwyl die tonnel af is, en bevestig die kliënt herstel sonder 'n herbegin, want ’n ontplooiing wat net vanaf 'n koue begin werk, is nie klaar nie.

Let ook op die eienaar van elke stadium, want ’n Kerberos-domein wat niemand instandhou nie, word ’n verouderde een. ’n Ketting wat niemand kan beskryf nie, is ’n ketting wat niemand kan ontfout nie.