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

Столкнулся со следующей ошибкой при 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 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 .