Kerberos SSO och VPN på Mac: jämför de två inloggningsvägarna

Två mekanismer ger samma vänliga resultat på en Mac och beter sig helt olika under ytan. Den ena hämtar Kerberos-biljetter via ett SSO-tillägg och lämnar dem till deltagande program. Den andra håller en webbläsarsession hos en identitetsleverantör och låter webbprogram erkänna den. De skiljer sig i vad de behöver i nätverket, hur länge deras autentiseringsuppgifter gäller och vad som händer i samma ögonblick som tunneln faller.

Två mekanismer, en inloggningsskärm

Biljettvägen beror på en Kerberos-domän, ett nyckeldistributionscenter och en klocka som stämmer med den. Webbläsarvägen beror på en nåbar identitetsleverantör, en cookie eller token och ett program som litar på den utgivaren. Båda kan konfigureras att starta vid inloggning, vilket är varför de förväxlas med samma funktion. Programmen avgör vilken av de två de accepterar, och en Mac kan legitimt köra båda samtidigt.

Jämför dem genom att fråga vad programmet kontrollerar när en användare öppnar det. En filtjänst som är ansluten till Kerberos-domänen vill ha en tjänstebiljett, och ingen mängd webbläsarsession kommer att tillfredsställa den. Ett webbprogram bakom en modern identitetsleverantör vill ha den utgivarens token och ignorerar Kerberos-biljetten helt. När du vet vilken kontroll som sker blir distributionsfrågorna specifika i stället för allmänna.

Vad Kerberos-tillägget behöver i nätverket

Apples guide för Kerberos SSO-tillägget beskriver inbyggd Active Directory-autentisering med proaktiv biljettinhämtning, parad med lokala konton i stället för domänbindning. Det den inte kan är att hitta på en väg till domänkontrollanterna. Macen behöver en resolver som svarar på Kerberos-tjänstposterna och en rutt som når dem genom den godkända tunneln. En profil som installeras rent bevisar ingenting förrän domänen faktiskt kan upptäckas från klienten.

Kontrollera upptäckten innan du kontrollerar autentiseringsuppgifterna: SRV-posterna för Kerberos-domänen måste lösas upp, och adresserna de returnerar måste vara nåbara när VPN:en är uppe. Tid är lika viktigt som nåbarhet, eftersom Kerberos avvisar förfrågningar från en klocka som har drivit utanför toleransen, och felet det ger ser ut som ett autentiseringsfel. En Mac som inte når en tidskälla medan tunneln är nere kommer att misslyckas igen i samma ögonblick som den kommer tillbaka. Åtgärda tidskällan som en del av distributionen och inte som en incidentrespons.

klist
sudo sntp -sS time.apple.com

VPN per program avgör om tillägget kan fungera

En full tunnel dirigerar allt och döljer detta problem. En konfiguration per program dirigerar bara de program som namnges i VPN-profilen, och SSO-tillägget är självt en process som behöver nätverket för att hämta biljetter. Om det inte finns i mappningen lyckas den lokala inloggningen, tunneln kommer upp för webbläsaren och biljettinhämtningen misslyckas ändå.

Läs VPN-konfigurationen och lista varje program den ska täcka, lägg sedan till SSO-komponenten via den dokumenterade mappningsmekanismen i stället för att gissa ett paket-id. Att mappa den synliga klienten och inte komponenten bakom den är den klassiska versionen av detta misstag. Håll mappningen i samma hanterade profil som tillägget, så att en ändring i den ena inte tyst kan ogiltigförklara den andra. Testa med en användare som aldrig har loggat in på den Macen, eftersom en cachad biljett kan få en trasig väg att se frisk ut, och testa sedan igen efter ett lösenordsbyte.

En webbläsaridentitetssession är ett annat avtal

En webbläsarsession har ingen Kerberos-domän, ingen tjänstebiljett och ingen klocktolerans i Kerberos mening. Den har en utgivare, en tokenlivslängd och en förnyelseväg, och dess fellägen är omdirigeringar som aldrig slutförs och cookies som ett privat fönster kastar. Att behandla den som en ersättning för biljettvägen är bara säkert där programmet självt accepterar den utgivaren. Att kopiera ett autentiseringssvar från VPN-portalen till en orelaterad tjänst är inte integration, hur bekväm genvägen än verkar.

När båda mekanismerna är utrullade, dokumentera vilka program som använder vilken, eftersom supportsamtalet beror på det. En användare som rapporterar att den är inloggad men inte kan öppna en filresurs beskriver två system, och svaret är att biljettvägen aldrig kördes. En användare som kan öppna resursen men inte intranätportalen beskriver det omvända, och att namnge mekanismen i ärendet sparar en frågerunda.

Gå igenom sekvensen, inte delarna

Gå igenom hela kedjan med ett vanligt registrerat konto: lokal inloggning, tunnel, biljettinhämtning och sedan en riktig åtgärd mot en tjänst. Upprepa det efter att tunneln har återanslutit och efter ett medvetet lösenordsbyte, eftersom vart och ett av dessa fall övar en annan del av livslängdslogiken. Att varje steg klarar sig på egen hand är inte samma sak som att kedjan fungerar. Kedjan är det användaren upplever, och det är vad acceptanstestet måste täcka.

Anteckna profilägaren, VPN-autentiseringsmetoden, domänupptäcktsvägen och tilläggets programmappning på ett ställe. Den anteckningen är det som gör flödet reproducerbart av någon som inte byggde det. Kontrollera sedan felet du mest sannolikt kommer att möta, en utgången biljett medan tunneln är nere, och bekräfta att klienten återhämtar sig utan omstart, eftersom en distribution som bara fungerar från kallstart inte är klar.

Notera också ägaren av varje steg, eftersom en Kerberos-domän som ingen underhåller blir föråldrad. En kedja som ingen kan beskriva är en kedja som ingen kan felsöka.