Mac blijft om een VPN-wachtwoord vragen: sleutelhanger of account?

Je ontgrendelt de Mac, opent de VPN-client en er verschijnt een wachtwoordvenster voordat de tunnel zelfs maar is gestart. Je typt het gateway-wachtwoord en het wordt ofwel geweigerd, ofwel het venster komt even later terug. Daarna vraagt het opnieuw na ontwaken uit slaapstand, uitloggen of een clientupdate. Dat venster is zelden de VPN-server die om inloggegevens vraagt; meestal vraagt macOS om toestemming om een lokaal record te lezen, te ontgrendelen of te wijzigen, en het wachtwoord hoort bij de eigenaar van dat record, niet bij je VPN-account.

Koppel het venster aan de identiteit erachter

Vier prompts lijken bijna identiek en slechts één gaat over de gateway. De formulering, het proces dat toegang vraagt en het item dat eronder wordt genoemd, vertellen je welke je voor je hebt.

Een dialoog over lokale toegang bewijst niets over de server. Een weigering van de gateway verschijnt in de client met de fouttekst van de leverancier, niet als een systeemvenster dat aanbiedt een sleutelhanger te ontgrendelen. Het omgekeerde is even gewoon: het gateway-wachtwoord intoetsen in een sleutelhanger-venster laat het record vergrendeld en voegt een mislukte poging toe.

De dialoog noemt een eigenaar, een opslag en een actie

Sleutelhanger-prompts gaan over ophalen, niet over authenticatie bij iets externs. Apples beschrijving van het aanvraagvenster is smal: Sta één keer toe, Sta altijd toe en Weiger bepalen of die app het opgeslagen item mag lezen. Geen van de drie geeft een recht op de gateway of verandert wat de server van je wachtwoord denkt.

Wanneer de aanvrager een client is die net is bijgewerkt, is hernieuwde goedkeuring te verwachten: de nieuwe build komt niet meer overeen met de toegangsbeheerlijst van het item, dus macOS vraagt opnieuw. Antwoord Sta één keer toe tijdens het diagnosticeren. Sta altijd toe is een blijvende toestemming aan die app en het verkeerde antwoord voor een hulpproces dat je niet verwachtte; weiger en controleer de leverancier als het binaire bestand niet de client is die je hebt geïnstalleerd.

Een prompt die om beheerderstoestemming vraagt is een derde soort. Hij noemt een systeeminstelling of beveiligde opslag die wordt gewijzigd, en de inloggegevens die hij wil zijn een beheerdersaccount op deze Mac. Niet elk persoonlijk sleutelhanger-item heeft dat nodig; de items achter de netwerkconfiguratie meestal wel, omdat de configuratie bij het systeem hoort, niet bij je inlogsessie.

Waar een VPN-wachtwoord op een Mac kan leven

De sleutelhanger is één mogelijke opslag, niet de definitie van een opslag. Een ingebouwde VPN-configuratie die in Systeeminstellingen is gemaakt, bewaart de inloggegevens bij de netwerkconfiguratie, als een beheerde systeeminstelling. Een client van derden bewaart meestal een item in je inlogsleutelhanger: een generiek wachtwoord met sleutel op een servicenaam, of een internetwachtwoord met sleutel op server, protocol en account. Veel nieuwere apps gebruiken in plaats daarvan de gegevensbeschermingssleutelhanger, waarvan de items nooit in Sleutelhanger toegang verschijnen.

Mensen zoeken in Sleutelhanger toegang naar de VPN-naam, vinden niets en concluderen dat het wachtwoord niet is opgeslagen. Apples TN3137-notitie zegt dat er meer dan één sleutelhanger-implementatie bestaat; afwezigheid uit die lijst is normaal, geen bewijs van een kapot item.

