Mac непрекъснато иска парола за VPN: ключодържател или акаунт?
Mac може да иска парола за ключодържателя за вход, администраторска парола или самия VPN акаунт. Прочетете кой притежава диалога и поправете правилното хранилище.
Отключвате Mac, отваряте VPN клиента и лист за парола се появява още преди тунелът да е стартирал. Въвеждате паролата за шлюза и или я отхвърлят, или листът се връща след миг. След това пита отново след събуждане от сън, изход от системата или актуализация на клиента. Този лист рядко е VPN сървърът, който иска идентификационни данни; обикновено macOS иска разрешение да прочете, отключи или промени локален запис и паролата принадлежи на собственика на този запис, а не на вашия VPN акаунт.
Съпоставете листа с самоличността зад него
Четири подкани изглеждат почти еднакво и само една засяга шлюза. Формулировката, процесът, който иска достъп, и елементът, посочен отдолу, ви казват с коя се сблъсквате.
| 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 |
Диалог за локален достъп не доказва нищо за сървъра. Отказът от шлюза се появява в клиента с текста за грешка на доставчика, а не като системен лист, който предлага отключване на ключодържател. Обратното е също толкова често: въвеждането на паролата за шлюза в лист на ключодържател оставя записа заключен и добавя неуспешен опит.
Диалогът посочва собственик, хранилище и действие
Подканите на ключодържателя са за извличане, не за удостоверяване пред нещо отдалечено. Описанието на Apple за диалога за заявка е тясно: „Разреши веднъж“, „Винаги разрешавай“ и „Откажи“ управляват дали това приложение може да прочете съхранения елемент. Нито едно от трите не дава привилегия на шлюза, нито променя какво мисли сървърът за паролата ви.
Когато заявителят е клиент, който току-що се е обновил, повторното одобрение е очаквано: новата версия вече не съответства на списъка за контрол на достъпа на елемента, затова macOS пита отново. Отговаряйте „Разреши веднъж“, докато диагностицирате. „Винаги разрешавай“ е постоянно разрешение за това приложение и грешен отговор за помощен процес, който не сте очаквали; откажете и проверете доставчика, ако двоичният файл не е клиентът, който сте инсталирали.
Подкана за администраторско разрешение е трети вид. Тя посочва системна настройка или защитено хранилище, което се променя, и иска идентификационни данни за администраторски акаунт на този Mac. Не всеки личен елемент на ключодържателя се нуждае от това; тези зад мрежовата конфигурация обикновено да, защото конфигурацията принадлежи на системата, а не на вашата сесия за вход.
Къде може да живее VPN парола на Mac
Ключодържателят е едно възможно хранилище, не определението за такова. Вградена VPN конфигурация, създадена в „Системни настройки“, пази идентификационните си данни с мрежовата конфигурация като управлявана системна настройка. Клиент от трета страна обикновено пази елемент в ключодържателя за вход: обща парола с ключ по име на услуга или интернет парола с ключ по сървър, протокол и акаунт. Много по-нови приложения използват вместо това ключодържател за защита на данни, чиито елементи никога не се появяват в „Достъп до ключодържател“.
Хората търсят в „Достъп до ключодържател“ името на VPN, не намират нищо и заключават, че паролата не е съхранена. Бележката на Apple TN3137 казва, че съществува повече от една реализация на ключодържател; отсъствието от този списък е нормално, а не доказателство за повреден елемент.
Типовете записи също не са взаимозаменяеми. Парола за акаунт, парола за частен ключ, клиентски сертификат и споделена тайна за IPsec се провалят по различен начин и се поправят на различни места; повторното въвеждане на запазена парола не прави нищо за отхвърлен сертификат. Ако Mac е включен в управление, профилът е друг собственик: VPN товар може да носи идентификационни данни и да ги прилага отново при обновяване, така че изтриването на локален елемент е временно, докато администратор го промени.
Когато паролата за вход и паролата на ключодържателя се разминат
Ключодържателят за вход обикновено използва паролата ви за вход в Mac и затова двете могат да се разминат. Администратор, който нулира паролата ви от друг акаунт, процес за възстановяване или промяна в директорията могат да оставят ключодържателя заключен към старата стойност и тогава macOS иска парола, която току-що не сте задали.
При вход може да видите предупреждение, че системата не е успяла да отключи ключодържателя. Актуализирането му изисква старата парола, което е добре, ако я помните, и безполезно, ако не. Двете честни поправки са „Достъп до ключодържател“, „Редактиране“, „Промяна на паролата за ключодържател „login““, или нов ключодържател за вход с повторно въведени нужни идентификационни данни. Втората опция унищожава съхранените елементи.
Не нулирайте целия ключодържател, защото един VPN отхвърля стар идентификационен запис: това засяга несвързани акаунти и пак не установява кой е елементът.
Една команда решава въпроса локално срещу отдалечено. Попитайте ключодържателя директно за елемента:
security find-internet-password -s vpn.example.com -a [email protected] -g
security find-generic-password -s "Client Name" -a [email protected] -gИзползвайте сървъра и акаунта от настройките на клиента. Ако същият лист за одобрение се появи, когато сами попитате ключодържателя, подканата е локална и сървърът е страничен наблюдател. Ако такъв елемент не съществува, клиентът не пази паролата там, където предполагате. Флагът -g отпечатва тайната в терминала, затова избягвайте споделяне на екран.
Актуализирайте записа, който клиентът наистина чете
Ако акаунтът е променен на шлюза, променете го първо там, после актуализирайте съхранения запис през настройките на клиента. Ръчното редактиране на елемент на ключодържателя е ненадеждно: клиентът може да чете друга двойка услуга и акаунт, а управляван профил ще презапише редакцията ви.
За елемент, за който се подозира, че е остарял, съпоставете услуга, акаунт и протокол, преди да изтриете нещо:
security delete-generic-password -s "Client Name" -a [email protected]Изтриването на подобно именуван елемент от друга връзка е често самопричинено прекъсване. Премахването е само локално: то не отменя сесия на шлюза, не отвързва сертификат на устройство и не променя паролата на акаунта.
Потвърдете, че поправката оцелява след рестарт
Свържете се, събудете от сън, излезте и влезте отново, после рестартирайте веднъж. Чиста последователност без лист и статус на клиента с очаквания акаунт е единственото доказателство, което се брои. Мястото, където подканата се връща, ви казва кой слой сте пропуснали: след актуализация това е одобрението, след мрежова промяна — собствената подкана на клиента, след рестарт — профил, който прилага отново състояние.
Проверете клиента за настройка „запомни паролата“ или „винаги питай“, преди да пипате ключодържателя отново. Някои конфигурации, особено IKEv2 с удостоверяване за всеки потребител, питат по замисъл при всяко свързване; поправка на ключодържателя няма да помогне.
Запишете елемента, който сте променили, хранилището, което го е притежавало, и акаунта, към който е принадлежал, за да отнеме секунди следващата подкана да се постави. Страницата на Apple „Заявки за достъп до ключодържател“ е справката за това какво разрешават тези три бутона.