Varför din Mac-VPN frågar om Keychain-åtkomst varje gång
Kartlägg vilken komponent som utlöser varje Mac-VPN-fråga, stoppa dubbla anslutningsförsök och reparera Keychain-åtkomst utan att återställa hela nyckelringen.
Ett klick på Connect borde ge ett inloggningsfönster. På en Mac ger det ofta tre, och de delar sällan samma ägare: nyckelringen äger de lokala förfrågningarna om inloggningsuppgifter, VPN-gatewayen äger autentiseringen och klienten äger sina egna aviseringar. I stället för att leta efter en brytare som tystar allt, behandla varje fönster som en egen defekt med sin egen lösning. Guiden nedan går igenom ett medvetet anslutningsförsök och avslutas med en kontroll du kan upprepa.
Namnge ägaren till varje dialog innan du ändrar en inställning
Första steget är bokföring, inte konfiguration. Gör ett anslutningsförsök och skriv för varje fönster som dyker upp ned fyra fält: appnamnet i dialogen, den exakta texten utan något hemligt, fasen den dök upp i och vad som hände när du avbröt den. Tre sådana rader täcker nästan varje rapport jag har tittat på.
Ägarskap avgör rätt lösning, och fel lösning är oftast det som gör en förfrågan till 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 förfrågan som kommer tillbaka inom samma försök är en annan signal än en som kommer tillbaka vid nästa försök. Den första betyder oftast att anslutningen startades om under dig; den andra betyder oftast att sparade inloggningsuppgifter efterfrågas igen. Notera vilken du har innan du rör nyckelringen, för de två har nästan ingenting gemensamt.
Ta reda på hur många saker som startar tunneln
Fyra mekanismer kan starta samma VPN på en Mac: en menyradsåtgärd, ett inloggningsobjekt, en On Demand-regel och ett skript eller en agent. När två av dem utlöses kan den andra starten komma medan den första fortfarande väntar på autentisering, vilket ger ett dubbelt fönster och ingen framgång. Lista först vad som är konfigurerat: scutil --nc list skriver ut de VPN-tjänster som Systeminställningar känner till, med deras nuvarande status. Klienter som levererar sin egen nätverksutökning har profilerna i appen och visas kanske inte där, så kontrollera även klientens egen anslutningslista.
Leta sedan efter konkurrerande startare. scutil --nc show "Work VPN" skriver ut konfigurationsordboken för en inbyggd tjänst, inklusive On Demand-regler; en regel som återansluter vid varje gränssnittsändring startar om tunneln — och öppnar autentiseringsfrågan igen — varje gång Wi-Fi flyttar sig eller en skärm väcker nätverksstacken. Kontrollera inloggningsobjekt under Systeminställningar > Allmänt > Inloggningsobjekt och lista agenter per användare med ls ~/Library/LaunchAgents. Låt allt som ägs av en MDM-hanterad säkerhetsstack vara; borttagning skjuts oftast tillbaka vid nästa kontroll.
För att se vad som faktiskt körs under ett försök: ps -Ao pid,comm | grep -iE 'vpn|tunnel|extension'. Två klienthjälpare där du förväntar dig en förklarar "varför fick jag två förfrågningar" långt oftare än något inloggningsproblem.
Reparera nyckelringsåtkomst utan att återställa nyckelringen
Förfrågan kommer från den sparade postens åtkomstkontrollista, inte från VPN-protokollet. Varje post registrerar vilka program som får läsa den utan att fråga. Efter en klientuppdatering kan hjälparen som frågar ha ett annat namn eller en annan signatur medan posten fortfarande listar den gamla, så macOS frågar igen vid varje anslutning. Att godkänna den nya hjälparen för just den posten är hela lösningen; att godkänna varje program är det inte.
Du kan bekräfta att ACL är orsaken utan att röra VPN:en: security find-generic-password -s "service-name" -g läser samma post från en terminal. Om kommandot också utlöser förfrågan tillhör dialogen nyckelringen och tunneln är bara utlösaren. Apples vägledning om de tre knapparna — Tillåt en gång, Tillåt alltid, Neka — är värd en genomläsning, eftersom Neka är det som får förfrågan att komma tillbaka direkt i stället för vid nästa försök.
Om du godkände fel hjälpare, öppna posten i Nyckelringsåtkomst, byt till Åtkomstkontroll och ta bort posten; det är återrullningen. Att radera inloggningsnyckelringen, eller köra ett reparationsverktyg som bygger upp den igen, kastar också bort orelaterade lösenord och är en mycket större ändring än problemet.
Håll inloggnings- och policysteg i de flöden som äger dem
En webbläsarinloggning eller MFA-utmaning tillhör gatewayen. Om din organisation erbjuder sessionsbeständighet eller certifikatbaserad autentisering, använd den, eftersom det är det stödda sättet att autentisera mer sällan. Att skriva in en fast kod i en klient, eller lagra ett lösenord i ett skript så att förfrågan aldrig visas, ersätter en interaktiv faktor med en statisk hemlighet och misslyckas nästa gång policyn roteras.
Organisationsaviseringar är den enda kategorin du inte bör undertrycka. De genomdriver oftast en lägeskontroll eller ett godkännande av acceptabel användning, och att dölja dem kan sätta enheten ur efterlevnad även när tunneln fungerar. Feldialoger är den andra kategorin: behåll den första feltexten, eftersom en andra dialog ofta bara är samma fel rapporterat efter ett nytt försök.
Verifiera med ett försök, sedan efter en omstart
När dubbla startare är borttagna och nyckelringsposten reparerad, gör ett enda försök: avsluta varje klientinstans inklusive menyradshjälparen, anslut en gång och räkna fönstren. Du vill ha nyckelringens godkännande, om posten byggdes upp igen, och ett autentiseringssteg. Inget mer. scutil --nc status "Work VPN" bör rapportera Connected för en inbyggd tjänst.
Starta sedan om en gång och upprepa. En förfrågan som bara kommer tillbaka efter en omstart pekar på ett inloggningsobjekt eller en On Demand-regel, inte på inloggningsuppgifter; en som kommer tillbaka inom sessionen pekar på ACL eller på en andra startare. Om den fortfarande upprepas efter båda omgångarna är det användbara att ge din administratör tabellen med tre rader från det första försöket — ägare, exakt text, fas — inte en skärmbild av dialogen.
Färre förfrågningar är målet, inte tysta. En anslutning som döljer sina auktoriseringssteg är en anslutning du inte längre kan granska, och nästa certifikatrotation kommer att hitta dig utan en aning om vilken komponent som fallerar.