Paulit-ulit na nagtatanong ng password ng VPN ang Mac: keychain o account?

Binubuksan mo ang Mac, binuksan ang VPN client, at may password sheet na lumitaw bago pa man magsimula ang tunnel. Itinatype mo ang password ng gateway, at alinman sa tinatanggihan ito o bumabalik ang sheet maya-maya. Pagkatapos ay nagtatanong muli ito pagkatapos ng paggising mula sa sleep, pag-logout, o pag-update ng client. Bihirang ang sheet na iyon ang VPN server na humihingi ng credentials; kadalasan ang macOS ang humihingi ng pahintulot na basahin, i-unlock o baguhin ang isang lokal na record, at ang password ay pag-aari ng may-ari ng record na iyon, hindi ng iyong VPN account.

Itugma ang sheet sa pagkakakilanlang nasa likod nito

Apat na prompt ang halos magkapareho, at isa lang ang tungkol sa gateway. Ang pananalita, ang prosesong humihingi ng access, at ang item na nakapangalan sa ibaba ang nagsasabi kung alin ang kaharap mo.

Walang pinapatunayan ang dialog tungkol sa lokal na access ukol sa server. Ang pagtanggi ng gateway ay lumilitaw sa loob ng client kasama ang text ng error ng vendor, hindi bilang system sheet na nag-aalok na i-unlock ang isang keychain. Kasingkaraniwan din ang kabaliktaran: ang pag-type ng password ng gateway sa isang keychain sheet ay nag-iiwan ng record na naka-lock at nagdaragdag ng isang bigong pagtatangka.

Pinapangalanan ng dialog ang isang may-ari, isang imbakan at isang aksyon

Ang mga prompt ng keychain ay tungkol sa pagkuha, hindi sa pagpapatotoo sa anumang malayo. Makitid ang paglalarawan ng Apple sa request dialog: ang Allow Once, Always Allow at Deny ay kumokontrol kung maaaring basahin ng app na iyon ang nakaimbak na item. Wala sa tatlo ang nagbibigay ng pribilehiyo sa gateway o nagbabago ng iniisip ng server tungkol sa iyong password.

Kapag ang humihingi ay isang client na karara lang nag-update, inaasahan ang muling pag-apruba: hindi na tumutugma ang bagong build sa access control list sa item, kaya muling nagtatanong ang macOS. Sumagot ng Allow Once habang nag-diagnose. Ang Always Allow ay isang panatag na pagpayag sa app na iyon at maling sagot para sa isang helper process na hindi mo inaasahan; tanggihan at suriin ang vendor kung ang binary ay hindi ang client na ininstalla mo.

Ang prompt na humihingi ng administrator authorization ay ibang uri. Pinapangalanan nito ang isang system setting o protektadong imbakan na binabago, at ang credential na hinihingi nito ay isang admin account sa Mac na ito. Hindi lahat ng personal na keychain item ay nangangailangan niyon; ang mga nasa likod ng network configuration ay karaniwang nangangailangan, dahil pag-aari ng system ang configuration, hindi ng iyong login session.

Saan maaaring manirahan ang password ng Mac VPN

Ang keychain ay isang posibleng imbakan, hindi ang kahulugan ng isang imbakan. Ang built-in na VPN configuration na ginawa sa System Settings ay nagtatabi ng mga credential nito kasama ng network configuration, bilang isang managed system setting. Ang third-party client ay karaniwang nagtatabi ng isang item sa iyong login keychain: isang generic password na naka-key sa isang service name, o isang internet password na naka-key sa server, protocol at account. Maraming mas bagong app ang gumagamit ng data-protection keychain sa halip, na ang mga item ay hindi kailanman lumilitaw sa Keychain Access.

Hinahanap ng mga tao ang pangalan ng VPN sa Keychain Access, walang mahanap, at hinuhusgahan na hindi naka-store ang password. Sinasabi ng note na TN3137 ng Apple na may higit sa isang implementasyon ng keychain; normal ang kawalan sa listahang iyon, hindi patunay ng sirang item.

