Ошибка RDP: обнаружено различие во времени или текущей дате между этим компьютером и удаленным компьютером

Столкнулся со следующей ошибкой при RDP подключении к удаленному серверу в домене AD. После указания корректных имени и пароля доменного пользователя появилось окно с ошибкой (ниже) и окно rdp клиента закрылось.

Remote Desktop cannot verify the identity of the remote computer because there is a time or date difference between your computer and the remote computer. Make sure your computer’s clock is set to the correct time, and then try connecting again. If the problem occurs again, contact your network administrator or the owner of the remote computer.

В русской версии 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 corpadminname

При возникновении ошибки: “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 -> PoliciesAdministrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security), выбрав менее безопасный RDP уровень по аналогии со статьей. Или через параметр реестра HKLMSystemCurrentControlSetControlTerminal ServerWinStationsRDP-TcpSecurityLayer.

Также рекомендую убедиться, что проблема не связанна с недавними изменениями в протоколе CredSSP.