Kerberos SSO en VPN op de Mac: vergelijk de twee inlogroutes

Twee mechanismen leveren op een Mac hetzelfde vriendelijke resultaat en gedragen zich eronder volstrekt anders. Het ene haalt Kerberos-tickets op via een SSO-extensie en geeft ze aan deelnemende apps. Het andere houdt een browsersessie bij een identiteitsprovider en laat webapps die erkennen. Ze verschillen in wat ze op het netwerk nodig hebben, hoe lang hun inloggegevens geldig blijven en wat er gebeurt op het moment dat de tunnel wegvalt.

Twee mechanismen, één inlogscherm

De ticketroute hangt af van een Kerberos-domein, een sleutelverdelingscentrum en een klok die daarmee overeenkomt. De browserroute hangt af van een bereikbare identiteitsprovider, een cookie of token, en een app die die uitgever vertrouwt. Beide kunnen worden ingesteld om bij het inloggen te starten, waardoor ze voor dezelfde functie worden aangezien. De apps beslissen welke van de twee ze accepteren, en een Mac kan beide legitiem tegelijk draaien.

Vergelijk ze door te vragen wat de app controleert wanneer een gebruiker die opent. Een bestandsservice die aan het Kerberos-domein is gekoppeld, wil een serviceticket, en geen enkele hoeveelheid browsersessie zal daaraan voldoen. Een webapp achter een moderne identiteitsprovider wil het token van die provider en negeert het Kerberos-ticket volledig. Zodra je weet welke controle plaatsvindt, worden de implementatievragen specifiek in plaats van algemeen.

Wat de Kerberos-extensie op het netwerk nodig heeft

Apples handleiding voor de Kerberos SSO-extensie beschrijft native Active Directory-verificatie met proactieve ticketverwerving, gekoppeld aan lokale accounts in plaats van een domeinkoppeling. Wat hij niet kan, is een route naar de domeincontrollers verzinnen. De Mac heeft een resolver nodig die de Kerberos-servicerecords beantwoordt, en een route die ze via de goedgekeurde tunnel bereikt. Een profiel dat schoon installeert, bewijst niets totdat het domein daadwerkelijk vanaf de client kan worden ontdekt.

Controleer de ontdekking voordat je de inloggegevens controleert: de SRV-records voor het Kerberos-domein moeten worden opgelost, en de adressen die ze teruggeven moeten bereikbaar zijn zodra de VPN actief is. Tijd is net zo belangrijk als bereikbaarheid, omdat Kerberos verzoeken weigert van een klok die buiten de tolerantie is afgedreven, en de fout die dat oplevert lijkt op een verificatiefout. Een Mac die geen tijdbron bereikt terwijl de tunnel weg is, zal opnieuw falen op het moment dat hij terugkomt. Los de tijdbron op als onderdeel van de implementatie en niet als reactie op een incident.

klist
sudo sntp -sS time.apple.com

VPN per app bepaalt of de extensie kan werken

Een volledige tunnel routeert alles en verbergt dit probleem. Een configuratie per app routeert alleen de apps die in het VPN-profiel worden genoemd, en de SSO-extensie is zelf een proces dat het netwerk nodig heeft om tickets op te halen. Als hij niet in de mapping staat, slaagt de lokale login, komt de tunnel omhoog voor de browser, en mislukt het ophalen van tickets alsnog.

Lees de VPN-configuratie en som elke app op die hij moet dekken, voeg dan de SSO-component toe via het gedocumenteerde mappingmechanisme in plaats van een bundle-id te raden. De zichtbare client mappen en niet de component erachter is de klassieke versie van deze fout. Houd de mapping in hetzelfde beheerde profiel als de extensie, zodat een wijziging in de ene de andere niet stilzwijgend ongeldig kan maken. Test met een gebruiker die nooit op die Mac heeft ingelogd, omdat een gecacht ticket een kapotte route gezond kan laten lijken, en test daarna opnieuw na een wachtwoordwijziging.

Een browser-identiteitssessie is een ander contract

Een browsersessie heeft geen Kerberos-domein, geen serviceticket en geen kloktolerantie in de zin van Kerberos. Ze heeft een uitgever, een tokenlevensduur en een vernieuwingspad, en haar faalmodi zijn redirects die nooit voltooien en cookies die een privévenster weggooit. Haar als vervanging van de ticketroute behandelen is alleen veilig waar de app zelf die uitgever accepteert. Een verificatieantwoord van het VPN-portaal naar een ongerelateerde dienst kopiëren is geen integratie, hoe handig de snelkoppeling ook lijkt.

Wanneer beide mechanismen zijn ingezet, documenteer dan welke apps welke gebruiken, want het supportgesprek hangt daarvan af. Een gebruiker die meldt te zijn ingelogd maar geen bestandsshare kan openen, beschrijft twee systemen, en het antwoord is dat de ticketroute nooit heeft gedraaid. Een gebruiker die de share wel kan openen maar het intranetportaal niet, beschrijft het omgekeerde, en de naam van het mechanisme in het ticket scheelt een ronde vragen.

Doorloop de volgorde, niet de onderdelen

Doorloop de hele keten met een gewoon ingeschreven account: lokale login, tunnel, ticketverwerving en dan één echte bewerking tegen een dienst. Herhaal dat nadat de tunnel opnieuw verbinding maakt en na een bewuste wachtwoordwijziging, omdat elk van die gevallen een ander deel van de levensduurlogica oefent. Dat elke fase op zichzelf slaagt, is niet hetzelfde als een werkende keten. De keten is wat de gebruiker ervaart, en dat is wat de acceptatietest moet dekken.

Leg de profieleigenaar, de VPN-verificatiemethode, het domeinontdekkingspad en de app-mapping van de extensie op één plek vast. Die registratie maakt de flow reproduceerbaar door iemand die hem niet heeft gebouwd. Controleer dan de fout die je het meest zult tegenkomen, een verlopen ticket terwijl de tunnel weg is, en bevestig dat de client herstelt zonder herstart, want een implementatie die alleen vanuit een koude start werkt, is niet af.

Noteer ook de eigenaar van elke fase, want een Kerberos-domein waar niemand naar omkijkt, wordt verouderd. Een keten die niemand kan beschrijven, is een keten die niemand kan debuggen.