Kerberos SSO dhe VPN në Mac: krahasoni dy rrugët e hyrjes

Dy mekanizma prodhojnë të njëjtin rezultat miqësor në një Mac dhe sillen krejt ndryshe nën sipërfaqe. Njëri merr bileta Kerberos përmes një shtojce SSO dhe ua dorëzon aplikacioneve pjesëmarrëse. Tjetri mban një sesion shfletuesi te një ofrues identiteti dhe lejon aplikacionet web ta pranojnë atë. Ata ndryshojnë në atë që u duhet në rrjet, sa zgjasin kredencialet e tyre dhe çfarë ndodh në momentin kur tuneli bie.

Dy mekanizma, një ekran hyrjeje

Rruga e bazuar në bileta varet nga një domen Kerberos, një qendër shpërndarjeje çelësash dhe një orë që pajtohet me të. Rruga e shfletuesit varet nga një ofrues identiteti i arritshëm, një cookie ose token dhe një aplikacion që i beson atij lëshuesi. Të dyja mund të konfigurohen të nisin në hyrje, prandaj ngatërrohen me të njëjtin funksion. Aplikacionet vendosin cilin nga të dy pranojnë, dhe një Mac mund t'i ekzekutojë të dy njëkohësisht në mënyrë legjitime.

Krahasoni duke pyetur çfarë kontrollon aplikacioni kur përdoruesi e hap atë. Një shërbim skedarësh i bashkuar me domenin Kerberos kërkon një biletë shërbimi, dhe asnjë sasi sesioni shfletuesi nuk do ta kënaqë atë. Një aplikacion web pas një ofruesi modern identiteti kërkon tokenin e atij ofruesi dhe e injoron plotësisht biletën Kerberos. Pasi të dini cili kontroll ndodh, pyetjet e vendosjes bëhen specifike në vend të përgjithshme.

Çfarë i duhet shtojcës Kerberos në rrjet

Udhëzuesi i shtojcës Kerberos SSO i Apple përshkruan vërtetimin vendas të Active Directory me marrje proaktive të biletave, të çiftëzuar me llogari lokale në vend të lidhjes me domenin. Ajo që nuk mund të bëjë është të shpikë një rrugë drejt kontrolluesve të domenit. Mac-i ka nevojë për një zgjidhës që u përgjigjet regjistrimeve të shërbimit Kerberos dhe një rrugë që i arrin ato përmes tunelit të miratuar. Një profil që instalohet pastër nuk provon asgjë derisa domeni të mund të zbulohet vërtet nga klienti.

Kontrolloni zbulimin përpara se të kontrolloni kredencialet: regjistrimet SRV të domenit Kerberos duhet të zgjidhen, dhe adresat që kthejnë duhet të jenë të arritshme pasi VPN të jetë ngritur. Koha është po aq e rëndësishme sa arritshmëria, sepse Kerberos refuzon kërkesat nga një orë që ka shmangur përtej tolerancës së tij, dhe gabimi që prodhon duket si dështim vërtetimi. Një Mac që nuk arrin një burim kohe ndërsa tuneli është poshtë do të dështojë përsëri në momentin kur ai kthehet. Rregulloni burimin e kohës si pjesë e vendosjes dhe jo si përgjigje ndaj një incidenti.

klist
sudo sntp -sS time.apple.com

VPN për aplikacion vendos nëse shtojca mund të funksionojë

Një tunel i plotë drejton gjithçka dhe e fsheh këtë problem. Një konfigurim për aplikacion drejton vetëm aplikacionet e emërtuara në profilin e VPN, dhe shtojca SSO është vetë një proces që ka nevojë për rrjetin për të marrë bileta. Nëse nuk është në mapim, hyrja lokale ka sukses, tuneli ngrihet për shfletuesin dhe marrja e biletave prapë dështon.

Lexoni konfigurimin e VPN dhe listoni çdo aplikacion që duhet të mbulojë, pastaj shtoni komponentin SSO përmes mekanizmit të dokumentuar të mapimit dhe jo duke hamendësuar një identifikues pakete. Mapimi i klientit të dukshëm dhe jo i komponentit pas tij është versioni klasik i këtij gabimi. Mbajeni mapimin në të njëjtin profil të menaxhuar si shtojca, që një ndryshim në njërën të mos e zhvlerësojë në heshtje tjetrën. Testoni me një përdorues që nuk është identifikuar kurrë në atë Mac, sepse një biletë e ruajtur në cache mund ta bëjë një rrugë të thyer të duket e shëndetshme, pastaj testoni përsëri pas një ndryshimi fjalëkalimi.

Një sesion identiteti në shfletues është një kontratë tjetër

Një sesion shfletuesi nuk ka domen Kerberos, biletë shërbimi dhe tolerancë ore në kuptimin e Kerberos. Ka një lëshues, një kohëzgjatje tokeni dhe një rrugë rifreskimi, dhe mënyrat e tij të dështimit janë ridrejtime që nuk përfundojnë kurrë dhe cookies që një dritare private i hedh. Trajtimi i tij si zëvendësues i rrugës së biletave është i sigurt vetëm aty ku vetë aplikacioni e pranon atë lëshues. Kopjimi i një përgjigjeje vërtetimi nga portali i VPN në një shërbim të palidhur nuk është integrim, sado i përshtatshëm që duket shkurtimi.

Kur të dy mekanizmat janë vendosur, dokumentoni cilat aplikacione përdorin cilin, sepse biseda e mbështetjes varet nga kjo. Një përdorues që raporton se është identifikuar por nuk mund të hapë një ndarje skedarësh po përshkruan dy sisteme, dhe përgjigjja është se rruga e biletave nuk u ekzekutua kurrë. Një përdorues që mund të hapë ndarjen por jo portalin e intranetit përshkruan të kundërtën, dhe emërtimi i mekanizmit në biletë kursen një raund pyetjesh.

Ecni sekuencën, jo pjesët

Ecni të gjithë zinxhirin me një llogari të regjistruar të zakonshme: hyrje lokale, tunel, marrje biletash, pastaj një operacion i vërtetë ndaj një shërbimi. Përsëriteni pasi tuneli rilidhet dhe pas një ndryshimi të qëllimshëm fjalëkalimi, sepse secili prej këtyre rasteve ushtron një pjesë tjetër të logjikës së jetëgjatësisë. Kalimi i secilës fazë më vete nuk është i njëjtë me zinxhirin që funksionon. Zinxhiri është ajo që përjeton përdoruesi, dhe është ajo që rasti i pranimit duhet të mbulojë.

Regjistroni pronarin e profilit, metodën e vërtetimit të VPN, rrugën e zbulimit të domenit dhe mapimin e aplikacioneve të shtojcës në një vend. Ai regjistrim e bën rrjedhën të riprodhueshme nga dikush që nuk e ndërtoi. Pastaj kontrolloni dështimin që ka më shumë gjasa të takoni, një biletë e skaduar ndërsa tuneli është poshtë, dhe konfirmoni që klienti rikuperohet pa rinisje, sepse një vendosje që funksionon vetëm nga nisje e ftohtë nuk është e përfunduar.

Shënoni edhe pronarin e secilës fazë, sepse një domen Kerberos që askush nuk kujdeset për të bëhet i vjetruar. Një zinxhir që askush nuk mund ta përshkruajë është një zinxhir që askush nuk mund ta korrigjojë.