Компьютеру не удается проверить подлинность шлюза удаленных рабочих столов

Обновлено: 24.11.2024

Вы получаете код ошибки: «Компьютер не может проверить подлинность шлюза удаленных рабочих столов. Небезопасно подключаться к серверам, которые невозможно идентифицировать»? Скорее всего, вы настраиваете веб-доступ к удаленному рабочему столу (RDweb) с самоподписанным сертификатом.

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

Во всплывающем окне с ошибкой нажмите кнопку «Просмотреть сертификат».

Перейдите на вкладку «Подробности», а затем нажмите «Копировать в файл…», чтобы создать резервную копию сертификата на рабочем столе.

Появится мастер. Вам нужно будет выбрать тип сертификата. Выберите «Закодировано DER»

Укажите местоположение

Экспорт должен завершиться без ошибок.

Щелкните сертификат правой кнопкой мыши и выберите "Установить сертификат".

Вы собираетесь поместить сертификат в хранилище «Доверенные корневые центры сертификации». Вам нужно будет нажать «Обзор», чтобы выбрать его.

Импорт должен работать,

Вас спросят: «Вы ДЕЙСТВИТЕЛЬНО уверены, что хотите установить этот сертификат». Да… да.

Вы получите сообщение об успешном импорте.

Закройте все браузеры. Вернитесь к URL-адресу веб-доступа к удаленным рабочим столам и повторно войдите в систему. Теперь все должно работать.

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

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

Как следует из ошибки, клиент RDP не смог пройти аутентификацию с помощью Kerberos, так как разница во времени между локальным и удаленным компьютером превышает 5 минут. Но в моем случае оказалось, что это не так: открыв консоль удаленного сервера по ILO, я убедился, что время и часовой пояс одинаковы на обоих компьютерах (и получены с одного и того же исходного NTP-сервера).< /p>

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

чистое время \\IP-адрес удаленного компьютера

Вы можете синхронизировать время вручную на всякий случай и перезапустить службу w32time:

w32tm /config /manualpeerlist:your_ntp_server_ip NTP,0x8 /syncfromflags:manual
net stop w32time & net start w32time & w32tm /resync

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

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

Если у вас есть физический доступ к удаленному компьютеру (у меня был доступ через консоль HPE ILO), проверьте DNS-сервер в настройках сетевого адаптера. Также убедитесь, что вы можете получить доступ к этому DNS-серверу с вашего удаленного сервера. Это проще сделать с помощью этой команды:

nslookup some_server_name DNSServername

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

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

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

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

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

Test-ComputerSecureChannel -Repair -Credential contoso\your_admin_account_name

Если возникает ошибка « Test-ComputerSecureChannel : невозможно сбросить пароль безопасного канала для учетной записи компьютера в домене. Операция не удалась со следующим исключением: сервер не работает », проверьте доступность контроллера домена с вашего сервера и откройте порты TCP/UDP для службы «Домен и доверие» с помощью инструмента portqry.

Убедитесь, что на локальном и удаленном компьютере выбран один и тот же уровень безопасности RDP. Этот параметр можно настроить с помощью политики «Требовать использование определенного уровня безопасности для удаленных (RDP) подключений» в разделе GPO «Конфигурация компьютера» -> «Административные шаблоны» -> «Компоненты Windows» -> «Службы удаленных рабочих столов» -> «Узел сеансов удаленных рабочих столов» -> «Безопасность». выбрав менее безопасный уровень RDP, как описано в этой статье. Или сделайте это, используя этот раздел реестра: HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\SecurityLayer.

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

Поскольку большинство ИТ-специалистов сталкиваются несколько раз в день/неделю, когда вы используете подключение к удаленному рабочему столу (mstsc.exe) для подключения к удаленному серверу/рабочей станции через RDP, вы получаете раздражающее всплывающее окно:

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

Решение

Есть несколько способов решить эту проблему :-).

Первый вариант: переопределить

Как упоминалось ранее, вы можете установить флажок "Больше не спрашивать меня о подключении к этому компьютеру", чтобы решить проблему, но это требует времени.

Второй вариант: переопределить через реестр

Если у вас есть несколько подключений и вы не хотите устанавливать флажок, вы можете развернуть этот параметр реестра с помощью Microsoft Endpoint Manager/GPO и т. д.

Третий вариант: используйте доверенный сертификат из вашего внутреннего ЦС.

Бесстыдная затычка 🙂 Я написал статью о том, как реализовать внутренний центр сертификации. Если вы установите его, он автоматически создаст сертификаты для RDP для серверов в вашей среде. Таким образом, если клиент и сервер находятся в домене Active Directory, в котором также установлен центр сертификации, корневой сертификат автоматически распространяется на все компьютеры в домене, поэтому сертификат RDP будет доверенным.