Hindi rin mapagpapalit ang mga uri ng record. Ang account password, passphrase ng private key, client certificate at shared secret ng IPsec ay nabigo nang iba at kinukumpuni sa iba't ibang lugar; walang nagagawa ang muling pag-type ng naka-save na password para sa tinanggihang certificate. Kung ang Mac ay naka-enroll sa management, ibang may-ari ang profile: ang isang VPN profile ay maaaring magdala ng mga credential at muling ilapat ang mga ito kapag nag-refresh, kaya pansamantala lamang ang pagbura ng lokal na item hanggang baguhin ito ng administrator.

Kapag nagkahiwalay ang login password at ang keychain password

Ang login keychain ay karaniwang gumagamit ng iyong Mac login password, kaya nagkakahiwalay ang dalawa. Ang administrator na nagre-reset ng password mo mula sa ibang account, isang recovery flow, o pagbabago sa directory ay maaaring mag-iwan sa keychain na naka-lock sa lumang value, at pagkatapos ay humihingi ang macOS ng password na hindi mo lang itinakda.

Sa pag-login maaari kang makakita ng babala na hindi ma-unlock ng system ang keychain. Kailangan ng lumang password para i-update ito, na maayos kung natatandaan mo at walang silbi kung hindi. Ang dalawang tapat na pagkukumpuni ay Keychain Access, Edit, Change Password for Keychain “login”, o isang bagong login keychain kung saan muling ilalagay ang mga credential na kailangan mo. Sinisira ng pangalawang opsyon ang mga naka-store na item.

Huwag i-reset ang buong keychain dahil lang tinatanggihan ng isang VPN ang lumang credential: inaalis niyon ang mga walang kaugnayang account at hindi pa rin nakikilala ang item.

Isang command ang nagtatapos sa tanong na lokal laban sa malayo. Tanungin nang direkta ang keychain para sa item:

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

Gamitin ang server at account mula sa settings ng iyong client. Kung ang parehong approval sheet ay lumilitaw kapag ikaw mismo ang nagtanong sa keychain, lokal ang prompt at manonood lang ang server. Kung wala ang item na iyon, hindi iniimbak ng client ang password sa inaasahan mong lugar. Ang -g flag ay nagpi-print ng secret sa terminal, kaya iwasan ang screen sharing.

I-update ang record na aktuwal na binabasa ng client

Kung nagbago ang account sa gateway, baguhin muna doon, pagkatapos ay i-update ang naka-store na record sa pamamagitan ng settings ng client. Hindi mapagkakatiwalaan ang mano-manong pag-edit ng keychain item: maaaring ibang service-and-account pair ang basahin ng client, at papawiin ng managed profile ang edit mo.

Para sa pinaghihinalaang lumang item, itugma ang service, account at protocol bago magbura ng anuman:

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

Ang pagbura ng katulad ang pangalan na item mula sa ibang koneksyon ay karaniwang outage na ikaw mismo ang gumawa. Lokal lang ang pag-alis: hindi nito binabawi ang isang session sa gateway, hindi nag-aalis ng device certificate, at hindi nagbabago ng password ng account.

Kumpirmahin na tumatagal ang pagtatama kahit mag-reboot

Kumonekta, gumising mula sa sleep, mag-log out at pumasok muli, pagkatapos ay mag-reboot nang isang beses. Ang malinis na pagkakasunod-sunod na walang sheet at may status ng client na nagpapangalan sa inaasahang account ang tanging ebidensyang binibilang. Sinasabi ng lugar kung saan bumabalik ang prompt kung aling layer ang napalampas mo: pagkatapos ng update ito ay approval, pagkatapos ng pagbabago sa network ang sariling prompt ng client, pagkatapos ng reboot isang profile na muling naglalapat ng state.

Tingnan sa client ang setting na remember-password o always-ask bago mo muling hawakan ang keychain. Ang ilang configuration, lalo na ang IKEv2 na may per-user authentication, ay nagtatanong ayon sa disenyo sa bawat koneksyon; hindi makakatulong ang pagkukumpuni ng keychain.

Isulat ang item na binago mo, ang imbakang nagmamay-ari nito, at ang account na kinabibilangan nito, para ilang segundo lang ang susunod na prompt. Ang pahina ng Apple na Keychain access requests ang reference para sa kung ano ang pinapahintulutan ng tatlong button.