Ошибка подключения RDP по имени хоста, подключение RDP по IP-адресу работает.

Содержание

Вопрос или проблема
Ответ или решение
Проблема с подключением по RDP: не удаётся подключиться по имени хоста, но удаётся по IP-адресу
Введение
Анализ проблемы
Возможные причины
Заключение

Вопрос или проблема

У меня есть контроллер домена (DC02), которому 10 лет, и он был перенесен с VMware ESXi на Proxmox. DNS зоны показывают правильный IP-адрес.

RDP к хосту с IP-адресом работает.
RDP с использованием имени хоста W2022-DEV не работает и возвращает: “Удаленный компьютер, к которому вы пытаетесь подключиться, требует аутентификации на уровне сети (NLA), но ваш контроллер домена Windows не может быть контактирован для выполнения NLA.”

У меня есть еще одна DNS зона под названием ‘local’ в разделе Forward Lookup Zones. Я создал W2022-DEV там, и теперь RDP к W2022-DEV.local работает.

Есть идеи, что я настроил неправильно, чтобы это произошло?

NSLOOKUP W2022-DEV DC02 возвращает:

DNS запрос истек по времени.
    таймаут составил 2 секунды.
Сервер:   Неизвестно
Адрес:   192.168.111.24

DNS запрос истек по времени.
    таймаут составил 2 секунды.
*** Запрос к Неизвестно истек по времени

192.168.111.24 – это W2022-DEV.

Какие ОС вы используете, является ли DC старым? Они обновлены до последнего CU?

В powershell выполните Test-ComputerSecureChannel из VM, чтобы увидеть, подключен ли он полностью к AD
Возможно, вам придется настроить безопасность RDP во время устранения неполадок – я делаю это через GPO
https://i.sstatic.net/M1FgJ.png

Microsoft говорит, что причиной может быть:

VM не может взаимодействовать с контроллером домена (DC). Эта проблема может помешать RDP-сессии получить доступ к VM с использованием учетных данных домена. Однако вы все равно сможете войти, используя учетные данные локального администратора. Эта проблема может возникнуть в следующих ситуациях:
Канал безопасности Active Directory между этой VM и DC сломан. VM имеет старую копию пароля учетной записи, а DC имеет новую копию.
DC, к которому подключается эта VM, нестабилен.
Уровень шифрования VM выше, чем тот, который используется клиентским компьютером.
Протоколы TLS 1.0, 1.1 или 1.2 (сервер) отключены на VM. VM была настроена на отключение входа с использованием учетных данных домена, и локальный орган безопасности (LSA) неправильно настроен.
VM была настроена на прием только соединений с алгоритмами, соответствующими Федеральному стандарту обработки информации (FIPS). Обычно это делается с помощью политик Active Directory. Это редкая конфигурация, но FIPS может быть применен только к соединениям с удаленным рабочим столом.

Ответ или решение

Проблема с подключением по RDP: не удаётся подключиться по имени хоста, но удаётся по IP-адресу

Введение

Проблемы с подключением к виртуальным машинам (ВМ) через Remote Desktop Protocol (RDP) возникают довольно часто, особенно после перемещения серверов из одной среды виртуализации в другую. В данном случае вы столкнулись с ситуацией, когда подключение по имени хоста (W2022-DEV) не удаётся, тогда как доступ по IP-адресу (192.168.111.24) работает корректно. Рассмотрим возможные причины и пути решения данной проблемы.

Анализ проблемы

Давайте разберём ключевые аспекты описанной ситуации:

DNS-конфигурация: Вы переместили контроллер домена DC02 (находившийся ранее на VMware ESXi) на Proxmox и заметили, что имена в DNS-зоне отображают правильный IP-адрес. Однако команда nslookup W2022-DEV DC02 возвращает тайм-ауты. Это может указывать на проблемы с разрешением имен.
Работа с другими зонами DNS: Создание записи для W2022-DEV в зоне ‘local’ решает проблему – подключение осуществляется успешно. Это говорит о том, что контроллер домена или DNS-сервер не может корректно обрабатывать запросы к W2022-DEV.
Сообщение об ошибке RDP: Ошибка подключения указывает на проблемы с Network Level Authentication (NLA). Это может быть вызвано проблемами связи между ВМ и DC, которые препятствуют корректной аутентификации.

Возможные причины

Проблемы с DNS: Убедитесь, что ваши записи DNS актуальны и имеют правильное направление. Если контроллер DC02 не может разрешить имя W2022-DEV, это может привести к подобным проблемам.
Восстановление Secure Channel: Выполните команду Test-ComputerSecureChannel в PowerShell на ВМ, чтобы убедиться, что связь с Active Directory установлена. При необходимости, восстановите каналы безопасности.
Проблемы с NLA и политиками безопасности:
- Шифрование и протоколы: Проверьте настройки шифрования на ВМ и убедитесь, что они соответствуют требованиям DC. Возможно, шифрование VM выше, чем в клиенте.
- Настройки RDP: Для устранения проблемы временно измените параметры безопасности RDP через GPO. Рассмотрите возможность отключения NLA, чтобы изолировать проблему.
Состояние контроллера домена: Убедитесь, что ваш DC работает корректно и доступен. Проверьте состояние служб и целостность.
Настройки SSL/TLS: Убедитесь, что на ВМ не отключены протоколы TLS 1.0, 1.1 или 1.2, так как это может препятствовать установлению соединений.
Федеральные алгоритмы FIPS: Если на сервере W2022-DEV активирована поддержка только алгоритмов, соответствующих стандарту FIPS, проверьте, что это не препятствует выполнению RDP-подключений.

Заключение

Для диагностики и устранения проблемы с подключением по RDP вам следует в первую очередь проверить DNS-записи и упростить настройки безопасности RDP. Помимо этого, анализ состояния контроллера домена и тестирование безопасного канала являются важными шагами на пути к разрешению вашей проблемы. Убедитесь, что ваша сеть организована правильно и что все необходимые протоколы работают исправно. В случае необходимости привлеките дополнительную помощь для диагностики проблем в Active Directory.