У якій телефонній книзі завдання SYSTEM шукає профілі VPN?

Ваш профіль VPN розташований просто в Параметрах, а заплановане завдання досі повідомляє, що не може знайти з'єднання. Нічого не пошкоджено: власне сховище VPN у Windows прив'язане до користувача, якщо профіль не створено як профіль для всіх користувачів, а завдання виконується від імені того облікового запису, який називає його principal. Зазвичай завдання читає телефонну книгу, у якій вашого профілю ніколи не було. Двох команд і одного налаштування завдання достатньо, щоб це довести, і їх варто виконати, перш ніж хтось перебудує з'єднання.

Два сховища зберігають однакове ім'я профілю

Власний профіль VPN у Windows живе в сховищі того облікового запису, який його створив. Глобальне сховище — це інша телефонна книга, яка заповнюється лише тоді, коли профіль створено з перемикачем для всіх користувачів у сеансі з підвищеними правами. Обидва можуть зберігати профіль з однаковим ім'ям, і жодне не є поданням іншого.

Прочитайте обидва сховища в одному сеансі й порівняйте імена, які вони повертають. Перемикач вибирає глобальне сховище, і для його читання зазвичай потрібен сеанс з підвищеними правами:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType

Якщо перша команда перелічує профіль, а друга ні, жодна зміна облікових даних не допоможе завданню, що виконується від імені іншого облікового запису, бо проблема — членство, а не автентифікація. Якщо обидві перелічують його, сховище не є причиною і застосовується наступний розділ. Це єдине порівняння закриває половину таких звернень. Запишіть, яке сховище відповіло і від імені якого облікового запису ви виконували перевірку, бо відповідь без обох фактів безглузда.

Прочитайте principal завдання до його облікових даних

Відкрийте завдання й прочитайте principal, бо він указує, яке сховище бачить завдання. Завдання, налаштоване на виконання як SYSTEM, — це не ваш обліковий запис із додатковими правами: у нього власний профіль і немає доступу до телефонної книги конкретного користувача, яку ви створили, увійшовши в систему. Службовий обліковий запис поводиться точно так само.

Параметр запуску незалежно від входу в систему також це змінює, бо тоді завдання не має інтерактивного сеансу, чиї облікові дані можна було б позичити. Нехай дія запише whoami у файл, а відповідь прочитайте, замість того щоб припускати її.

Діагностика з вашого власного термінала нічого не каже про цю проблему, бо показує те, що бачить ваш обліковий запис. Виконайте порівняння від імені завдання через будь-яку затверджену процедуру, яка у вас для цього є. Вивід, вставлений з консолі адміністратора, — це інший набір даних, а не більш привілейований. Якщо такої процедури немає, завдання має саме записати відповідь, що й налаштовує останній розділ.

Знайти профіль — це не увійти в систему

Профіль для всіх користувачів робить конфігурацію ширше видимою. Він не переносить збережений пароль з облікового запису, що його створив, і не передає іншому обліковому запису закритий ключ, збережений у вашому профілі користувача. Видимість і придатні облікові дані — два окремі тести, і проходження першого нічого не каже про другий.

Якщо завдання тепер знаходить профіль і не проходить автентифікацію, це прогрес, і цей етап належить запису. Перенесіть сертифікат у сховище комп'ютера або передайте секрет через власний механізм розгортання, замість того щоб знову створювати ім'я з'єднання. Повторне створення дає ту саму помилку з новішою позначкою часу. Microsoft документує обидві області , між якими вибирає перемикач cmdlet.

Неінтерактивні запити — це пастка за цим етапом. На запит PIN або одноразовий код завдання без робочого столу відповісти не може, тому профіль, який вручну підключається бездоганно, під автоматизацією може бути непридатним.

Чотири поля, які потрібні запису завдання

Тримайте значення, що визначають результат, разом в одному місці, бо три з них зазвичай залишаються неявними. Запису потрібні чотири рядки:

• Шлях дії: сценарій або виконуваний файл, який запускає завдання, а не ярлик, що для іншого облікового запису розв'язується інакше.
• Ім'я профілю: точний рядок, бо два сховища можуть зберігати однакове ім'я, що вказує на різні сервери.
• Principal: обліковий запис, від імені якого виконується завдання, і чи має він інтерактивний сеанс.
• Метод автентифікації: що цей principal справді може завершити, наприклад сертифікат зі сховища комп'ютера, а не ключ у вашому профілі користувача.

Ці чотири рядки відповідають на питання, яке звернення насправді ставить: яку конфігурацію використала автоматизація. Вони також переживуть наступну перебудову завдання, коли початкового автора немає поруч, щоб пояснити, чому ім'я мало значення. Без них та сама помилка повертається після наступного розгортання і знову коштує тих самих годин.

Визначте етап, до якого дійшло завдання

Інструментуйте дію, замість того щоб гадати за результатом останнього запуску. Коротка обгортка записує в одному місці ідентичність, видиме сховище й результат додзвону:

whoami
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress
rasdial "Office"
schtasks /query /tn "VPN Connect" /v /fo LIST

Команда додзвону друкує власну помилку, яка зазвичай ясніша за загальний збій завдання. Запит повертає principal і останній код результату поруч, тож ідентичність і результат видно в одному поданні. Ці два факти вирішують, чи наступний крок — зміна сховища, чи зміна облікових даних.

Нарешті, відокремте завдання, що підключається після входу користувача, від тунелю пристрою або підтримуваного сценарію до входу в систему. Спільне використання одного профілю не є проєктом ні для одного з них, і саме поле principal каже, який із трьох випадків ви побудували. Якщо з'єднання має існувати до входу в систему, сховище профілів конкретного користувача — не той рівень, який треба виправляти.