Как исправить ошибку «Удаленный компьютер требует выполнения проверки подлинности» при RDP-подключении?

← На главную

При работе в гетерогенных сетях, где соседствуют современные серверы (Windows Server 2012/2016/2019/2022) и классические рабочие станции или серверы на базе Windows XP или Windows Server 2003, системные администраторы часто сталкиваются с ошибкой: «Удаленный компьютер требует выполнения проверки подлинности при подключении». Эта проблема блокирует доступ к удаленному рабочему столу, даже если введены корректные учетные данные. Разберем детально причины возникновения этой ситуации и пошагово рассмотрим способы ее решения.

Выясняем причину: Что такое NLA и почему старые системы его «не любят»?

Основная причина кроется в технологии Network Level Authentication (NLA) — проверке подлинности на уровне сети. Рассмотрим принцип ее работы. В старых версиях протокола RDP соединение устанавливалось полностью, открывалось окно приветствия Windows, и только потом пользователь вводил пароль. Это создавало угрозу DoS-атак и позволяло злоумышленникам взаимодействовать с сервером еще до авторизации.

Технология NLA запрашивает учетные данные пользователя до создания полноценного сеанса RDP. Если клиент (тот, кто подключается) не поддерживает NLA или протокол CredSSP, сервер обрывает соединение с указанной ошибкой. В операционных системах Windows XP SP3 и Server 2003 поддержка NLA формально существует, но по умолчанию она часто отключена или требует обновления клиентского программного обеспечения.

Решение 1: Обновление RDP-клиента до версии 6.0 или выше

Самый простой и эффективный способ, который помог автору обсуждаемой темы, — это обновление версии клиента удаленного рабочего стола. Проанализируем, как это сделать и на что обратить внимание.

В старых системах, таких как Windows Server 2003, по умолчанию может быть установлен клиент версии 5.2. Чтобы успешно подключаться к современным серверам, нам необходимо обновить его до версии 6.0 или 7.0. После установки обновления mstsc.exe получит необходимые механизмы для работы с CredSSP.

Проверим текущую версию клиента. Для этого запустим mstsc.exe, нажмем правой кнопкой мыши на заголовок окна (или на иконку в левом верхнем углу) и выберем пункт «О программе». Если в появившемся окне отсутствует строка «Поддержка проверки подлинности на уровне сети: поддерживается», значит, клиент нуждается в доработке или обновлении.

Решение 2: Активация CredSSP через реестр Windows

Иногда простого обновления клиента недостаточно, и систему нужно «подтолкнуть» к использованию новых протоколов безопасности. Рассмотрим, как вручную активировать поддержку CredSSP в операционных системах Windows XP SP3 или Server 2003 R2.

Разберем последовательность действий в редакторе реестра:

Нажмем Пуск — Выполнить, введем regedit и нажмем Enter.
Перейдем в ветку: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
Найдем мультистроковый параметр Security Packages. Добавим в список значений (в новую строку) слово tspkg. При этом крайне важно сохранить все уже имеющиеся там значения (например, kerberos, msv1_0 и другие).
Теперь перейдем в ветку: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders.
Найдем параметр SecurityProviders и добавим в конец через запятую (или в список) значение credssp.dll.
Важный момент: после внесения изменений в реестр необходимо обязательно перезагрузить компьютер, чтобы новые провайдеры безопасности инициализировались системой.

Решение 3: Снижение уровня безопасности на стороне целевого сервера

Если по каким-то причинам мы не можем обновить клиентскую часть (например, используется специализированное оборудование или тонкие клиенты), нам придется изменить настройки на самом сервере, к которому мы подключаемся. Выясним, как разрешить подключения без NLA.

Рассмотрим настройку через свойства системы:

На сервере откроем Панель управления — Система (или нажмем Win+Pause).
Перейдем в раздел «Настройка удаленного доступа».
В блоке «Удаленный рабочий стол» найдем пункт «Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети (рекомендуется)».
Снимем галочку с этого пункта и нажмем «Применить».

Внимание: это действие несколько снижает уровень безопасности сервера, так как позволяет старым клиентам инициировать соединение. Однако в закрытых локальных сетях это допустимый компромисс для обеспечения совместимости.

Решение 4: Настройка групповых политик для обхода ошибок CredSSP

Проанализируем еще одну ситуацию: ошибка «Encryption Oracle Remediation» (Исправление шифрующего оракула). Это специфическая проблема, возникшая после обновлений безопасности Microsoft в 2018 году. Если сервер обновлен, а клиент — нет, проверка подлинности не пройдет.

Если мы столкнулись именно с этой проблемой, выполним следующие шаги в редакторе групповых политик (gpedit.msc):

Перейдем по пути: Конфигурация компьютера — Административные шаблоны — Система — Передача учетных данных.
Найдем параметр «Исправление уязвимости шифрующего оракула» (Encryption Oracle Remediation).
Установим значение «Включено», а в параметрах выберем уровень защиты «Оставить уязвимость» (Vulnerable).

Это позволит установить соединение даже в том случае, если на одной из сторон отсутствует патч безопасности. После установления связи настоятельно рекомендуем обновить обе операционные системы до актуального состояния.

Резюме

Подводя итог, мы видим, что проблема «проверки подлинности» всегда связана с несоответствием протоколов безопасности между старым клиентом и новым сервером. В большинстве случаев достаточно обновить клиент RDP до версии 6.0/7.0 и, при необходимости, включить поддержку CredSSP в реестре. Если же доступ нужен «здесь и сейчас», временным решением станет отключение требования NLA в настройках удаленного доступа на стороне сервера.