Mac vra aanhoudend na VPN-wagwoord: sleutelbos of rekening?
Die Mac kan na 'n aanmeld-sleutelboswagwoord, 'n administrateurwagwoord of die VPN-rekening self vra. Lees wie die dialoog stuur en maak dan die regte stoor reg.
Jy ontgrendel die Mac, maak die VPN-kliënt oop, en 'n wagwoordblad verskyn voordat die tonnel eers begin het. Jy tik die poortwagwoord, en dit word óf verwerp óf die blad kom 'n oomblik later terug. Dan vra dit weer ná 'n ontwaking uit die slaap, 'n afmelding of 'n kliëntopdatering. Daardie blad is selde die VPN-bediener wat om geloofsbriewe vra; gewoonlik vra macOS toestemming om 'n plaaslike rekord te lees, te ontsluit of te verander, en die wagwoord behoort aan daardie rekord se eienaar, nie aan jou VPN-rekening nie.
Pas die blad by die identiteit daar agter
Vier vrae lyk byna identies, en net een het met die poort te doen. Die bewoording, die proses wat toegang vra en die item wat daaronder genoem word, sê watter een jy voor het.
| 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 |
'n Dialoog oor plaaslike toegang bewys niks oor die bediener nie. 'n Weiering by die poort verskyn binne die kliënt met die verskaffer se foutteks, nie as 'n stelselblad wat aanbied om 'n sleutelbos te ontsluit nie. Die omgekeerde is net so algemeen: as jy die poortwagwoord in 'n sleutelbosblad tik, bly die rekord gesluit en kom daar 'n mislukte poging by.
Die dialoog noem 'n eienaar, 'n stoor en 'n aksie
Sleutelbosvrae gaan oor die ophaal van iets, nie oor verifikasie by iets op die netwerk nie. Apple se beskrywing van die versoekdialoog is eng: Laat een keer toe, Laat altyd toe en Weier beheer of daardie app die gestoorde item mag lees. Nie een van die drie gee 'n voorreg by die poort nie of verander wat die bediener van jou wagwoord dink nie.
Wanneer die versoeker 'n kliënt is wat pas opgedateer is, is hergoedkeuring te wagte: die nuwe weergawe pas nie meer by die toegangsbeheelys op die item nie, so macOS vra weer. Antwoord Laat een keer toe terwyl jy diagnose doen. Laat altyd toe is 'n staande toestemming aan daardie app en die verkeerde antwoord vir 'n hulpproses wat jy nie verwag het nie; weier en kyk by die verskaffer of die binêre lêer nie die kliënt is wat jy geïnstalleer het nie.
'n Vraag om administrateurmagtiging is 'n derde soort ding. Dit noem 'n stelselinstelling of 'n beskermde stoor wat verander word, en die geloofsbrief wat dit wil hê, is 'n administrateurrekening op hierdie Mac. Nie elke persoonlike sleutelbositem het dit nodig nie; dié agter netwerkkonfigurasie het dit gewoonlik wel, want die konfigurasie behoort aan die stelsel, nie aan jou aanmeldsessie nie.
Waar 'n Mac se VPN-wagwoord kan woon
Die sleutelbos is een moontlike stoor, nie die definisie van een nie. 'n Ingeboude VPN-konfigurasie wat in Stelselinstellings geskep is, hou sy geloofsbriewe by die netwerkkonfigurasie, as 'n bestuurde stelselinstelling. 'n Derde-party-kliënt hou gewoonlik 'n item in jou aanmeldsleutelbos: 'n generiese wagwoord wat deur 'n diensnaam gesleutel word, of 'n internetwagwoord wat deur bediener, protokol en rekening gesleutel word. Baie nuwer programme gebruik eerder die databeskermingsleutelbos, wie se items nooit in Sleutelbostoegang verskyn nie.
Mense soek in Sleutelbostoegang na die VPN-naam, vind niks en kom tot die gevolgtrekking dat die wagwoord nie gestoor is nie. Apple se TN3137-nota sê daar bestaan meer as een sleutelbosimplementering; afwesigheid uit daardie lys is normaal, nie bewys van 'n stukkende item nie.
Die rekordtipes is ook nie uitruilbaar nie. 'n Rekeningwagwoord, 'n privaatsleutel-wagfrase, 'n kliëntsertifikaat en 'n IPsec-gedeelde geheim faal anders en word op verskillende plekke herstel; om 'n gestoorde wagwoord weer te tik, doen niks vir 'n verwerpte sertifikaat nie. As die Mac by bestuur ingeskryf is, is die profiel nog 'n eienaar: 'n VPN-lading kan geloofsbriewe dra en hulle by hernuwing weer toepas, so die verwydering van 'n plaaslike item is tydelik totdat 'n administrateur dit verander.
Wanneer die aanmeldwagwoord en die sleutelboswagwoord uitmekaar dryf
Die aanmeldsleutelbos gebruik gewoonlik jou Mac-aanmeldwagwoord, en daarom kan die twee uitmekaar dryf. 'n Administrateur wat jou wagwoord vanaf 'n ander rekening herstel, 'n herstelproses of 'n gidsverandering kan die sleutelbos aan die ou waarde gesluit laat, en macOS vra dan na 'n wagwoord wat jy nie pas gestel het nie.
By aanmelding kan jy 'n waarskuwing sien dat die stelsel nie die sleutelbos kon ontsluit nie. Om dit op te dateer, is die ou wagwoord nodig, wat goed is as jy dit onthou en nutteloos as jy dit nie doen nie. Die twee eerlike herstellings is Sleutelbostoegang, Wysig, Verander wagwoord vir sleutelbos "login", of 'n nuwe aanmeldsleutelbos waarin jy die nodige geloofsbriewe weer invoer. Die tweede opsie vernietig gestoorde items.
Moenie die hele sleutelbos herstel net omdat een VPN 'n ou geloofsbrief verwerp nie: dit haal onverwante rekeninge uit en identifiseer steeds nie die item nie.
Een opdrag besleg die vraag plaaslik teenoor afgeleë. Vra die sleutelbos direk vir die item:
security find-internet-password -s vpn.example.com -a [email protected] -g
security find-generic-password -s "Client Name" -a [email protected] -gGebruik die bediener en rekening uit jou kliënt se instellings. As dieselfde goedkeuringsblad verskyn wanneer jy self die sleutelbos vra, is die vraag plaaslik en is die bediener 'n omstander. As geen sulke item bestaan nie, stoor die kliënt die wagwoord nie waar jy aanvaar het nie. Die -g-vlag druk die geheim na die terminaal, so vermy skermdeling.
Dateer die rekord op wat die kliënt werklik lees
As die rekening by die poort verander het, verander dit eers daar en dateer dan die gestoorde rekord deur die kliënt se instellings op. Om 'n sleutelbositem met die hand te redigeer, is onbetroubaar: die kliënt kan 'n ander diens-en-rekening-paar lees, en 'n bestuurde profiel sal jou wysiging oorskryf.
Vir 'n vermoedelik verouderde item, pas diens, rekening en protokol voor jy enigiets verwyder:
security delete-generic-password -s "Client Name" -a [email protected]Om 'n soortgelyk benoemde item van 'n ander verbinding te verwyder, is 'n algemene selfgeskepte onderbreking. Verwydering is net plaaslik: dit herroep nie 'n sessie by die poort nie, ontbind nie 'n toestelsertifikaat nie en verander nie die rekening se wagwoord nie.
Bevestig dat die regstelling 'n herlaai oorleef
Maak verbinding, wek uit die slaap, meld af en weer aan, en herlaai dan een keer. 'n Skoon reeks sonder 'n blad en 'n kliëntstatus wat die verwagte rekening noem, is die enigste bewys wat tel. Waar die vraag terugkom, sê watter laag jy gemis het: ná 'n opdatering is dit goedkeuring, ná 'n netwerkverandering die kliënt se eie vraag, ná 'n herlaai 'n profiel wat toestand weer toepas.
Kyk in die kliënt na 'n instelling om wagwoord te onthou of altyd te vra voordat jy weer aan die sleutelbos raak. Sommige konfigurasies, veral IKEv2 met per-gebruiker-verifikasie, vra volgens ontwerp by elke verbinding; sleutelbosherstel sal nie help nie.
Skryf neer watter item jy verander het, watter stoor dit besit het en aan watter rekening dit behoort het, sodat die volgende vraag binne sekondes geplaas kan word. Apple se bladsy oor sleutelbostoegangversoeke is die verwysing vir waarvoor daardie drie knoppies magtig.