Столкнулся со следующей ошибкой при RDP подключении к удаленному серверу в домене AD. После указания корректных имени и пароля доменного пользователя появилось окно с ошибкой (ниже) и окно rdp клиента закрылось.
В русской версии Windows ошибка выглядит так:
Как следует из текста ошибки, RDP клиент не смог аутентифицироваться с помощью Kerberos, т.к. разница во времени между локальным и удаленным компьютером превышает 5 минут. Но в моем случае это оказалось не так: открыв консоль удаленного сервера через ILO, я убедился, что время и часовой пояс на обоих компьютерах одинаковые (и получены с одного и того же NTP сервера).
Вы можете попробовать проверить время на удаленном компьютере командой:
net time \\remote-computer-IP-address
На всякий случай вы можете выполнить ручную синхронизацию времени и перезапустить службу w32time:
w32tm /config /manualpeerlist:your_ntp_server_ip NTP,0x8 /syncfromflags:manual
net stop w32time & net start w32time & w32tm /resync
Другие причины из-за которых может сбиваться время на компьютере рассмотрены в статье.
Если у вас имеется физический доступ к удаленному компьютеру (у меня имелся доступ через консоль ILO), на удаленном компьютера проверьте параметры DNS сервера в настройках сетевого адаптера. Также убедитесь, что указанный DNS сервер доступен с удаленного сервера. Проще всего это сделать с помощью команды:
nslookup server_name DNSServername
Если DNS сервер не отвечает, проверьте, все ли с ним в порядке или попробуйте указать другой DNS сервер.
Если на удаленном компьютере используется несколько сетевых адаптеров, проверьте корректность маршрутизации при доступе к DNS серверу. Возможно компьютер пытается получить доступ к DNS серверу через второй сетевой адаптер в другой подсети.
Попробуйте подключится к удаленному компьютеру северу через RDP клиент по IP адресу вместо полного FQDN DNS имени. В этом случае при авторизации не будет использоваться Kerberos.
Проверьте, не сломались ли доверительные отношения с доменом AD, выполнив команду PowerShell:
Test-ComputerSecureChannel
При корректных доверительных отношениях, она должна вернуть True.
Для восстановления доверительных отношений с доменом можно использовать команду:
Test-ComputerSecureChannel -Repair -Credential corp\adminname
При возникновении ошибки: “Test-ComputerSecureChannel : Cannot reset the secure channel password for the computer account in the domain. Operation failed with the following exception: The server is not operational”, проверьте доступность контроллера домена с сервера и наличие открытых портов для службы Domain and trusts утилитой portqry.
Проверьте, что в настройках RDP протокола на локальном и удаленном сервере выбран одинаковый уровень безопасности RDP Security Layer. Данный параметр можно задать через политику “Требовать использования специального уровня безопасности для удаленных подключения по протоколу RDP” (Require use of specific security layer for remote (RDP) connections) в разделе Конфигурация компьютера -> Административно шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удаленных рабочих столов -> Безопасность (Computer Configuration -> Policies\Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security), выбрав менее безопасный RDP уровень по аналогии со статьей. Или через параметр реестра HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\SecurityLayer.
Также рекомендую убедиться, что проблема не связанна с недавними изменениями в протоколе CredSSP.
Нет никакого смысла проверять часовой пояс. Kerberos работает по UTC. Если контроллер домена и клиент в разных часовых поясах это не может стать причиной проблемы.
В доменной иерархии только PDC эмулятор в корневом домене должен синхронизироваться с NTP сервером. PDC эмуляторы из других доменов должны брать время с корневого PDC. А сервера и клиенты с эмуляторов своих доменов. Вы же предлагаете настроить синхронизацию с NTP сервера.
А также озвучили проблему и не уточнили, как именно решили ее. Вместо этого накидали кучу всевозможных вариантов, при этом даже не заглянув в логи. Смахивает на стрельбу по мухе из дробовика.
В свойствах сетевой карты на сервере включить протокол IPV6 и всё. Дело совсем не во времени тут.
Это плохой совет! Я включил и сетевое окружение стало не доступно.
В моём случае причина данной ошибки была весьма забавной — на клиенте и на терминальном сервере время было одинаковым, и бралось с эмулятора PDC в сети терминальника (для наглядности — в Ростове), а вот авторизовывался клиент на локальном контроллере домена (в Белгороде), на котором из-за скачка напряжения обнулились настройки, включая дату и время… в итоге, белгородских клиентов с отметками авторизации с некорректной датой (там было далеко не 10 минут, а несколько лет, из-за чего и «выпавший из времени» контроллер домена отказывался корректировать время на столь большой срок) Ростовский сервер удалённых рабочих столов отказывался пускать.
Благо, мне хватило опыта сразу пойти смотреть «билеты Цербера», а там — начало нулевых )))