Hvorfor Mac-VPN-en din ber om Keychain-tilgang hver gang
Kartlegg hvilken komponent som reiser hver Mac-VPN-forespørsel, stopp doble tilkoblingsforsøk, og reparer Keychain-tilgang uten å nullstille hele nøkkelringen.
Ett klikk på Connect skal gi ett påloggingsvindu. På en Mac gir det ofte tre, og de deler sjelden eier: nøkkelringen eier lokale forespørsler om påloggingsinformasjon, VPN-gatewayen eier autentiseringen, og klienten eier sine egne varsler. I stedet for å lete etter en bryter som får alt til å tie, behandle hvert vindu som en egen feil med sin egen løsning. Veiledningen nedenfor går gjennom ett bevisst tilkoblingsforsøk og avsluttes med en kontroll du kan gjenta.
Navngi eieren av hver dialog før du endrer en innstilling
Det første trinnet er bokføring, ikke konfigurasjon. Utfør ett tilkoblingsforsøk, og for hvert vindu som dukker opp, skriv ned fire felt: appnavnet i dialogen, den nøyaktige teksten uten noe hemmelig, fasen det dukket opp i, og hva som skjedde da du avbrøt det. Tre slike rader dekker nesten hver rapport jeg har sett på.
Eierskap avgjør riktig løsning, og feil løsning er vanligvis det som gjør én forespørsel til tre:
| Window | Who owns it | Correct fix | What not to do |
|---|---|---|---|
| “wants to use your confidential information stored in…” | The item's access control list in your login keychain | Approve the specific client helper, once, after checking the name | Resetting the login keychain, or granting Always Allow to every application |
| “Sign in to <organization>” or an MFA push | The gateway's identity provider | Use the client's supported session renewal, or re-authenticate | Scripting a fixed password or code into the client |
| “Connection failed”, “Update required”, a policy banner | The client or your organization | Read the first error and fix its cause | Hiding notices by editing a preference file the client rewrites |
En forespørsel som kommer tilbake i samme forsøk, er et annet signal enn en som kommer tilbake ved neste forsøk. Den første betyr vanligvis at tilkoblingen ble startet på nytt under deg; den andre betyr vanligvis at lagret påloggingsinformasjon spørres om igjen. Noter hvilken du har før du rører nøkkelringen, for de to har nesten ingenting til felles.
Finn ut hvor mange ting som starter tunnelen
Fire mekanismer kan starte samme VPN på en Mac: en menylinjehandling, et påloggingselement, en On Demand-regel og et skript eller en agent. Når to av dem utløses, kan den andre starten komme mens den første fortsatt venter på autentisering, noe som gir et dobbelt vindu og ingen fremgang. List først opp hva som er konfigurert: scutil --nc list skriver ut VPN-tjenestene Systeminnstillinger kjenner, med gjeldende status. Klienter som leverer sin egen nettverksutvidelse holder profiler inne i appen og vises kanskje ikke der, så sjekk også klientens egen tilkoblingsliste.
Se deretter etter konkurrerende startere. scutil --nc show "Work VPN" skriver ut konfigurasjonsordboken til en innebygd tjeneste, inkludert On Demand-regler; en regel som kobler til på nytt ved enhver grensesnittendring, starter tunnelen på nytt — og åpner autentiseringsforespørselen igjen — hver gang Wi-Fi flytter seg eller en skjerm vekker nettverksstakken. Sjekk påloggingselementer under Systeminnstillinger > Generelt > Påloggingselementer, og list agenter per bruker med ls ~/Library/LaunchAgents. La alt som eies av en MDM-styrt sikkerhetsstakk være i fred; fjerning blir vanligvis dyttet tilbake ved neste sjekk.
For å se hva som faktisk kjører under et forsøk: ps -Ao pid,comm | grep -iE 'vpn|tunnel|extension'. To klienthjelpere der du forventer én forklarer "hvorfor fikk jeg to forespørsler" langt oftere enn noe påloggingsproblem.
Reparer nøkkelringtilgang uten å nullstille nøkkelringen
Forespørselen kommer fra den lagrede postens tilgangskontrolliste, ikke fra VPN-protokollen. Hver post registrerer hvilke programmer som kan lese den uten å spørre. Etter en klientoppdatering kan hjelperen som spør, ha et annet navn eller en annen signatur mens posten fortsatt lister opp den gamle, så macOS spør igjen ved hver tilkobling. Å godkjenne den nye hjelperen for nettopp den posten er hele løsningen; å godkjenne hvert program er det ikke.
Du kan bekrefte at ACL er årsaken uten å røre VPN-en: security find-generic-password -s "service-name" -g leser den samme posten fra en terminal. Hvis den kommandoen også utløser forespørselen, tilhører dialogen nøkkelringen og tunnelen er bare utløseren. Apples veiledning om de tre knappene — Tillat én gang, Tillat alltid, Avvis — er verdt én lesing, fordi Avvis er det som får forespørselen til å komme tilbake med en gang i stedet for ved neste forsøk.
Hvis du godkjente feil hjelper, åpne posten i Nøkkelringtilgang, bytt til Tilgangskontroll og fjern den posten; det er tilbakerullingen. Sletting av påloggingsnøkkelringen, eller kjøring av et reparasjonsverktøy som bygger den opp igjen, kaster også bort urelaterte passord og er en mye større endring enn problemet.
Hold påloggings- og policysteg i flytene som eier dem
En nettleserpålogging eller MFA-utfordring tilhører gatewayen. Hvis organisasjonen din tilbyr sesjonsvedvarenhet eller sertifikatbasert autentisering, bruk det, fordi det er den støttede måten å autentisere sjeldnere på. Å skrive inn en fast kode i en klient, eller lagre et passord i et skript slik at forespørselen aldri vises, erstatter en interaktiv faktor med en statisk hemmelighet og feiler neste gang policyen roteres.
Organisasjonsvarsler er den ene kategorien du ikke bør undertrykke. De håndhever vanligvis en tilstandssjekk eller en bekreftelse av akseptabel bruk, og å skjule dem kan sette enheten ut av samsvar selv mens tunnelen fungerer. Feildialoger er den andre kategorien: ta vare på den første feilteksten, fordi en andre dialog ofte bare er samme feil rapportert etter et nytt forsøk.
Verifiser med ett forsøk, deretter etter en omstart
Med doble startere fjernet og nøkkelringposten reparert, utfør ett enkelt forsøk: avslutt hver klientinstans inkludert menylinjehjelperen, koble til én gang, og tell vinduene. Du vil ha nøkkelringgodkjenningen, hvis posten ble bygget opp igjen, og ett autentiseringstrinn. Ikke noe mer. scutil --nc status "Work VPN" bør rapportere Connected for en innebygd tjeneste.
Start deretter om én gang og gjenta. En forespørsel som bare kommer tilbake etter en omstart, peker på et påloggingselement eller en On Demand-regel, ikke på påloggingsinformasjon; en som kommer tilbake i økten, peker på ACL eller på en andre starter. Hvis den fortsatt gjentas etter begge gjennomgangene, er det nyttige å gi administratoren din tabellen med tre rader fra det første forsøket — eier, nøyaktig tekst, fase — ikke et skjermbilde av dialogen.
Færre forespørsler er målet, ikke tause. En tilkobling som skjuler autorisasjonstrinnene sine, er en tilkobling du ikke lenger kan revidere, og den neste sertifikatrotasjonen vil finne deg uten anelse om hvilken komponent som feiler.