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

To mekanismer giver det samme venlige resultat på en Mac og opfører sig helt forskelligt under overfladen. Den ene henter Kerberos-billetter gennem en SSO-udvidelse og giver dem videre til deltagende programmer. Den anden holder en browsersession hos en identitetsudbyder og lader webprogrammer anerkende den. De adskiller sig i, hvad de kræver på netværket, hvor længe deres legitimationsoplysninger holder, og hvad der sker i det øjeblik, tunnelen falder.

To mekanismer, én loginskærm

Den billetbaserede vej afhænger af et Kerberos-domæne, et nøglefordelingscenter og et ur, der er enigt med det. Browservejen afhænger af en tilgængelig identitetsudbyder, en cookie eller token og et program, der stoler på den udsteder. Begge kan konfigureres til at starte ved login, og derfor forveksles de med den samme funktion. Programmerne afgør, hvilken af de to de accepterer, og en Mac kan med rette køre begge på én gang.

Sammenlign dem ved at spørge, hvad programmet kontrollerer, når en bruger åbner det. En filservice, der er tilsluttet Kerberos-domænet, vil have en servicebillet, og ingen mængde browsersession vil tilfredsstille den. Et webprogram bag en moderne identitetsudbyder vil have den udsteders token og ignorerer Kerberos-billetten fuldstændigt. Når du ved, hvilken kontrol der finder sted, bliver udrulningsspørgsmålene konkrete i stedet for generelle.

Hvad Kerberos-udvidelsen har brug for på netværket

Apples vejledning til Kerberos SSO-udvidelsen beskriver indbygget Active Directory-godkendelse med proaktiv billetindhentning, parret med lokale konti i stedet for en domænetilknytning. Det, den ikke kan, er at opfinde en vej til domænecontrollerne. Mac'en har brug for en resolver, der svarer på Kerberos-serviceregistrene, og en rute, der når dem gennem den godkendte tunnel. En profil, der installeres rent, beviser intet, før domænet faktisk kan opdages fra klienten.

Kontrollér opdagelsen, før du kontrollerer legitimationsoplysningerne: SRV-registrene for Kerberos-domænet skal slås op, og de adresser, de returnerer, skal kunne nås, når VPN'en er oppe. Tid betyder lige så meget som tilgængelighed, fordi Kerberos afviser anmodninger fra et ur, der er løbet ud over sin tolerance, og den fejl, det giver, ligner en godkendelsesfejl. En Mac, der ikke kan nå en tidskilde, mens tunnelen er nede, vil fejle igen i det øjeblik, den vender tilbage. Ret tidskilden som en del af udrulningen i stedet for som en reaktion på en hændelse.

klist
sudo sntp -sS time.apple.com

VPN pr. app afgør, om udvidelsen kan virke

En fuld tunnel ruter alt og skjuler dette problem. En konfiguration pr. app ruter kun de programmer, der er nævnt i VPN-profilen, og SSO-udvidelsen er selv en proces, der har brug for netværket til at hente billetter. Hvis den ikke er i mappingen, lykkes det lokale login, tunnelen kommer op for browseren, og billetindhentningen fejler stadig.

Læs VPN-konfigurationen, og list hvert program, den skal dække, og tilføj derefter SSO-komponenten gennem den dokumenterede mappingmekanisme i stedet for at gætte et bundle-id. At mappe den synlige klient og ikke komponenten bag den er den klassiske version af denne fejl. Hold mappingen i samme administrerede profil som udvidelsen, så en ændring i den ene ikke lydløst kan ugyldiggøre den anden. Test med en bruger, der aldrig har logget ind på den Mac, fordi en cachet billet kan få en brudt vej til at se sund ud, og test derefter igen efter en adgangskodeændring.

En browseridentitetssession er en anden kontrakt

En browsersession har ikke noget Kerberos-domæne, ingen servicebillet og ingen urtolerance i Kerberos-forstand. Den har en udsteder, en tokenlevetid og en opdateringsvej, og dens fejltilstande er omdirigeringer, der aldrig fuldføres, og cookies, som et privat vindue kasserer. At behandle den som en erstatning for billetvejen er kun sikkert der, hvor programmet selv accepterer den udsteder. At kopiere et godkendelsessvar fra VPN-portalen til en ubeslægtet tjeneste er ikke integration, hvor bekvem genvejen end ser ud.

Når begge mekanismer er udrullet, skal du dokumentere, hvilke programmer der bruger hvilken, fordi supportsamtalen afhænger af det. En bruger, der rapporterer at være logget ind, men ikke kan åbne en fildeling, beskriver to systemer, og svaret er, at billetvejen aldrig kørte. En bruger, der kan åbne delingen, men ikke intranetportalen, beskriver det omvendte, og hvis mekanismen nævnes i billetten, spares en runde spørgsmål.

Gå gennem sekvensen, ikke delene

Gå gennem hele kæden med en almindelig tilmeldt konto: lokalt login, tunnel, billetindhentning og derefter én rigtig handling mod en tjeneste. Gentag det, efter at tunnelen har genoprettet forbindelsen, og efter en bevidst adgangskodeændring, fordi hvert af disse tilfælde øver en anden del af levetidslogikken. At hvert trin består for sig selv er ikke det samme som, at kæden virker. Kæden er det, brugeren oplever, og det er det, accepttesten skal dække.

Notér profilens ejer, VPN-godkendelsesmetoden, domæneopdagelsesvejen og udvidelsens appmapping ét sted. Den registrering er det, der gør flowet reproducerbart af en person, der ikke har bygget det. Kontrollér derefter den fejl, du mest sandsynligt vil møde, en udløbet billet, mens tunnelen er nede, og bekræft, at klienten kommer sig uden genstart, fordi en udrulning, der kun virker fra en kold start, ikke er færdig.

Notér også ejeren af hvert trin, fordi et Kerberos-domæne, som ingen vedligeholder, bliver et forældet et. En kæde, som ingen kan beskrive, er en kæde, som ingen kan fejlfinde.