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 Запити доступу до зв'язки ключів — це довідка про те, що авторизують ті три кнопки.