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

Содержание

Ошибка 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 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.

Ошибка при подключении к серверу терминала — Windows Server






Twitter




LinkedIn




Facebook




Адрес электронной почты










  • Статья



Эта статья содержит решение для различных сообщений об ошибках, связанных с сертификатом, при подключении к серверу терминала.

Применяется к: Windows Server 2012 R2
Исходный номер базы знаний: 2000960

Симптомы

При подключении к серверу терминалов под управлением Windows Server 2008 или серверу удаленных рабочих столов под управлением Windows Server 2008 R2 вы получите одно из следующих сообщений об ошибке:

Сбой подключения к удаленному рабочему столу из-за невозможной проверки подлинности удаленного компьютера

Не удалось проверить подлинность удаленного компьютера из-за проблем с сертификатом безопасности. Продолжение может быть небезопасным.

Несоответствие имен
Запрашиваемый удаленный компьютер — <имя компьютера 1>
Имя в сертификате — <имя компьютера 2>

Ошибки сертификата
При проверке сертификата удаленного компьютера обнаружены следующие ошибки: неправильное имя сервера в сертификате.

Продолжение невозможно, так как требуется проверка подлинности.

-или-

Невозможно проверить удостоверение удаленного компьютера. Вы все равно хотите подключиться?

Не удалось проверить подлинность удаленного компьютера из-за проблем с сертификатом безопасности. Продолжение может быть небезопасным.

Несоответствие имен
Запрашиваемый удаленный компьютер — <имя компьютера 1>
Имя в сертификате — <имя компьютера 2>

Ошибки сертификата
Неверное имя сервера в сертификате
Сертификат не из доверенного центра сертификации.

Вы хотите подключиться, несмотря на эти ошибки сертификата?

Причина

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

Решение

Ниже приведены инструкции по проверке выбранного сертификата.

  1. Откройте окна конфигурации служб терминалов в Windows Server 2008 или конфигурацию узла сеансов удаленных рабочих столов в Windows Server 2008 R2.
  2. Откройте диалоговое окно свойств RDP-Tcp подключения.
  3. На вкладке « Общие» проверьте выбранный сертификат. Убедитесь, что выбран правильный сертификат для создания сеансов сервера терминалов или сеансов удаленного рабочего стола.






Пользователь не может пройти аутентификацию или должен пройти аутентификацию дважды

  • Статья

В этой статье рассматриваются несколько проблем, которые могут вызвать проблемы, влияющие на проверку подлинности пользователя.

Доступ запрещен, ограниченный тип входа

В этой ситуации пользователю Windows 10, пытающемуся подключиться к компьютерам Windows 10 или Windows Server 2016, будет отказано в доступе со следующим сообщением:

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

Эта проблема возникает, когда для подключений RDP требуется проверка подлинности на уровне сети (NLA), а пользователь не является членом группы пользователей удаленного рабочего стола . Это также может произойти, если группа пользователей удаленного рабочего стола не назначена группе 9.0024 Доступ к этому компьютеру из сети права пользователя.

Чтобы решить эту проблему, выполните одно из следующих действий:

  • Измените членство пользователя в группе или назначение прав пользователя.
  • Отключить NLA (не рекомендуется).
  • Используйте клиенты удаленного рабочего стола, отличные от Windows 10. Например, клиенты Windows 7 не имеют этой проблемы.

Изменить членство пользователя в группе или назначение прав пользователя

Если эта проблема затрагивает одного пользователя, самым простым решением этой проблемы является добавление пользователя в Группа пользователей удаленного рабочего стола .

Если пользователь уже является членом этой группы (или если у нескольких членов группы возникла одна и та же проблема), проверьте конфигурацию прав пользователя на удаленном компьютере с Windows 10 или Windows Server 2016.

  1. Откройте редактор объектов групповой политики (GPE) и подключитесь к локальной политике удаленного компьютера.
  2. Перейдите к Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment , щелкните правой кнопкой мыши Получите доступ к этому компьютеру из сети , а затем выберите Свойства .
  3. Проверьте список пользователей и групп для пользователей удаленного рабочего стола (или родительской группы).
  4. Если в списке нет ни Пользователи удаленного рабочего стола , ни родительской группы, такой как Все , вы должны добавить ее в список. Если в вашем развертывании более одного компьютера, используйте объект групповой политики.
    Например, членство по умолчанию для Доступ к этому компьютеру из сети включает Каждый . Если в вашем развертывании используется объект групповой политики для удаления Все , вам может потребоваться восстановить доступ, обновив объект групповой политики и добавив Пользователей удаленного рабочего стола .

Отказано в доступе, отклонен удаленный вызов базы данных SAM

