Mac frågar ständigt efter VPN-lösenord: nyckelring eller konto?

Du låser upp Macen, öppnar VPN-klienten och ett lösenordsfönster dyker upp innan tunneln ens har startat. Du skriver in gateway-lösenordet och det avvisas, eller också kommer rutan tillbaka ett ögonblick senare. Sedan frågar den igen efter en väckning ur viloläge, en utloggning eller en klientuppdatering. Den rutan är sällan VPN-servern som ber om inloggningsuppgifter; oftast är det macOS som ber om tillstånd att läsa, låsa upp eller ändra en lokal post, och lösenordet tillhör postens ägare, inte ditt VPN-konto.

Matcha rutan mot identiteten bakom den

Fyra uppmaningar ser nästan identiska ut, och bara en gäller gatewayen. Formuleringen, processen som begär åtkomst och posten som namnges nedanför avgör vilken du står inför.

En dialog om lokal åtkomst bevisar ingenting om servern. Ett avvisande från gatewayen visas inne i klienten med leverantörens feltext, inte som en systemruta som erbjuder att låsa upp en nyckelring. Det omvända är lika vanligt: att skriva in gateway-lösenordet i en nyckelringsruta lämnar posten låst och lägger till ett misslyckat försök.

Dialogen namnger en ägare, ett lager och en åtgärd

Nyckelringsuppmaningar handlar om hämtning, inte om autentisering mot något fjärran. Apples beskrivning av förfrågningsdialogen är snäv: Tillåt en gång, Tillåt alltid och Neka styr om appen får läsa den lagrade posten. Ingen av de tre ger en behörighet i gatewayen eller ändrar vad servern anser om ditt lösenord.

När den som frågar är en klient som just uppdaterats är ett nytt godkännande väntat: det nya bygget matchar inte längre åtkomstkontrollistan på posten, så macOS frågar igen. Svara Tillåt en gång medan du felsöker. Tillåt alltid är ett stående medgivande till appen och fel svar för en hjälpprocess du inte väntade dig; avvisa och kontrollera leverantören om binären inte är den klient du installerade.

En uppmaning som ber om administratörsbehörighet är en tredje sorts företeelse. Den namnger en systeminställning eller ett skyddat lager som ändras, och uppgiften den vill ha är ett administratörskonto på den här Macen. Inte varje personlig nyckelringspost behöver det; de bakom nätverkskonfiguration brukar göra det, eftersom konfigurationen tillhör systemet och inte din inloggningssession.

Var ett VPN-lösenord på en Mac kan ligga

Nyckelringen är ett möjligt lager, inte definitionen av ett sådant. En inbyggd VPN-konfiguration som skapats i Systeminställningar behåller sina inloggningsuppgifter med nätverkskonfigurationen, som en hanterad systeminställning. En tredjepartsklient har oftast en post i din inloggningsnyckelring: ett generiskt lösenord som nycklas på ett tjänstenamn, eller ett internetlösenord som nycklas på server, protokoll och konto. Många nyare appar använder i stället den dataskyddade nyckelringen, vars poster aldrig syns i Nyckelringsåtkomst.

Folk söker i Nyckelringsåtkomst efter VPN-namnet, hittar inget och drar slutsatsen att lösenordet inte är sparat. Apples TN3137-not säger att det finns mer än en implementation av nyckelringar; att posten saknas i den listan är normalt, inte bevis på en trasig post.

Posttyperna är inte heller utbytbara. Ett kontolösenord, en lösenfras för en privat nyckel, ett klientcertifikat och en delad IPsec-hemlighet misslyckas på olika sätt och repareras på olika ställen; att skriva in ett sparat lösenord igen gör ingenting för ett avvisat certifikat. Om Macen är registrerad i hantering är profilen ytterligare en ägare: en VPN-profil kan bära inloggningsuppgifter och lägga tillbaka dem vid uppdatering, så att radera en lokal post är tillfälligt tills en administratör ändrar det.

När inloggningslösenordet och nyckelringslösenordet glider isär

Inloggningsnyckelringen använder normalt ditt inloggningslösenord till Macen, och därför kan de två glida isär. En administratör som återställer lösenordet från ett annat konto, ett återställningsflöde eller en katalogändring kan lämna nyckelringen låst till det gamla värdet, och då ber macOS om ett lösenord du inte nyss har satt.

Vid inloggning kan du se en varning om att systemet inte kunde låsa upp nyckelringen. Att uppdatera den kräver det gamla lösenordet, vilket är bra om du minns det och värdelöst om du inte gör det. De två ärliga reparationerna är Nyckelringsåtkomst, Redigera, Ändra lösenord för nyckelringen „login“, eller en ny inloggningsnyckelring där du anger de uppgifter du behöver på nytt. Det andra alternativet förstör lagrade poster.

Återställ inte hela nyckelringen bara för att en VPN avvisar en gammal uppgift: det slår ut orelaterade konton och identifierar fortfarande inte posten.

Ett kommando avgör frågan om lokalt kontra fjärran. Fråga nyckelringen direkt efter posten:

security find-internet-password -s vpn.example.com -a [email protected] -g
security find-generic-password -s "Client Name" -a [email protected] -g

Använd servern och kontot från klientens inställningar. Om samma godkännanderuta dyker upp när du frågar nyckelringen själv, är uppmaningen lokal och servern en åskådare. Om ingen sådan post finns lagrar klienten inte lösenordet där du antog. Flaggan -g skriver ut hemligheten i terminalen, så undvik skärmdelning.

Uppdatera den post som klienten faktiskt läser

Om kontot ändrades i gatewayen, ändra det där först och uppdatera sedan den lagrade posten via klientens inställningar. Att redigera en nyckelringspost för hand är opålitligt: klienten kan läsa ett annat tjänst-och-konto-par, och en hanterad profil skriver över din ändring.

För en misstänkt inaktuell post, matcha tjänst, konto och protokoll innan du raderar något:

security delete-generic-password -s "Client Name" -a [email protected]

Att radera en liknande post från en annan anslutning är ett vanligt självförvållat avbrott. Borttagning är bara lokal: den återkallar ingen session i gatewayen, frigör inget enhetscertifikat och ändrar inte kontots lösenord.

Bekräfta att åtgärden håller efter omstart

Anslut, väck ur viloläge, logga ut och in igen och starta sedan om en gång. En ren sekvens utan ruta och med klientstatus som namnger det förväntade kontot är det enda bevis som räknas. Var uppmaningen kommer tillbaka säger vilket lager du missade: efter en uppdatering är det godkännande, efter en nätverksändring klientens egen uppmaning, efter en omstart en profil som lägger tillbaka tillståndet.

Kontrollera klienten för en inställning för att komma ihåg lösenord eller alltid fråga innan du rör nyckelringen igen. Vissa konfigurationer, särskilt IKEv2 med autentisering per användare, frågar medvetet vid varje anslutning; nyckelringsreparation hjälper inte.

Skriv ner posten du ändrade, lagret som ägde den och kontot den tillhörde, så tar nästa uppmaning sekunder att placera. Apples sida om nyckelringsbegäranden är referensen för vad de tre knapparna auktoriserar.