De recordtypen zijn ook niet uitwisselbaar. Een accountwachtwoord, een wachtwoordzin voor een privésleutel, een clientcertificaat en een gedeeld IPsec-geheim falen anders en worden op verschillende plaatsen gerepareerd; een opgeslagen wachtwoord opnieuw intypen doet niets voor een geweigerd certificaat. Als de Mac in beheer is ingeschreven, is het profiel een andere eigenaar: een VPN-payload kan inloggegevens dragen en ze bij verversen opnieuw toepassen, dus het verwijderen van een lokaal item is tijdelijk tot een beheerder het wijzigt.

Wanneer het inlogwachtwoord en het sleutelhangerwachtwoord uit elkaar lopen

De inlogsleutelhanger gebruikt meestal je Mac-inlogwachtwoord, daarom kunnen de twee uit elkaar lopen. Een beheerder die je wachtwoord vanaf een ander account reset, een herstelproces of een adreswijziging kunnen de sleutelhanger vergrendeld laten op de oude waarde, en dan vraagt macOS om een wachtwoord dat je niet net hebt ingesteld.

Bij het inloggen kun je een waarschuwing zien dat het systeem de sleutelhanger niet kon ontgrendelen. Bijwerken vereist het oude wachtwoord, wat goed is als je het onthoudt en nutteloos als je dat niet doet. De twee eerlijke reparaties zijn Sleutelhanger toegang, Bewerk, Wijzig wachtwoord voor sleutelhanger "login", of een nieuwe inlogsleutelhanger met de benodigde inloggegevens opnieuw ingevoerd. De tweede optie vernietigt opgeslagen items.

Reset niet de hele sleutelhanger omdat één VPN een oude inloggegeven weigert: dat verwijdert ongerelateerde accounts en identificeert het item nog steeds niet.

Eén opdracht beslecht de vraag lokaal versus extern. Vraag de sleutelhanger rechtstreeks om het item:

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

Gebruik de server en het account uit de instellingen van je client. Als hetzelfde goedkeuringsvenster verschijnt wanneer je zelf de sleutelhanger vraagt, is de prompt lokaal en is de server toeschouwer. Bestaat zo'n item niet, dan bewaart de client het wachtwoord niet waar je aannam. De vlag -g drukt het geheim af in de terminal, dus vermijd scherm delen.

Werk het record bij dat de client echt leest

Als het account op de gateway is gewijzigd, wijzig het daar eerst en werk daarna het opgeslagen record bij via de instellingen van de client. Een sleutelhanger-item met de hand bewerken is onbetrouwbaar: de client leest mogelijk een ander service-en-account-paar, en een beheerd profiel overschrijft je bewerking.

Voor een vermoedelijk verouderd item: stem service, account en protocol af voordat je iets verwijdert:

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

Een vergelijkbaar genoemd item van een andere verbinding verwijderen is een veelvoorkomende zelf veroorzaakte storing. Verwijderen is alleen lokaal: het trekt geen sessie op de gateway in, maakt geen apparaatcertificaat los en wijzigt het wachtwoord van het account niet.

Bevestig dat de reparatie een herstart overleeft

Maak verbinding, word wakker uit slaapstand, log uit en weer in en herstart daarna één keer. Een schone reeks zonder venster en een clientstatus die het verwachte account noemt, is het enige bewijs dat telt. Waar de prompt terugkomt, zegt welke laag je hebt gemist: na een update is dat goedkeuring, na een netwerkwijziging de eigen prompt van de client, na een herstart een profiel dat de status opnieuw toepast.

Controleer de client op een instelling wachtwoord onthouden of altijd vragen voordat je de sleutelhanger weer aanraakt. Sommige configuraties, vooral IKEv2 met authenticatie per gebruiker, vragen by design bij elke verbinding; sleutelhangerreparatie helpt niet.

Noteer welk item je hebt gewijzigd, welke opslag het bezat en bij welk account het hoorde, zodat de volgende prompt binnen seconden te plaatsen is. Apples pagina Verzoeken om sleutelhanger toegang is de referentie voor wat die drie knoppen goedkeuren.