Такое поведение наиболее вероятно, если ваши контроллеры домена работают под управлением Windows Server 2016 или более поздней версии, а пользователи пытаются подключиться с помощью настроенного приложения для подключения. В частности, приложениям, которые обращаются к информации профиля пользователя в Active Directory, будет отказано в доступе.

Такое поведение является результатом изменения в Windows. В Windows Server 2012 R2 и более ранних версиях, когда пользователь входит на удаленный рабочий стол, диспетчер удаленных подключений (RCM) связывается с контроллером домена (DC), чтобы запросить конфигурации, относящиеся к удаленному рабочему столу, в объекте пользователя в Active Directory. Доменные службы (AD DS). Эта информация отображается на вкладке «Профиль служб удаленных рабочих столов» свойств объекта пользователя в оснастке MMC «Пользователи и компьютеры Active Directory».

Начиная с Windows Server 2016, RCM больше не запрашивает объект пользователя в AD DS. Если вам нужен RCM для запроса AD DS, потому что вы используете атрибуты служб удаленных рабочих столов, вы должны вручную включить запрос.

Важная информация

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

Чтобы включить устаревшее поведение RCM на сервере узла сеансов удаленных рабочих столов, настройте следующие записи реестра, а затем перезапустите Службы удаленных рабочих столов служба:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\<имя Winstation>\
    • Имя: fQueryUserConfigFromDC
    • Тип: Reg_DWORD
    • Значение: 1 (десятичное)

Чтобы включить устаревшее поведение RCM на сервере, отличном от сервера узла сеансов удаленных рабочих столов, настройте эти записи реестра и следующую дополнительную запись реестра (а затем перезапустите службу):

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

Дополнительные сведения об этом поведении см. в статье KB 3200967 Изменения в диспетчере удаленных подключений в Windows Server.

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

Не удается выполнить вход с помощью смарт-карты в филиале с контроллером домена только для чтения (RODC)

Эта проблема возникает в развертываниях, включающих сервер RDSH на сайте филиала, который использует контроллер домена только для чтения. Сервер RDSH размещен в корневом домене. Пользователи на сайте филиала принадлежат к дочернему домену и используют смарт-карты для проверки подлинности. RODC настроен на кэширование паролей пользователей (RODC принадлежит к Разрешенная группа репликации паролей RODC ). Когда пользователи пытаются войти в сеансы на сервере RDSH, они получают такие сообщения, как «Попытка входа недействительна. Это связано либо с неправильным именем пользователя, либо с неверной информацией для проверки подлинности».

Эта проблема вызвана тем, как корневой контроллер домена и RDOC управляют шифрованием учетных данных пользователя. Корневой контроллер домена использует ключ шифрования для шифрования учетных данных, а контроллер домена только для чтения предоставляет клиенту ключ дешифрования. Когда пользователь получает «недопустимую» ошибку, это означает, что два ключа не совпадают.

Чтобы обойти эту проблему, попробуйте выполнить одно из следующих действий:

  • Измените топологию контроллера домена, отключив кэширование паролей на контроллере домена только для чтения, или разверните контроллер домена с возможностью записи на сайте филиала.
  • Переместите сервер RDSH в тот же дочерний домен, что и пользователи.
  • Разрешить пользователям входить в систему без смарт-карт.

Имейте в виду, что все эти решения требуют компромиссов либо в производительности, либо в уровне безопасности.

Пользователь не может войти на компьютер под управлением Windows Server 2008 SP2 с помощью смарт-карты

Эта проблема возникает, когда пользователи входят на компьютер с Windows Server 2008 SP2, на котором установлено обновление KB4093227 (2018. 4B). Когда пользователи пытаются войти с помощью смарт-карты, им отказывают в доступе с такими сообщениями, как «Действительные сертификаты не найдены. Убедитесь, что карта вставлена ​​правильно и плотно прилегает». В то же время компьютер Windows Server фиксирует событие приложения «Произошла ошибка при получении цифрового сертификата со вставленной смарт-карты. Неверная подпись».

Чтобы устранить эту проблему, обновите компьютер Windows Server с помощью перевыпуска 2018.06 B базы знаний 4093227, Описание обновления безопасности для уязвимости отказа в обслуживании протокола удаленного рабочего стола Windows (RDP) в Windows Server 2008: 10 апреля 2018 г. . может войти в систему с помощью смарт-карты, но затем получает сообщение об ошибке «SCARD_E_NO_SERVICE». Удаленный компьютер может перестать отвечать.

Чтобы обойти эту проблему, перезагрузите удаленный компьютер.

