Waarom je Mac-VPN elke keer Keychain-toegang vraagt
Bepaal welk onderdeel elke Mac-VPN-melding veroorzaakt, stop dubbele verbindingspogingen en herstel Keychain-toegang zonder de hele sleutelhanger te resetten.
Eén klik op Connect zou één inlogvenster moeten opleveren. Op een Mac levert het er vaak drie op, en ze delen zelden dezelfde eigenaar: de sleutelhanger bezit de lokale verzoeken om inloggegevens, de VPN-gateway bezit de authenticatie, en de client bezit zijn eigen meldingen. In plaats van te zoeken naar een schakelaar die alles stil maakt, behandelt u elk venster als een apart defect met zijn eigen oplossing. De onderstaande handleiding doorloopt één bewuste verbindingspoging en eindigt met een controle die u kunt herhalen.
Benoem de eigenaar van elk dialoogvenster voordat u een instelling wijzigt
De eerste stap is boekhouding, niet configuratie. Doe één verbindingspoging en noteer voor elk venster dat verschijnt vier velden: de appnaam in het dialoogvenster, de exacte tekst zonder iets geheims, de fase waarin het verscheen, en wat er gebeurde toen u het annuleerde. Drie zulke rijen dekken bijna elk rapport dat ik heb bekeken.
Eigenaarschap bepaalt de juiste oplossing, en de verkeerde oplossing is meestal wat één melding er drie maakt:
| 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 |
Een melding die binnen dezelfde poging terugkomt is een ander signaal dan een die bij de volgende poging terugkomt. De eerste betekent meestal dat de verbinding onder u opnieuw is gestart; de tweede betekent meestal dat er opnieuw om opgeslagen inloggegevens wordt gevraagd. Noteer welke u hebt voordat u de sleutelhanger aanraakt, want de twee hebben bijna niets gemeen.
Zoek uit hoeveel dingen de tunnel starten
Vier mechanismen kunnen dezelfde VPN op een Mac starten: een menubalkactie, een inlogitem, een On Demand-regel en een script of agent. Wanneer twee ervan afgaan, kan de tweede start aankomen terwijl de eerste nog op authenticatie wacht, wat een dubbel venster en geen voortgang oplevert. Maak eerst een lijst van wat is geconfigureerd: scutil --nc list drukt de VPN-diensten af die Systeeminstellingen kent, met hun huidige status. Clients die hun eigen netwerkextensie meeleveren, houden profielen in de app en verschijnen daar mogelijk niet, dus controleer ook de eigen verbindingslijst van de client.
Zoek dan naar concurrerende starters. scutil --nc show "Work VPN" drukt het configuratiewoordenboek van een ingebouwde dienst af, inclusief On Demand-regels; een regel die bij elke interfacewijziging opnieuw verbindt, herstart de tunnel — en opent de authenticatiemelding opnieuw — elke keer dat Wi-Fi beweegt of een scherm de netwerkstack wekt. Controleer inlogitems onder Systeeminstellingen > Algemeen > Inlogitems, en lijst per-gebruikeragents op met ls ~/Library/LaunchAgents. Laat alles met rust dat eigendom is van een door MDM beheerde beveiligingsstack; verwijderen wordt bij de volgende controle meestal teruggedraaid.
Om te zien wat er tijdens een poging echt draait: ps -Ao pid,comm | grep -iE 'vpn|tunnel|extension'. Twee clienthelpers waar u er één verwacht, verklaren "waarom kreeg ik twee meldingen" veel vaker dan welk inloggegevensprobleem dan ook.
Herstel sleutelhanger-toegang zonder de sleutelhanger te resetten
De melding komt van de toegangsbeheerlijst van het opgeslagen item, niet van het VPN-protocol. Elk item legt vast welke apps het zonder vragen mogen lezen. Na een clientupdate kan de helper die vraagt een andere naam of handtekening hebben terwijl het item nog de oude vermeldt, dus vraagt macOS bij elke verbinding opnieuw. De nieuwe helper voor dat ene item goedkeuren is de hele oplossing; elke app goedkeuren niet.
U kunt bevestigen dat de ACL de oorzaak is zonder de VPN aan te raken: security find-generic-password -s "service-name" -g leest hetzelfde item uit een terminal. Als dat commando de melding ook oproept, hoort het dialoogvenster bij de sleutelhanger en is de tunnel alleen de trigger. Apple's richtlijnen over de drie knoppen — Eenmalig toestaan, Altijd toestaan, Weigeren — zijn één keer lezen waard, want Weigeren is wat de melding meteen laat terugkomen in plaats van bij de volgende poging.
Als u de verkeerde helper hebt goedgekeurd, opent u het item in Sleutelhanger-toegang, schakelt u naar Toegangsbeheer en verwijdert u dat item; dat is de terugdraaiing. Het inlogsleutelhanger verwijderen, of een reparatiehulpmiddel draaien dat hem opnieuw opbouwt, gooit ook niet-gerelateerde wachtwoorden weg en is een veel grotere wijziging dan het probleem.
Houd inlog- en beleidsstappen in de stromen die ze bezitten
Een browserlogin of MFA-uitdaging hoort bij de gateway. Als uw organisatie sessiepersistentie of certificaatgebaseerde authenticatie biedt, gebruik dat, want dat is de ondersteunde manier om minder vaak te authenticeren. Een vaste code in een client typen, of een wachtwoord in een script opslaan zodat de melding nooit verschijnt, vervangt een interactieve factor door een statisch geheim en mislukt de volgende keer dat het beleid roteert.
Organisatiemeldingen zijn de enige categorie die u niet moet onderdrukken. Ze dwingen meestal een postuurcontrole of een bevestiging van acceptabel gebruik af, en ze verbergen kan het apparaat buiten compliance brengen, zelfs terwijl de tunnel werkt. Foutdialoogvensters zijn de andere categorie: bewaar de eerste fouttekst, want een tweede dialoogvenster is vaak alleen dezelfde fout die na een nieuwe poging wordt gemeld.
Verifieer met één poging, en daarna na een herstart
Met dubbele starters verwijderd en het sleutelhangeritem hersteld, doet u één poging: sluit elk clientexemplaar inclusief de menubalkhelper, maak één keer verbinding en tel de vensters. U wilt de sleutelhanger goedkeuring, als het item opnieuw is opgebouwd, en één authenticatiestap. Niets meer. scutil --nc status "Work VPN" zou Connected moeten melden voor een ingebouwde dienst.
Herstart dan één keer en herhaal. Een melding die alleen na een herstart terugkomt, wijst op een inlogitem of een On Demand-regel, niet op inloggegevens; een die binnen de sessie terugkomt, wijst op de ACL of op een tweede starter. Als het na beide rondes nog steeds terugkomt, is het nuttige dat u uw beheerder kunt geven de tabel met drie rijen van de eerste poging — eigenaar, exacte tekst, fase — niet een schermafbeelding van het dialoogvenster.
Minder meldingen is het doel, niet stille. Een verbinding die zijn autorisatiestappen verbergt, is een verbinding die u niet meer kunt auditen, en de volgende certificaatrotatie treft u zonder idee welk onderdeel faalt.