Mac held fram å spørre etter VPN-passord: nøkkelring eller konto?
Macen kan be om passordet til påloggingsnøkkelringen, et administratorpassord eller selve VPN-kontoen. Les hvem dialogen tilhører, og reparer deretter riktig lager.
Du låser opp Macen, åpner VPN-klienten, og et passordark dukker opp før tunnelen i det hele tatt har startet. Du skriver inn gateway-passordet, og det blir enten avvist eller arket kommer tilbake et øyeblikk senere. Deretter spør den igjen etter oppvåkning fra dvale, utlogging eller en klientoppdatering. Det arket er sjelden VPN-serveren som ber om påloggingsinformasjon; som regel ber macOS om tillatelse til å lese, låse opp eller endre en lokal oppføring, og passordet tilhører eieren av den oppføringen, ikke VPN-kontoen din.
Match arket med identiteten bak det
Fire ledetekster ser nesten identiske ut, og bare én gjelder gatewayen. Ordlyden, prosessen som ber om tilgang og elementet som er navngitt nedenfor, forteller deg hvilken du står overfor.
| What the sheet says | Whose password it wants | What it does not do |
|---|---|---|
| Enter the password for the login keychain | The local keychain password, normally your Mac login password | It does not authenticate you to the VPN server |
| An app wants to use confidential information stored in your keychain | Approval for that app to retrieve one item | It does not grant privileges at the gateway |
| macOS wants to make changes, and asks for administrator authorization | An admin account on this Mac, for the named setting | It does not change the VPN account password |
| The client itself asks for a username and password to connect | The remote account, certificate or profile credential | It does not unlock anything local |
En dialog om lokal tilgang beviser ingenting om serveren. En avvisning fra gatewayen vises inne i klienten med leverandørens feiltekst, ikke som et systemark som tilbyr å låse opp en nøkkelring. Det motsatte er like vanlig: å skrive gateway-passordet i et nøkkelringsark lar oppføringen være låst og legger til et mislykket forsøk.
Dialogen navngir en eier, et lager og en handling
Nøkkelring-ledetekstene handler om henting, ikke om autentisering mot noe eksternt. Apples beskrivelse av forespørselsdialogen er snever: Tillat én gang, Tillat alltid og Avslå styrer om den appen kan lese det lagrede elementet. Ingen av de tre gir en rettighet på gatewayen eller endrer hva serveren mener om passordet ditt.
Når den som spør er en klient som nettopp er oppdatert, er ny godkjenning forventet: den nye versjonen samsvarer ikke lenger med tilgangskontrollisten på elementet, så macOS spør igjen. Svar Tillat én gang mens du feilsøker. Tillat alltid er en stående tillatelse til den appen og det gale svaret for en hjelpeprosess du ikke forventet; avslå og sjekk leverandøren hvis binærfila ikke er klienten du installerte.
En ledetekst som ber om administratorgodkjenning er en tredje type. Den navngir en systeminnstilling eller et beskyttet lager som endres, og påloggingsinformasjonen den vil ha er en administratorkonto på denne Macen. Ikke hvert personlige nøkkelringselement trenger det; de bak nettverkskonfigurasjonen trenger det vanligvis, fordi konfigurasjonen tilhører systemet, ikke økten din.
Hvor et VPN-passord på en Mac kan bo
Nøkkelringen er ett mulig lager, ikke definisjonen på et lager. En innebygd VPN-konfigurasjon opprettet i Systeminnstillinger oppbevarer påloggingsinformasjonen sammen med nettverkskonfigurasjonen, som en administrert systeminnstilling. En tredjepartsklient lagrer vanligvis et element i påloggingsnøkkelringen din: et generisk passord med nøkkel på et tjenestenavn eller et internettpassord med nøkkel på server, protokoll og konto. Mange nyere apper bruker i stedet databeskyttelsesnøkkelringen, hvis elementer aldri vises i Nøkkelringtilgang.
Folk søker etter VPN-navnet i Nøkkelringtilgang, finner ingenting og konkluderer med at passordet ikke er lagret. Apples TN3137-notat sier at det finnes mer enn én nøkkelringimplementasjon; fravær fra den listen er normalt, ikke bevis på et ødelagt element.
Oppføringstypene er heller ikke utskiftbare. Et kontopassord, en passfrase for en privat nøkkel, et klient sertifikat og en delt IPsec-hemmelighet feiler forskjellig og repareres på forskjellige steder; å skrive inn et lagret passord på nytt gjør ingenting for et avvist sertifikat. Hvis Macen er påmeldt administrasjon, er profilen en annen eier: en VPN-nyttelast kan bære påloggingsinformasjon og bruke den på nytt ved oppdatering, så sletting av et lokalt element er midlertidig til en administrator endrer det.
Når påloggingspassordet og nøkkelringpassordet glir fra hverandre
Påloggingsnøkkelringen bruker vanligvis Mac-innloggingspassordet ditt, og derfor kan de to gli fra hverandre. En administrator som tilbakestiller passordet ditt fra en annen konto, en gjenopprettingsflyt eller en katalogendring kan la nøkkelringen være låst til den gamle verdien, og macOS ber da om et passord du ikke nettopp har angitt.
Ved pålogging kan du se en advarsel om at systemet ikke kunne låse opp nøkkelringen. Oppdatering krever det gamle passordet, noe som er greit hvis du husker det og ubrukelig hvis du ikke gjør det. De to ærlige reparasjonene er Nøkkelringtilgang, Rediger, Endre passord for nøkkelring "login", eller en ny påloggingsnøkkelring med nødvendig påloggingsinformasjon skrevet inn på nytt. Det andre alternativet ødelegger lagrede elementer.
Ikke tilbakestill hele nøkkelringen fordi én VPN avviser en gammel påloggingsinformasjon: det fjerner urelaterte kontoer og identifiserer fortsatt ikke elementet.
Én kommando avgjør spørsmålet lokalt kontra eksternt. Spør nøkkelringen direkte om elementet:
security find-internet-password -s vpn.example.com -a [email protected] -g
security find-generic-password -s "Client Name" -a [email protected] -gBruk serveren og kontoen fra klientens innstillinger. Hvis det samme godkjenningsarket vises når du selv spør nøkkelringen, er ledeteksten lokal og serveren er en tilskuer. Hvis et slikt element ikke finnes, lagrer ikke klienten passordet der du antok. Flagget -g skriver hemmeligheten til terminalen, så unngå skjermdeling.
Oppdater oppføringen klienten faktisk leser
Hvis kontoen er endret på gatewayen, endre den der først, og oppdater deretter den lagrede oppføringen via klientens innstillinger. Å redigere et nøkkelringselement manuelt er upålitelig: klienten kan lese et annet tjeneste-og-konto-par, og en administrert profil overskriver endringen din.
For et element som mistenkes å være utdatert, match tjeneste, konto og protokoll før du sletter noe:
security delete-generic-password -s "Client Name" -a [email protected]Å slette et lignende navngitt element fra en annen tilkobling er et vanlig selvpåført avbrudd. Fjerning er bare lokalt: det tilbakekaller ikke en økt på gatewayen, løser ikke ut et enhetssertifikat og endrer ikke kontoens passord.
Bekreft at reparasjonen overlever en omstart
Koble til, våkn opp fra dvale, logg ut og inn igjen, og start deretter på nytt én gang. En ren sekvens uten ark og en klientstatus som navngir den forventede kontoen er det eneste beviset som teller. Hvor ledeteksten kommer tilbake forteller deg hvilket lag du gikk glipp av: etter en oppdatering er det godkjenning, etter en nettverksendring klientens egen ledetekst, etter en omstart en profil som bruker tilstanden på nytt.
Sjekk klienten for en innstilling om å huske passordet eller alltid spørre før du rører nøkkelringen igjen. Noen konfigurasjoner, særlig IKEv2 med autentisering per bruker, spør ved design ved hver tilkobling; nøkkelringreparasjon vil ikke hjelpe.
Skriv ned hvilket element du endret, hvilket lager som eide det og hvilken konto det tilhørte, slik at neste ledetekst kan plasseres på sekunder. Apples side Forespørsler om nøkkelringtilgang er referansen for hva de tre knappene godkjenner.