Чтобы решить эту проблему, обновите удаленный компьютер с помощью соответствующего исправления:

  • Windows Server 2008 SP2: KB 4090928, Windows пропускает дескрипторы в процессе lsm. exe, и приложения смарт-карт могут отображать ошибки «SCARD_E_NO_SERVICE»
  • Windows Server 2012 R2: KB 4103724, 17 мая 2018 г. — KB4103724 (предварительная версия ежемесячного накопительного пакета)
  • Windows Server 2016 и Windows 10, версия 1607: KB 4103720, 17 мая 2018 г. — KB4103720 (сборка ОС 1439).3.2273)

Если удаленный ПК заблокирован, пользователю необходимо дважды ввести пароль

Эта проблема может возникнуть, когда пользователь пытается подключиться к удаленному рабочему столу под управлением Windows 10 версии 1709 в развертывании, в котором подключения RDP не требуют NLA . В этих условиях, если удаленный рабочий стол заблокирован, пользователю необходимо дважды ввести свои учетные данные при подключении.

Чтобы решить эту проблему, обновите компьютер с Windows 10 версии 1709 с помощью KB 4343893, 30 августа 2018 г. — KB434389.3 (сборка ОС 16299.637).

Пользователь не может войти в систему и получает сообщения «Ошибка аутентификации» и «Исправление оракула шифрования CredSSP».

, им отказано в доступе, и они получают такие сообщения:

 Произошла ошибка аутентификации. Запрошенная функция не поддерживается.
...
Это может быть связано с исправлением оракула шифрования CredSSP.
...

«Исправление оракула шифрования CredSSP» относится к набору обновлений безопасности, выпущенных в марте, апреле и мае 2018 года. CredSSP — это поставщик проверки подлинности, который обрабатывает запросы проверки подлинности для других приложений. В обновлении «3B» и последующих обновлениях от 13 марта 2018 г. был устранен эксплойт, с помощью которого злоумышленник мог передать учетные данные пользователя для выполнения кода в целевой системе.

В исходных обновлениях добавлена ​​поддержка нового объекта групповой политики, Encryption Oracle Remediation, который имеет следующие возможные параметры:

Обновление от 8 мая 2018 г. изменило значение параметра Encryption Oracle Remediation по умолчанию с Vulnerable на Mitigated. С этим изменением клиенты удаленных рабочих столов, на которых установлены обновления, не могут подключаться к серверам, на которых их нет (или обновленным серверам, которые не были перезапущены). Дополнительные сведения об обновлениях CredSSP см. в статье базы знаний 4093492.

Чтобы решить эту проблему, обновите и перезапустите все системы. Полный список обновлений и дополнительную информацию об уязвимостях см. в статье CVE-2018-0886 | Уязвимость CredSSP, связанная с удаленным выполнением кода.

Чтобы обойти эту проблему, пока обновления не будут завершены, проверьте KB 4093492 для разрешенных типов подключений. Если нет возможных альтернатив, вы можете рассмотреть один из следующих методов:

Дополнительные сведения о работе с групповой политикой см. в разделе Изменение блокирующего объекта групповой политики.

Когда пользователи входят в удаленный рабочий стол с помощью компьютера под управлением Windows 7 или Windows 10 версии 1709, они сразу же видят второй запрос на вход. Эта проблема возникает, если на клиентском компьютере установлены следующие обновления:

  • Windows 7: KB 4103718, 8 мая 2018 г. — KB4103718 (ежемесячный накопительный пакет)
  • Windows 10 1709: KB 4103727, 8 мая 2018 г. — KB4103727 (сборка ОС 16299.431)

Чтобы решить эту проблему, убедитесь, что компьютеры, к которым пользователи хотят подключиться (а также серверы RDSH или RDVI), полностью обновлены до июня 2018 г. Сюда входят следующие обновления:

  • Windows Server 2016: KB 4284880 , 12 июня 2018 г. — KB4284880 (сборка ОС 14393.2312)
  • Windows Server 2012 R2: KB 4284815, 12 июня 2018 г. — KB4284815 (ежемесячный накопительный пакет)
  • Windows Server 2012: KB 4284855, 12 июня 2018 г. — KB4284855 (ежемесячный накопительный пакет)
  • Windows Server 2008 R2: KB 4284826, 12 июня 2018 г. — KB4284826 (ежемесячный накопительный пакет)
  • Windows Server 2008 SP2: KB4056564, Описание обновления безопасности для уязвимости удаленного выполнения кода CredSSP в Windows Server 2008, Windows Embedded POSReady 2009 и Windows Embedded Standard 2009: 13 марта 2018 г.

Пользователям отказано в доступе к развертыванию, использующему Remote Credential Guard с несколькими посредниками подключений к удаленному рабочему столу

Эта проблема возникает в развертываниях с высокой доступностью, использующих два или более посредников подключений к удаленному рабочему столу, если используется Remote Credential Guard в Защитнике Windows. Пользователи не могут войти на удаленные рабочие столы.