Четвертый вариант
Если ничего не помогает, вы всегда можете экспортировать сертификат удаленного рабочего стола с целевого сервера и развернуть его через GPO или любым другим способом, который вы предпочитаете, на машинах, с которых вы используете RDP. Для этого откройте на целевом сервере RDP локальное хранилище сертификатов (откройте MMC.exe и выберите сертификаты). Экспортируйте сертификат в нужное место.

Следующий шаг — импортировать его на целевой сервер в папку доверенных корневых сертификатов.

После этого сообщение больше не должно появляться. При необходимости вы можете распространять этот сертификат через GPO (Конфигурация компьютера\Политики\Параметры Windows\Параметры безопасности\Политики открытого ключа\Доверенные корневые центры сертификации).

В этом примере мы уже установили на сервере роли узла сеансов удаленных рабочих столов (RDSH) и сервера лицензий удаленных рабочих столов. Этот сервер находится в режиме рабочей группы и не присоединен к домену. Описанные ниже шаги используются для установки роли RDGW на один сервер (при установке RDGW также устанавливаются IIS), поэтому все три роли (RDSH, RDlic, RDGW) устанавливаются на один и тот же сервер. Если вы уже лицензируете RDS с помощью пользовательских лицензий RDS, установка роли шлюза удаленных рабочих столов не требует дополнительных затрат (кроме приобретения доверенного SSL-сертификата).

Перейдите в Диспетчер серверов, добавьте роли и функции, установка на основе ролей или функций, выберите существующий сервер, в ролях сервера разверните Службы удаленных рабочих столов и выберите Шлюз удаленных рабочих столов, выберите все остальное по умолчанию. Установка займет около 5 минут. Хотя это не приведет к принудительной перезагрузке, обычно рекомендуется перезагрузить сервер после этого шага.

<р>2. Затем перейдите в «Диспетчер серверов», «Службы удаленных рабочих столов», «Серверы», щелкните имя сервера и щелкните правой кнопкой мыши свойства и «Диспетчер шлюза удаленных рабочих столов». (примечание: в обзоре RDS вы увидите сообщение о необходимости войти в систему как пользователь домена для управления серверами и коллекциями — для использования этой функции вам необходимо подключиться к домену, а не в режиме рабочей группы, мы продолжаем режим рабочей группы только ниже).

<р>3. В диспетчере шлюза удаленных рабочих столов разверните дерево и перейдите к политикам. Создайте «Политику авторизации подключения» (CAP), для которой пользователи могут входить в шлюз, и «Политику авторизации ресурсов» (RAP) для того, какие ресурсы могут быть доступны. Например, мы создали политики с именами CAP1 и RAP1 и почти везде использовали значения по умолчанию. Для CAP1 вы, вероятно, захотите добавить пользователей и администраторов удаленного рабочего стола в «членство в группе пользователей». Для RAP1 в разделе «Сетевой ресурс» следует изменить выбор на «разрешить пользователям подключаться к любому ресурсу», поскольку это настройка одного сервера. Вы можете изменить эти политики позже, чтобы сделать их более конкретными и ограничительными.

Примечание. При использовании самозаверяющего сертификата вам потребуется установить сертификат на каждое клиентское устройство. Рекомендуется использовать доверенный сертификат (вместо самоподписанного сертификата), где вам потребуется приобрести сертификат SSL у такой компании, как GoDaddy, и он будет на имя URL/домена вместо IP-адреса.

<р>5. На этом этапе все элементы в статусе диспетчера шлюза удаленных рабочих столов должны отображаться в виде зеленых/зеленых флажков.

<р>6. Перейдите в раздел «Службы» и измените службу шлюза удаленных рабочих столов (имя службы — TSGateway) на тип запуска «автоматический» вместо «автоматический (отложенный)» и убедитесь, что она запущена/работает. Это позволит службе шлюза запускаться быстрее после перезагрузки сервера, иначе вы можете получить сообщение о том, что служба шлюза недоступна при попытке входа в систему, пока вы не подождите несколько минут, пока служба не запустится.

Подключение к RDGW с локального ПК

