Ошибка 691 VPN в Windows: какая проверка действительно не прошла?

Windows отклоняет пароль, который минуту назад принял в другом месте, поэтому учётная запись выглядит сломанной, хотя попытка вообще не оценивалась. Ошибка 691 означает, что соединение было отклонено во время проверки подлинности, и клиент показывает один и тот же текст независимо от того, был ли секрет неверным, разрешилось ли имя учётной записи в неожиданную личность или серверная политика отклонила соединение. Три разных исправления делят одно сообщение, поэтому сброс иногда помогает, а иногда вообще ничего не меняет. Начните с той части, которую можно проверить самостоятельно: точная строка, отправленная клиентом, и хранилище учётных данных, из которого она взята. Затем спросите сервер, какое решение он записал, потому что диалог — это отказ, а не диагноз.

Три способа получить отказ, одно окно

Неверный секрет — только первый путь к этому окну. Имя учётной записи может разрешиться в личность, которую вы не имели в виду, у учётной записи может не быть права на коммутируемый доступ, или условие на сервере может отклонить соединение после принятия пароля. Каждый из этих случаев даёт один и тот же текст в клиенте, и у каждого своё исправление.

Поэтому сброс в понедельник выглядит работающим, а во вторник не делает ничего. Читайте диалог как отказ, а не как диагноз, и запишите имя профиля и местное время сбоя, прежде чем трогать учётную запись.

Эти три категории дают сбой и на разных уровнях. Неверный секрет проваливает доказательство личности, неверная форма учётной записи проваливает поиск, а условие политики проваливает авторизацию после того, как личность доказана. Только первая исправляется сменой пароля. Двум другим нужен человек с доступом к журналу решений сервера, поэтому следующий шаг — запрос сведений, а не ещё один сброс.

Что клиент на самом деле отправил

Подтвердите принятый формат учётной записи у того, кто управляет шлюзом, потому что простое имя пользователя, имя с доменом и основное имя пользователя могут разрешаться в разные контексты учётной записи. Только одно из них может быть личностью, у которой есть разрешение. Спросите, какую форму ожидает шлюз, до первой попытки, а не после пятой, и проверьте, не использует ли клиент сохранённые учётные данные вместо введённых вами.

Два запроса только для чтения на машине Windows показывают профиль и любые кэшированные учётные данные, которые могли бы перевесить диалог. Ни один из них не обращается к серверу:

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

Относитесь к паролю как к данным, а не как к тексту, скопированному из документа. Значение, прошедшее через сценарий, может нести escape-символы, которые никогда не были частью секрета, а экспорт конфигурации мог заключить его в кавычки. Удаление всех специальных символов, чтобы оно подошло, — это другое изменение, чем поиск настоящего значения, поэтому сначала установите настоящее значение.

Получите решение политики, а не сброс

В развёртывании удалённого доступа с сервером сетевых политик два решения выполняются последовательно. Проверка подлинности устанавливает, какая учётная запись спрашивает, а авторизация решает, может ли эта учётная запись вообще подключаться. Условия и ограничения политики оцениваются по собственным правилам, поэтому верный секрет решает только первую половину вопроса. Имя политики в событии сервера указывает, какое решение действительно выполнялось.

Отправьте администратору имя профиля, испробованную учётную запись и отметку времени. Попросите соответствующую запись решения и её причину вместо очередного сброса пароля, а также имя политики, которое несёт событие. справочник кодов ошибок удалённого доступа Microsoft относит 691 к ошибкам учётных данных и проверки подлинности, и именно поэтому диалог не может различить три случая.

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

Попробуйте ещё раз, затем сравните

Повторите тот же профиль после единственного исправления, которое вы определили. Если доступ принят, а внутренний ресурс всё ещё недоступен, сбой перешёл на другой уровень и больше ничего не говорит о пароле. Именно неизменный профиль делает это сравнение осмысленным.

Сопротивляйтесь искушению отключить семейство адресов или включить подробную трассировку, пока отказ не объяснён. Трассировка даёт объём, а не решение, и первым полезным результатом остаётся компонент, отклонивший попытку, и причина, которую он записал. Когда это известно, повторная попытка либо подтверждает исправление, либо даёт новый и более узкий симптом.