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

Три способи отримати відмову, одне вікно

Неправильний секрет — лише перший шлях до цього вікна. Ім'я облікового запису може перетворитися на особу, якої ви не мали на увазі, обліковий запис може не мати дозволу на комутований доступ, або умова на сервері може відхилити з'єднання після прийняття пароля. Кожен із цих випадків дає той самий текст у клієнті, і кожен має власне виправлення.

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

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

Що клієнт насправді надіслав

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

Два запити лише для читання на машині Windows показують профіль і будь-які кешовані облікові дані, які могли б переважити діалог. Жоден із них не звертається до сервера:

Get-VpnConnection -Name 'Corp VPN' | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod
cmdkey /list | Select-String -Pattern 'corp' -SimpleMatch

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

Отримайте рішення політики, а не скидання

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

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

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

Спробуйте ще раз, потім порівняйте

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

Опіртеся спокусі вимкнути родину адрес або ввімкнути докладне трасування, доки відмову не пояснено. Трасування дає обсяг, а не рішення, і першим корисним результатом залишається компонент, який відхилив спробу, та причина, яку він записав. Коли це відомо, повторна спроба або підтверджує виправлення, або дає новий і вужчий симптом.

Схожі статті