Hvorfor din Mac-VPN beder om Keychain-adgang hver gang

Et klik på Connect burde give ét login-vindue. På en Mac giver det ofte tre, og de deler sjældent ejer: nøgleringen ejer lokale anmodninger om adgangsoplysninger, VPN-gatewayen ejer autentificering, og klienten ejer sine egne meddelelser. I stedet for at lede efter en kontakt, der får alt til at tie, så behandl hvert vindue som en separat fejl med sin egen løsning. Vejledningen nedenfor går gennem ét bevidst forbindelsesforsøg og slutter med et tjek, du kan gentage.

Navngiv hver dialogs ejer, før du ændrer en indstilling

Det første skridt er bogholderi, ikke konfiguration. Udfør ét forbindelsesforsøg, og for hvert vindue, der vises, skriv fire felter ned: appnavnet i dialogen, den præcise tekst uden noget hemmeligt, den fase hvori det viste sig, og hvad der skete, da du annullerede det. Tre sådanne rækker dækker næsten enhver rapport, jeg har kigget på.

Ejerskab afgør den korrekte løsning, og den forkerte løsning er normalt det, der gør én prompt til tre:

En prompt, der vender tilbage inden for samme forsøg, er et andet signal end en, der vender tilbage ved det næste forsøg. Den første betyder normalt, at forbindelsen blev genstartet under dig; den anden betyder normalt, at der igen spørges til en gemt adgangsoplysning. Noter, hvilken du har, før du rører nøgleringen, for de to har næsten intet til fælles.

Find ud af, hvor mange ting der starter tunnelen

Fire mekanismer kan starte den samme VPN på en Mac: en menulinjehandling, et login-element, en On Demand-regel og et script eller en agent. Når to af dem udløses, kan den anden start ankomme, mens den første stadig venter på autentificering, hvilket giver et dobbelt vindue og ingen fremgang. List først, hvad der er konfigureret: scutil --nc list udskriver de VPN-tjenester, som Systemindstillinger kender, med deres aktuelle status. Klienter, der leverer deres egen netværksudvidelse, holder profiler inde i appen og vises måske ikke der, så tjek også klientens egen forbindelsesliste.

Se derefter efter konkurrerende startere. scutil --nc show "Work VPN" udskriver en indbygget tjenestes konfigurationsordbog, inklusive On Demand-regler; en regel, der genopretter forbindelse ved enhver grænsefladeændring, genstarter tunnelen — og åbner autentificeringsprompten igen — hver gang Wi-Fi vandrer, eller en skærm vækker netværksstakken. Tjek login-elementer under Systemindstillinger > Generelt > Login-elementer, og list agenter for hver bruger med ls ~/Library/LaunchAgents. Lad alt, der ejes af en MDM-styret sikkerhedsstak, være; fjernelse bliver normalt skubbet tilbage ved næste check-in.

For at se, hvad der faktisk kører under et forsøg: ps -Ao pid,comm | grep -iE 'vpn|tunnel|extension'. To klienthjælpere, hvor du forventer én, forklarer "hvorfor fik jeg to prompter" langt oftere end noget adgangsoplysningsproblem.

Reparer nøgleringeadgang uden at nulstille nøgleringen

Prompten kommer fra den gemte posts adgangskontrolliste, ikke fra VPN-protokollen. Hver post registrerer, hvilke programmer der må læse den uden at spørge. Efter en klientopdatering kan den hjælper, der spørger, have et andet navn eller en anden signatur, mens posten stadig viser den gamle, så macOS spørger igen ved hver forbindelse. At godkende den nye hjælper for netop den post er hele løsningen; at godkende hvert program er det ikke.

Du kan bekræfte, at ACL'en er årsagen uden at røre VPN'en: security find-generic-password -s "service-name" -g læser den samme post fra en terminal. Hvis den kommando også fremkalder prompten, tilhører dialogen nøgleringen, og tunnelen er kun udløseren. Apples vejledning om de tre knapper — Tillad én gang, Tillad altid, Afvis — er værd at læse én gang, fordi Afvis er det, der får prompten til at vende tilbage med det samme i stedet for ved næste forsøg.

Hvis du godkendte den forkerte hjælper, skal du åbne posten i Nøgleringadgang, skifte til Adgangskontrol og fjerne den post; det er tilbagerulningen. Sletning af login-nøgleringen eller kørsel af et reparationsværktøj, der genopbygger den, smider også urelaterede adgangskoder væk og er en meget større ændring end problemet.

Hold login- og politiktrin i de flows, der ejer dem

Et browser-login eller MFA-udfordring tilhører gatewayen. Hvis din organisation tilbyder sessionsvedholdenhed eller certifikatbaseret autentificering, så brug det, fordi det er den understøttede måde at autentificere sjældnere. At taste en fast kode ind i en klient eller gemme en adgangskode i et script, så prompten aldrig vises, erstatter en interaktiv faktor med en statisk hemmelighed og fejler næste gang, politikken roteres.

Organisationsmeddelelser er den ene kategori, du ikke bør undertrykke. De håndhæver normalt et posture-tjek eller en accept af acceptabel brug, og at skjule dem kan sætte enheden ud af overensstemmelse, selv mens tunnelen virker. Fejldialoger er den anden kategori: gem den første fejltekst, fordi en anden dialog ofte blot er den samme fejl rapporteret efter et nyt forsøg.

Bekræft med ét forsøg, derefter efter en genstart

Med dobbelte startere fjernet og nøgleringeposten repareret, udfør ét enkelt forsøg: afslut hver klientinstans inklusive menulinjehjælperen, opret forbindelse én gang, og tæl vinduerne. Du vil have nøgleringegodkendelsen, hvis posten blev genopbygget, og ét autentificeringstrin. Intet mere. scutil --nc status "Work VPN" bør rapportere Connected for en indbygget tjeneste.

Genstart derefter én gang, og gentag. En prompt, der kun vender tilbage efter en genstart, peger på et login-element eller en On Demand-regel, ikke på adgangsoplysninger; en, der vender tilbage i sessionen, peger på ACL'en eller på en anden starter. Hvis den stadig gentages efter begge gennemløb, er det nyttige at give din administrator tabellen med tre rækker fra det første forsøg — ejer, præcis tekst, fase — ikke et skærmbillede af dialogen.

Færre prompter er målet, ikke tavse. En forbindelse, der skjuler sine autorisationstrin, er en forbindelse, du ikke længere kan revidere, og den næste certifikatrotation vil finde dig uden anelse om, hvilken komponent der fejler.