Mac bliver ved med at spørge efter VPN-adgangskode: nøglering eller konto?
Mac'en kan bede om adgangskoden til login-nøgleringen, en admin-adgangskode eller selve VPN-kontoen. Læs, hvem dialogen tilhører, og reparér derefter det rigtige lager.
Du låser Mac'en op, åbner VPN-klienten, og et adgangskodeark dukker op, før tunnelen overhovedet er startet. Du skriver gatewayens adgangskode, og den bliver enten afvist, eller arket kommer tilbage et øjeblik senere. Derefter spørger den igen efter en opvågning fra dvale, en logud eller en klientopdatering. Det ark er sjældent VPN-serveren, der beder om legitimationsoplysninger; som regel beder macOS om tilladelse til at læse, låse op for eller ændre en lokal post, og adgangskoden tilhører den posts ejer, ikke din VPN-konto.
Match arket med identiteten bag det
Fire prompts ser næsten identiske ud, og kun én vedrører gatewayen. Formuleringen, processen der anmoder om adgang, og elementet nævnt nedenunder fortæller dig, hvilken du står over for.
| 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 adgang beviser intet om serveren. En afvisning fra gatewayen vises inde i klienten med leverandørens fejltekst, ikke som et systemark, der tilbyder at låse en nøglering op. Det omvendte er lige så almindeligt: at skrive gatewayens adgangskode i et nøgleringeark efterlader posten låst og tilføjer et mislykket forsøg.
Dialogen navngiver en ejer, et lager og en handling
Nøgleringeprompts handler om at hente, ikke om godkendelse over for noget eksternt. Apples beskrivelse af anmodningsdialogen er snæver: Tillad én gang, Tillad altid og Afvis styrer, om den app må læse det gemte element. Ingen af de tre giver en rettighed på gatewayen eller ændrer, hvad serveren mener om din adgangskode.
Når anmoderen er en klient, der netop er opdateret, er ny godkendelse forventet: det nye build matcher ikke længere adgangskontrollisten på elementet, så macOS spørger igen. Svar Tillad én gang, mens du diagnosticerer. Tillad altid er en stående tilladelse til den app og det forkerte svar for en hjælpeproces, du ikke forventede; afvis, og tjek leverandøren, hvis binæren ikke er den klient, du installerede.
En prompt, der beder om administratorgodkendelse, er en tredje slags. Den navngiver en systemindstilling eller et beskyttet lager, der ændres, og den legitimation, den vil have, er en administratorkonto på denne Mac. Ikke hvert personligt nøgleringeelement har brug for det; dem bag netværkskonfiguration har normalt, fordi konfigurationen tilhører systemet, ikke din login-session.
Hvor en VPN-adgangskode på en Mac kan bo
Nøgleringen er ét muligt lager, ikke definitionen på et lager. En indbygget VPN-konfiguration oprettet i Systemindstillinger gemmer sine legitimationsoplysninger sammen med netværkskonfigurationen som en administreret systemindstilling. En tredjepartsklient gemmer normalt et element i din login-nøglering: en generisk adgangskode med nøgle på et tjenestenavn eller en internetadgangskode med nøgle på server, protokol og konto. Mange nyere apps bruger i stedet databeskyttelsesnøgleringen, hvis elementer aldrig vises i Nøgleordsadgang.
Folk søger efter VPN-navnet i Nøgleordsadgang, finder intet og konkluderer, at adgangskoden ikke er gemt. Apples TN3137-note siger, at der findes mere end én nøglering-implementering; fravær fra den liste er normalt, ikke bevis på et ødelagt element.
Posttyperne er heller ikke udskiftelige. En kontoadgangskode, en adgangssætning til en privat nøgle, et klientcertifikat og en delt IPsec-hemmelighed fejler forskelligt og repareres forskellige steder; at skrive en gemt adgangskode igen gør intet for et afvist certifikat. Hvis Mac'en er tilmeldt styring, er profilen en anden ejer: en VPN-nyttelast kan bære legitimationsoplysninger og anvende dem igen ved opdatering, så sletning af et lokalt element er midlertidig, indtil en administrator ændrer det.
Når login-adgangskoden og nøgleringens adgangskode glider fra hinanden
Login-nøgleringen bruger normalt din Mac-login-adgangskode, og derfor kan de to glide fra hinanden. En administrator, der nulstiller din adgangskode fra en anden konto, et gendannelsesforløb eller en ændring i en mappe kan efterlade nøgleringen låst til den gamle værdi, og macOS beder så om en adgangskode, du ikke lige har angivet.
Ved login kan du se en advarsel om, at systemet ikke kunne låse nøgleringen op. Opdatering kræver den gamle adgangskode, hvilket er fint, hvis du husker den, og ubrugeligt, hvis du ikke gør. De to ærlige reparationer er Nøgleordsadgang, Rediger, Skift adgangskode for nøglering "login", eller en ny login-nøglering med de nødvendige legitimationsoplysninger indtastet igen. Den anden mulighed ødelægger gemte elementer.
Nulstil ikke hele nøgleringen, fordi én VPN afviser en gammel legimitation: det fjerner urelaterede konti og identificerer stadig ikke elementet.
Én kommando afgør spørgsmålet lokalt kontra eksternt. Spørg nøgleringen 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] -gBrug serveren og kontoen fra klientens indstillinger. Hvis det samme godkendelsesark vises, når du selv spørger nøgleringen, er prompten lokal, og serveren er en tilskuer. Hvis der ikke findes et sådant element, gemmer klienten ikke adgangskoden, hvor du antog. Flaget -g udskriver hemmeligheden til terminalen, så undgå skærmdeling.
Opdater den post, klienten faktisk læser
Hvis kontoen er ændret på gatewayen, ændr den der først, og opdater derefter den gemte post via klientens indstillinger. Det er upålideligt at redigere et nøgleringeelement i hånden: klienten kan læse et andet tjeneste-og-konto-par, og en administreret profil overskriver din ændring.
For et formodet forældet element skal du matche tjeneste, konto og protokol, før du sletter noget:
security delete-generic-password -s "Client Name" -a [email protected]At slette et lignende navngivet element fra en anden forbindelse er et almindeligt selvpåført nedbrud. Fjernelse er kun lokal: det tilbagekalder ikke en session på gatewayen, frigør ikke et enhedscertifikat eller ændrer kontos adgangskode.
Bekræft, at reparationen overlever en genstart
Opret forbindelse, vågn fra dvale, log ud og ind igen, og genstart derefter én gang. Et rent forløb uden ark og en klientstatus, der nævner den forventede konto, er det eneste bevis, der tæller. Stedet, hvor prompten vender tilbage, fortæller dig, hvilket lag du missede: efter en opdatering er det godkendelse, efter en netværksændring klientens egen prompt, efter en genstart en profil, der genanvender tilstand.
Tjek klienten for en indstilling om at huske adgangskoden eller altid spørge, før du igen rører nøgleringen. Nogle konfigurationer, især IKEv2 med godkendelse per bruger, spørger efter design ved hver forbindelse; nøgleringereparation hjælper ikke.
Skriv ned, hvilket element du ændrede, hvilket lager der ejede det, og hvilken konto det tilhørte, så den næste prompt kan placeres på sekunder. Apples side Anmodninger om nøgleordsadgang er reference for, hvad de tre knapper godkender.