Kerberos SSO a VPN na Macu: porovnejte dvě cesty přihlášení

Dva mechanismy dávají na Macu stejný příjemný výsledek a uvnitř se chovají úplně jinak. Jeden získává kerberosové lístky přes rozšíření SSO a předává je zúčastněným aplikacím. Druhý udržuje relaci prohlížeče u poskytovatele identity a nechává webové aplikace, aby ji respektovaly. Liší se v tom, co potřebují v síti, jak dlouho vydrží jejich přihlašovací údaje a co se stane ve chvíli, kdy tunel spadne.

Dva mechanismy, jedna přihlašovací obrazovka

Cesta založená na lístcích závisí na doméně Kerberos, centru pro distribuci klíčů a hodinách, které jsou s ní v souladu. Cesta přes prohlížeč závisí na dostupném poskytovateli identity, cookie nebo tokenu a aplikaci, která tomuto vydavateli důvěřuje. Obě lze nastavit tak, aby se spustily při přihlášení, a proto se považují za stejnou funkci. Aplikace rozhodují, kterou z těch dvou přijmou, a Mac může legitimně provozovat obě současně.

Porovnejte je tak, že se zeptáte, co aplikace kontroluje, když ji uživatel otevře. Souborová služba připojená k doméně Kerberos chce servisní lístek a žádné množství relace prohlížeče to nesplní. Webová aplikace za moderním poskytovatelem identity chce token tohoto poskytovatele a kerberosový lístek zcela ignoruje. Jakmile víte, která kontrola probíhá, otázky k nasazení se stanou konkrétními místo obecnými.

Co rozšíření Kerberos potřebuje v síti

Apple ve průvodci rozšířením Kerberos SSO popisuje nativní ověřování v Active Directory s proaktivním získáváním lístků, spojené s místními účty místo vazby na doménu. Co nedokáže, je vymyslet cestu k řadičům domény. Mac potřebuje překladač, který odpovídá na kerberosové servisní záznamy, a trasu, která se k nim dostane přes schválený tunel. Profil, který se čistě nainstaluje, nic nedokazuje, dokud doménu nelze skutečně objevit z klienta.

Zkontrolujte zjišťování dřív než přihlašovací údaje: záznamy SRV pro doménu Kerberos se musí přeložit a adresy, které vracejí, musí být dostupné, jakmile je VPN nahoře. Čas je stejně důležitý jako dostupnost, protože Kerberos odmítá požadavky z hodin, které se odchýlily nad jeho toleranci, a chyba, kterou to vyprodukuje, vypadá jako selhání ověření. Mac, který se nedostane ke zdroji času, dokud je tunel dole, selže znovu ve chvíli, kdy se vrátí. Opravte zdroj času jako součást nasazení, ne jako reakci na incident.

klist
sudo sntp -sS time.apple.com

VPN pro jednotlivé aplikace rozhoduje, zda rozšíření může fungovat

Plný tunel směruje vše a tento problém skrývá. Konfigurace pro jednotlivé aplikace směruje jen aplikace uvedené v profilu VPN a rozšíření SSO je samo proces, který k získání lístků potřebuje síť. Pokud v mapování není, místní přihlášení uspěje, tunel se pro prohlížeč zvedne a získání lístku přesto selže.

Přečtěte si konfiguraci VPN a vypište každou aplikaci, kterou má pokrývat, potom přidejte komponentu SSO přes dokumentovaný mechanismus mapování, ne hádáním identifikátoru balíčku. Namapovat viditelného klienta a ne komponentu za ním je klasická verze této chyby. Udržujte mapování ve stejném spravovaném profilu jako rozšíření, aby změna jednoho nemohla tiše zneplatnit druhé. Testujte s uživatelem, který se na tom Macu nikdy nepřihlásil, protože uložený lístek může vadnou cestu jevit jako zdravou, a poté test zopakujte po změně hesla.

Relace identity v prohlížeči je jiná smlouva

Relace prohlížeče nemá doménu Kerberos, servisní lístek ani toleranci hodin v kerberosovém smyslu. Má vydavatele, životnost tokenu a cestu obnovy a jejími režimy selhání jsou přesměrování, která nikdy neskončí, a cookies, které soukromé okno zahodí. Považovat ji za náhradu cesty lístků je bezpečné jen tam, kde aplikace sama tohoto vydavatele přijímá. Kopírování autentizační odpovědi z portálu VPN do nesouvisející služby není integrace, ať už zkratka vypadá jakkoli pohodlně.

Když jsou nasazeny oba mechanismy, zdokumentujte, které aplikace používají který, protože na tom závisí rozhovor s podporou. Uživatel, který hlásí, že je přihlášen, ale nemůže otevřít souborovou sdílenou složku, popisuje dva systémy a odpovědí je, že cesta lístků nikdy neběžela. Uživatel, který otevře sdílenou složku, ale ne intranetový portál, popisuje opak, a pojmenování mechanismu v tiketu ušetří jedno kolo otázek.

Projděte posloupnost, ne části

Projděte celý řetěz s běžným zapsaným účtem: místní přihlášení, tunel, získání lístku a poté jedna skutečná operace vůči službě. Zopakujte to po opětovném připojení tunelu a po úmyslné změně hesla, protože každý z těchto případů procvičuje jinou část logiky životnosti. To, že každá fáze projde sama o sobě, není totéž jako fungující řetěz. Řetěz je to, co uživatel zažívá, a to musí pokrýt akceptační test.

Zaznamenejte vlastníka profilu, metodu ověřování VPN, cestu zjišťování domény a mapování aplikací rozšíření na jedno místo. Právě tento záznam dělá tok reprodukovatelným pro někoho, kdo ho nestavěl. Potom zkontrolujte selhání, se kterým se nejpravděpodobněji setkáte, prošlý lístek při vypnutém tunelu, a potvrďte, že se klient zotaví bez restartu, protože nasazení, které funguje jen ze studeného startu, není hotové.

Poznamenejte si i vlastníka každé fáze, protože doména Kerberos, o kterou se nikdo nestará, zestárne. Řetěz, který nikdo nedokáže popsat, je řetěz, který nikdo nedokáže ladit.