Эта проблема возникает из-за того, что Remote Credential Guard использует Kerberos для аутентификации и ограничивает NTLM. Однако в конфигурации высокой доступности с балансировкой нагрузки посредники подключений к удаленному рабочему столу не могут поддерживать операции Kerberos.

Если вам необходимо использовать конфигурацию высокой доступности с посредниками подключений к удаленному рабочему столу с балансировкой нагрузки, эту проблему можно обойти, отключив Remote Credential Guard. Дополнительные сведения об управлении Remote Credential Guard в Защитнике Windows см. в статье Защита учетных данных удаленного рабочего стола с помощью Remote Credential Guard в Защитнике Windows.

Удаленный рабочий стол не может проверить время идентификации или разницу в дате

by Gayathri R Nayak | 22 ноября 2020 г.

При попытке подключиться к удаленному серверу в домене AD через RDP возникает ошибка «удаленный рабочий стол не может проверить разницу во времени или дате идентификации».

Здесь, в Bobcares, мы видели несколько таких ошибок, связанных с Windows, как часть наших служб управления сервером для веб-хостов и поставщиков онлайн-услуг.

Сегодня мы рассмотрим причины этой ошибки и посмотрим, как ее исправить.

 

Почему возникает ошибка «Удаленный рабочий стол не может проверить разницу во времени или дате идентификации»

Эта ошибка возникает при попытке подключения к удаленному серверу в домене AD через RDP.

Например, ошибка выглядит так, как показано ниже.

Эта ошибка указывает на то, что клиент RDP не может пройти аутентификацию с помощью Kerberos. Это происходит потому, что разница во времени между локальным и удаленным компьютером превышает 5 минут.

 

Как устранить ошибку «Удаленный рабочий стол не может проверить подлинность времени или разницы дат»

Чтобы исправить эту ошибку, наши инженеры службы поддержки открыли консоль удаленного сервера через ILO. Также мы позаботились о том, чтобы время и часовой пояс были одинаковыми на обоих компьютерах.

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

 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

Примечание. Если удаленный сервер является виртуальной машиной, мы гарантируем, что синхронизация времени с хост-гипервизором отключена в настройках виртуальной машины.

Поскольку у нас есть физический доступ к удаленному компьютеру, проверяем DNS-сервер в настройках сетевого адаптера. Кроме того, мы удостоверяемся, что можем получить доступ к этому DNS-серверу с удаленного сервера. Для этого мы используем приведенную ниже команду.

 nslookup some_server_name DNSServername

В случае, если DNS-сервер DNS не отвечает, проверяем его работоспособность или пытаемся указать другой адрес DNS-сервера.

Однако, если на удаленном компьютере используется несколько сетевых адаптеров, мы проверяем правильность таблицы маршрутизации при доступе к DNS-серверу. Компьютер может попытаться получить доступ к DNS-серверу, используя другой сетевой адаптер из другой IP-подсети.

Затем мы пытаемся подключиться к удаленному компьютеру, используя IP-адрес вместо полного полного доменного имени DNS в окне подключения RDP-клиента. В нашем случае Kerberos не будет использоваться для аутентификации.

Убеждаемся, что доверительные отношения с доменом AD существуют. Для этого мы запускаем эту команду PowerShell.

 Test-ComputerSecureChannel

Если есть доверительные отношения, возвращается True.

Чтобы восстановить доверительные отношения с доменом Active Directory, мы запускаем эту команду:

 Test-ComputerSecureChannel -Repair -Credential contoso\your_admin_account_name

Если появляется указанная ниже ошибка, мы проверяем доступность контроллера домена с сервера и открыть порты TCP/UDP для службы «Домен и трасты».

 Test-ComputerSecureChannel: Не удается сбросить пароль безопасного канала для учетной записи компьютера в домене. Операция завершилась неудачно со следующим исключением: сервер не работает

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

Мы устанавливаем этот параметр с помощью политики «Требовать использования определенного уровня безопасности для удаленных (RDP) подключений». Он присутствует в разделе GPO «Конфигурация компьютера» >> «Административные шаблоны» >> «Компоненты Windows» >> «Службы удаленных рабочих столов» >> «Узел сеансов удаленных рабочих столов» >> «Безопасность», выбрав менее безопасный уровень RDP.

Или мы делаем это, используя приведенный ниже раздел реестра.

 HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\SecurityLayer

 

[Вы все еще сталкиваетесь с ошибкой Windows? – Мы здесь, чтобы помочь вам]

 

Заключение

Короче говоря, эта ошибка возникает при попытке подключения к удаленному серверу в домене AD через RDP.

Читайте также: