VPN før login på macOS: oplåsning, loginvindue, session

Her er en overbevisning, der koster folk en uge: at en Mac har ét øjeblik, der hedder før login, og at en VPN-klient enten starter der eller ikke. Maskinen har faktisk mindst tre øjeblikke, hvor netværksadgang betyder noget, adskilt af hvem der på det punkt har lov til at holde legitimationsoplysninger. En klient, der startes fra et login-element, dækker præcis ét af dem, og det er det sidste.

Myten om, at én indstilling dækker hele opstarten

Læs produktsiden igen, og se efter hvilken fase funktionen nævner. Et afkrydsningsfelt med teksten start ved login betyder et login-element, som kører, efter at en brugersession findes. Et afkrydsningsfelt med teksten forbind ved behov betyder, at klienten åbner en forbindelse, når trafikken matcher en regel, hvilket stadig kræver, at klienten og dens legitimationsoplysninger er tilgængelige.

Ingen af dem når opstartsprocessen. Det er ikke en begrænsning, som leverandøren har glemt at fjerne; det er, hvad operativsystemet tillader. Før disken er låst op, findes der ikke et kørende system at starte en klient fra, og efter log ud forlader brugerens hemmeligheder sessionen. To adskilte mure, og ingen af dem viger for et andet afkrydsningsfelt.

Når du adskiller faserne, skifter det oprindelige spørgsmål form. I stedet for at spørge, om VPN'en starter før login, spørger du, hvilket af tre konkrete øjeblikke der skal virke, og så opdager du, at hvert af dem har en anden ejer: krypteringslaget, netværksudvidelsen eller brugersessionen.

Hvad der faktisk sker i hver fase

Opstarten begynder med en krypteret disk, som skal låses op, før der findes et brugbart system til noget alment. Den oplåsning sker i en begrænset kontekst med et begrænset sæt legitimationsoplysninger, og Apple dokumenterer klart, at krypterede data forbliver utilgængelige uden en gyldig oplåsning.

Derefter kommer loginvinduet, hvor systemet kører, men der endnu ikke findes en brugersession. En udvidelse i brugerkontekst er allerede afsluttet, hvis brugeren har logget ud, og en global systemudvidelse kan stadig køre, men at køre er ikke det samme som at holde de legitimationsoplysninger, din VPN har brug for.

Så kommer sessionen, hvor en normal klient kan læse login-nøgleringen, bede om en anden faktor og anvende skubbede ruter. De fleste funktioner, folk beskriver som før login, er faktisk denne fase, udløst tidligt i sessionen snarere end før den.

Hvorfor en launch daemon ikke kan logge ind for en fraværende bruger

Forhøjede rettigheder føles som om de burde løse problemet, og det gør de ikke. En launch daemon kører som en systemproces uden en brugersession bag sig, så der er ingen nøglering at låse op og intet menneske til at svare på en anmodning. Den kan åbne en socket og læse en fil; det, den ikke kan, er at blive den bruger, der ejer legitimationsoplysningerne. Rettigheder er ikke identitet, og det er præcis her, de to blandes sammen.

Det, folk bygger i det hul, er et script med en adgangskode i, hvilket er et værre problem end det, de startede med.

Den ærlige version af kravet er smallere. Hvis maskinen skal nå en beskyttet ressource, mens ingen er til stede, skal den identitet, ressourcen accepterer, være en, maskinen kan holde uden en person: et enhedscertifikat, en legitimationsoplysning i systemnøgleringen eller en konto, hvis anden faktor ikke er et push til en telefon i nogens lomme. Design den identitet bevidst, og fasespørgsmålet besvarer som regel sig selv.

Windows-funktionen før login overføres ikke

Windows har en dokumenteret adgangsmekanisme før login til nogle fjernadgangsprodukter, og navnet rejser bedre end evnen. En funktion beskrevet i en Windows-udrulningsvejledning fortæller dig intet om, hvorvidt den samme leverandør implementerer en tilsvarende på macOS.

Bed om en erklæring, der dækker Mac-hardware, macOS-versionen, klientversionen og den godkendelsesmetode, du faktisk bruger. En generel påstand om support er ikke nok, fordi forskellen mellem at virke og ikke virke ofte ligger i en af de fire.

Hvis leverandøren ikke kan svare, er det svaret. Planlæg sessionfasen, og design et alternativ til den ubemandede situation, i stedet for at opdage hullet under en udrulning.

Hvad du i stedet skal bede om

Skriv kravet i fasernes sprog. Hvilken ressource, nødvendig for hvem, i hvilken kontekst, og med hvilken acceptabel forsinkelse når forbindelsen endnu ikke er der?

Hvis svaret er en bruger, der logger ind og derefter har brug for tunnelen, er forbind ved behov og et opstartselement tilstrækkeligt og billigt. Hvis svaret er en maskine, der genstarter om natten og skal rapportere, kræver designet en understøttet vej til at låse disken op, en enhedsidentitet og en gendannelsesproces, der virker, når netværket aldrig kommer op. Hvis svaret er organisationslogin, der afhænger af tunnelen, skal designet af login, identitet og VPN bygges sammen i stedet for at købes separat.

Apples FileVault-dokumentation er det rigtige udgangspunkt for oplåsningsfasen. Alt efter det er et klient- og identitetsspørgsmål, som en leverandørerklæring bør afgøre, før du køber.