Kerberos SSO og VPN på Mac: sammenlign de to påloggingsveiene

To mekanismer gir det samme vennlige resultatet på en Mac og oppfører seg helt forskjellig under overflaten. Den ene henter Kerberos-billetter gjennom en SSO-utvidelse og gir dem videre til programmer som deltar. Den andre holder en nettlesersesjon hos en identitetsleverandør og lar nettprogrammer anerkjenne den. De skiller seg i hva de trenger på nettverket, hvor lenge påloggingsinformasjonen deres varer, og hva som skjer i det øyeblikket tunnelen faller.

To mekanismer, én påloggingsskjerm

Den billettbaserte veien avhenger av et Kerberos-domene, et nøkkelfordelingssenter og en klokke som stemmer med det. Nettleserveien avhenger av en tilgjengelig identitetsleverandør, en informasjonskapsel eller token, og et program som stoler på den utstederen. Begge kan konfigureres til å starte ved pålogging, og derfor forveksles de med samme funksjon. Programmene bestemmer hvilken av de to de godtar, og en Mac kan med rette kjøre begge samtidig.

Sammenlign dem ved å spørre hva programmet kontrollerer når en bruker åpner det. En filtjeneste som er tilsluttet Kerberos-domenet, vil ha en tjenestebillett, og ingen mengde nettlesersesjon vil tilfredsstille den. Et nettprogram bak en moderne identitetsleverandør vil ha den utstederens token og ignorerer Kerberos-billetten fullstendig. Når du vet hvilken kontroll som skjer, blir utrullingsspørsmålene konkrete i stedet for generelle.

Hva Kerberos-utvidelsen trenger på nettverket

Apples veiledning for Kerberos SSO-utvidelsen beskriver innebygd Active Directory-autentisering med proaktiv billettinnhenting, sammenkoblet med lokale kontoer i stedet for domenetilknytning. Det den ikke kan, er å finne opp en vei til domenekontrollerne. Macen trenger en resolver som svarer på Kerberos-tjenestepostene, og en rute som når dem gjennom den godkjente tunnelen. En profil som installeres rent, beviser ingenting før domenet faktisk kan oppdages fra klienten.

Kontroller oppdagelsen før du kontrollerer påloggingsinformasjonen: SRV-postene for Kerberos-domenet må løses, og adressene de returnerer må være tilgjengelige når VPN-en er oppe. Tid betyr like mye som tilgjengelighet, fordi Kerberos avviser forespørsler fra en klokke som har drevet utenfor toleransen, og feilen det gir ser ut som en autentiseringsfeil. En Mac som ikke når en tidskilde mens tunnelen er nede, vil feile igjen i det øyeblikket den kommer tilbake. Rett tidskilden som en del av utrullingen og ikke som en hendelsesrespons.

klist
sudo sntp -sS time.apple.com

VPN per program avgjør om utvidelsen kan fungere

En full tunnel ruter alt og skjuler dette problemet. En konfigurasjon per program ruter bare programmene som er navngitt i VPN-profilen, og SSO-utvidelsen er selv en prosess som trenger nettverket for å hente billetter. Hvis den ikke er i kartleggingen, lykkes den lokale påloggingen, tunnelen kommer opp for nettleseren, og billettinnhentingen feiler fortsatt.

Les VPN-konfigurasjonen og list opp hvert program den skal dekke, og legg deretter til SSO-komponenten gjennom den dokumenterte kartleggingsmekanismen i stedet for å gjette en pakkeidentifikator. Å kartlegge den synlige klienten og ikke komponenten bak den er den klassiske versjonen av denne feilen. Hold kartleggingen i samme administrerte profil som utvidelsen, slik at en endring i den ene ikke stille kan ugyldiggjøre den andre. Test med en bruker som aldri har logget på den Macen, fordi en bufret billett kan få en ødelagt vei til å se sunn ut, og test deretter igjen etter en passordendring.

En nettleseridentitetssesjon er en annen kontrakt

En nettlesersesjon har ingen Kerberos-domene, ingen tjenestebillett og ingen klokketoleranse i Kerberos-forstand. Den har en utsteder, en tokenlevetid og en fornyelsesvei, og feilmodusene er omdirigeringer som aldri fullføres og informasjonskapsler som et privat vindu forkaster. Å behandle den som en erstatning for billettveien er bare trygt der programmet selv godtar den utstederen. Å kopiere et autentiseringssvar fra VPN-portalen til en urelatert tjeneste er ikke integrasjon, uansett hvor praktisk snarveien virker.

Når begge mekanismene er rullet ut, dokumenter hvilke programmer som bruker hvilken, fordi støttesamtalen avhenger av det. En bruker som rapporterer å være pålogget men ikke kan åpne en fildeling, beskriver to systemer, og svaret er at billettveien aldri kjørte. En bruker som kan åpne delingen men ikke intranettportalen, beskriver det motsatte, og å navngi mekanismen i saken sparer en runde med spørsmål.

Gå gjennom sekvensen, ikke delene

Gå gjennom hele kjeden med en vanlig registrert konto: lokal pålogging, tunnel, billettinnhenting, deretter én ekte operasjon mot en tjeneste. Gjenta det etter at tunnelen har koblet til igjen og etter en bevisst passordendring, fordi hvert av disse tilfellene trener en annen del av levetidslogikken. At hvert trinn består for seg selv, er ikke det samme som at kjeden virker. Kjeden er det brukeren opplever, og det er det akseptansetesten må dekke.

Noter profileier, VPN-autentiseringsmetode, domeneoppdagelsesvei og utvidelsens programkartlegging på ett sted. Den registreringen er det som gjør flyten reproduserbar av noen som ikke bygde den. Kontroller deretter feilen du mest sannsynlig vil møte, en utløpt billett mens tunnelen er nede, og bekreft at klienten kommer seg uten omstart, fordi en utrulling som bare virker fra kaldstart ikke er ferdig.

Noter også eieren av hvert trinn, fordi et Kerberos-domene ingen vedlikeholder blir utdatert. En kjede ingen kan beskrive, er en kjede ingen kan feilsøke.