7Откройте клиент подключения к удаленному рабочему столу на локальном ПК и разверните все поле, щелкнув параметры показа.
На вкладке "Общие" убедитесь, что в поле имени компьютера указан IP-адрес сервера. Вы будете вводить IP-адрес как на вкладке «Общие», так и на вкладке «Дополнительно», используя один и тот же IP-адрес, поскольку в этом примере сервер RDSH и сервер RDGW — это один и тот же сервер.
Перед подключением перейдите на вкладку "Дополнительно".
Нажмите на поле "Настройки" в разделе "Подключение откуда угодно".
Выберите «использовать эти настройки шлюза».
Введите IP-адрес сервера в качестве имени сервера
Снимите флажок "Обходить сервер шлюза удаленных рабочих столов для локальных адресов"
Установите флажок, чтобы использовать те же учетные данные для сервера шлюза удаленных рабочих столов и удаленного компьютера, что и в этом примере.
Нажмите «ОК», вернитесь на вкладку «Локальные ресурсы» и выберите, какие локальные устройства следует перенаправить (обычно принтеры и буфер обмена должны быть перенаправлены, но не локальные диски под кнопкой «Дополнительно» — перенаправление локальных дисков использует пропускную способность/ресурсы, поэтому делайте это только тогда, когда нужно)
Перейдите на вкладку "Общие", решите, хотите ли вы разрешить сохранение учетных данных, и сохраните настроенный файл rdp в виде ярлыка на рабочем столе, нажав "Сохранить как" и дав ему подходящее имя.
При подключении вы можете сначала получить предупреждающее сообщение, в котором говорится: "Не удается определить издателя этого удаленного подключения. Вы все равно хотите подключиться? ИЛИ «Идентификация удаленного компьютера не может быть проверена. Вы все равно хотите подключиться?» Вы можете установить флажок «Больше не спрашивать меня о подключениях к этому компьютеру», если вы не хотите видеть это сообщение каждый раз, и продолжить. Это сообщение обычно появляется из-за того, что вы используете ярлык RDP на локальном рабочем столе, который вы настроили, или потому что вы используете самозаверяющий сертификат.
Подключитесь, и вы получите сообщение о необходимости ввести свои учетные данные, которые будут использоваться как для RDSH, так и для RDGW, выберите, следует ли запоминать учетные данные или нет.
Если при попытке подключения появляется сообщение "Этому компьютеру не удается проверить подлинность шлюза удаленных рабочих столов XXXXX..." и он не будет подключаться, это потому, что вы используете самозаверяющий сертификат и не поместили копию сертификата в доверенные корневые центры сертификации на вашем локальном ПК. Итак, вернитесь на сервер и скопируйте сертификат из папки users\username\documents\certname.cer сервера на локальный ПК/рабочий стол, затем дважды щелкните его на локальном ПК, выберите «установить сертификат» и выберите «Локальный компьютер». ” сохранить местоположение и выберите это конкретное местоположение «Доверенные корневые центры сертификации» (не выполняйте автоматическое определение местоположения). ЭТО НЕОБХОДИМО СДЕЛАТЬ НА ВСЕХ ЛОКАЛЬНЫХ ПК, ЧТОБЫ ПОДКЛЮЧИТЬСЯ ПРИ ИСПОЛЬЗОВАНИИ САМОПОДПИСАННЫХ СЕРТИФИКАТОВ.
Если у вас возникли проблемы со входом в систему, попробуйте ввести имя пользователя в виде имя_сервера\имя_пользователя, то есть WIN-XXXXXX\Administrator или ServerX\Dan и т. д.

Отключите порт 3389 для подключения к Интернету, чтобы заставить трафик использовать порт 443/RDGW

Затем отключите четыре входящих правила брандмауэра Windows для удаленного рабочего стола для порта 3389 ДЛЯ ОБЩЕСТВЕННОГО ПРОФИЛЯ (удаленный рабочий стол — режим пользователя (TCP-In) и (UDP-In) и службы удаленных рабочих столов — режим пользователя (TCP-In). ) и (UDP-In). Нажмите на правило брандмауэра, перейдите на вкладку "Дополнительно" и снимите флажок "Общий", чтобы правило не применялось к общедоступному профилю.
Трафик RDP затем должен проходить через порт 443 извне на сервер, а затем через порт 3389 внутрь сервера. Вы можете проверить это, попробовав войти через RDP без настроек шлюза.
При необходимости вы также можете изменить/отключить другие правила брандмауэра для входящих подключений к удаленному рабочему столу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы проверяем наличие доверительных отношений с доменом AD. Для этого мы запускаем эту команду PowerShell.

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

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

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

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

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

Или мы делаем это с помощью приведенного ниже ключа реестра.

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

Заключение

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

ЗАЩИТИТЕ ВАШ СЕРВЕР ОТ СБОЯ!

Никогда больше не теряйте клиентов из-за низкой скорости сервера! Позвольте нам помочь вам.

Наши специалисты по серверам будут контролировать и обслуживать ваш сервер круглосуточно и без выходных, чтобы он оставался молниеносно быстрым и безопасным.

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

Set-ItemProperty -Path «HKCU:\Software\Microsoft\Terminal Server Client» -name «AuthenticationLevelOverride» -value 0

Компьютеру не удается проверить подлинность шлюза удаленных рабочих столов

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

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

Заключение

Похожие сообщения:

ЗАЩИТИТЕ ВАШ СЕРВЕР ОТ СБОЯ!