Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение.
В связи с недавними обновлениями безопасности Windows, закрывающее уязвимости в протоколе CredSSP, парочка маков (mac mini середины 2007 года) потеряли доступ к терминальному серверу на базе Windows Server 2008R2.
Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение.
Дело в том, что старая версия маковского rdp client 2.1.1 от Microsoft, ставшая последней доступной для Mac OS X 10.7 (Lion), не работает не только с Windows Server 2012, но после вышеупомянутого обновления перестала подключаться и к WinServer 2008R2. В природе существует и неофициальная версия rdp-клиента 2.1.2, однако разыскивать её, нет особого резона — результат будет аналогичным.
Актуальные, на данный момент, клиенты Microsoft Remote Desktop 8.0 (совместима с OS X 10.9 и выше) и Microsoft Remote Desktop 10.0 (macOS 10.10 и выше) поставить на старую систему OS X не представляется возможным. Из вменяемых альтернатив, можно выделить, пожалуй, только Parallels Client. и вроде вот оно счастье, ведь в минимальных требованиях значится Mac OS X 10.7.3, однако не стоит верить всему что пишут. Хоть программа и благополучно устанавливается, позволяет внести данные о вашем подключении, однако вылетает на попытке соединения с сервером вываливая кучу ошибок.
От безысходности можно пойти от обратного, изменив работу службы удаленных рабочих столов на сервере (метод работает и на Windows Server 2012), однако лучшим вариантом станет замена клиентской машины.
Подключения старой версии rdp client 2. 1 к Windows Server 2012
Нам понадобится запустить редактор групповых политик. В командной строке набираем gpedit. Переходим в раздел настроек безопасности RDP:
Здесь следует поменять значение двух параметров:
Теперь даже старые версии Microsoft Remote Desktop будут подключаться к терминальному серверу, правда только по дефолтному порту 3389. Замечен и побочный эффект — Windows клиенты, которые ставили галочку «сохранить пароль» лишились такой возможности. В общем, данная статья носит скорее познавательный характер, приделывать подобные костыли рабочим серверам я бы не стал.
Если считаете статью полезной,не ленитесь ставить лайки и делиться с друзьями.
Комментариев
Добрый день. Не ожидал что в 2018 найду свежую информацию для старых маков. Вот мне как раз актуально, так как подключаюсь по удалёнке не к серверу, а к своему рабочему компьютеру на Windows 10, обновился недавно. Теперь RDP снова работает 🙂
Вы так конкретно и доступно всё описали, что до меня наконец-то дошло почему не удаётся подключиться к удалённому компу. Спасибо за помощь!
Не удаётся подключиться к RDP через шлюз?
Пробовал подключаться с двух разных компьютеров, которые территориально находятся совсем в разных местах (разные провайдер, IP и пр.). На обеих стоит Windows 7 x64 uk-UA (без SP, без обновлений), оба настраивались и используются мной. Нет даже предположений, в чём проблема. Какой-то софт, либо сделанные мной настройки, или ещё что.
Ну и, собственно, вопрос. Что не так и что делать? Как локализовать проблему? Чем мои компьютеры так уникальны и не нравятся шлюзу?
Симптомы
Рассмотрим следующий сценарий:
Установить службу шлюза удаленных рабочих столов (шлюз RD) на компьютере под управлением Windows Server 2008 R2.
Существует несколько привязок сертификат на порт 443 этого компьютера.
В этом случае шлюз удаленных рабочих Столов может работать неправильно. Некорректное поведение зависит от привязки выбранного сертификата имя хранилища сертификатов. Имя различные проблемы привязки вызывает хранилища сертификата следующие значения:
Имя хранилища сертификатов не равно NULL для привязки
В этом случае все соединения проходят за исключением в следующих случаях:
Проверка подлинности смарт-карты настраивается на стороне шлюза удаленных рабочих Столов.
Проверки работоспособности защиты доступа к сети применяются на стороне клиента.
Имя хранилища сертификатов для привязки равно NULL
В этом случае все соединения друг с другом сбой и появляется следующее сообщение об ошибке:
Компьютеру не удается подключиться к удаленному компьютеру, так как отсутствует сертификат, настроенный для использования на сервере шлюза удаленных рабочих столов. Обратитесь к сетевому администратору за помощью.
В то же время добавляется следующее событие шлюза службы терминалов с 306 идентификатор журнала шлюза службы терминалов:Примечание. Чтобы проверить, установлено ли значение NULL имя хранилища сертификатов, выполните следующие действия.
В командной строке введите следующую команду и нажмите клавишу ВВОД:
netsh http show sslcert
Причина
Проблемы возникают потому, что служба шлюза удаленных рабочих Столов получает привязку неверный сертификат.
Решение
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.
Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Чтобы получить полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание, посетите следующий веб-сайт корпорации Майкрософт:
http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Для установки этого исправления компьютер должна быть запущена Windows Server 2008 R2.
Необходимость перезагрузки
После установки исправления компьютер необходимо перезагрузить.
Сведения о замене исправлений
Это исправление не заменяет других исправлений.
Сведения о файлах
Английская версия данного исправления содержит атрибуты файла (или более поздние атрибуты файлов), приведенные в следующей таблице. Дата и время для этих файлов указаны в формате общего скоординированного времени (UTC). При просмотре сведений о файле, он преобразуется в локальное время. Чтобы узнать разницу между временем по Гринвичу и местным временем, следует использовать Часовой поясвкладке Дата и времяэлемент панели управления.
При подключении к серверу терминала, который работает Windows Server 2008 или Windows Server 2008 R2, вы получаете различные сообщения об ошибках, связанных с сертификатом.
В этой статье предоставляется решение для различных сообщений об ошибках, связанных с сертификатом, при подключении к серверу терминала.
Применяется к: Windows Server 2012 R2 Исходный номер КБ: 2000960
При подключении к серверу терминала, который работает Windows Server 2008, или удаленному настольному серверу, который работает Windows Server 2008 R2, вы получаете одно из следующих сообщений об ошибке.
Подключение удаленного рабочего стола не удалось из-за невозможности проверки подлинности удаленного компьютера
Удаленный компьютер не удалось проверить подлинность из-за проблем с сертификатом безопасности. Продолжить работу может быть небезопасно.
Несоответствие имен Запрашивается удаленный компьютер Имя в сертификате
Ошибки сертификата При проверке сертификата удаленного компьютера были допущены следующие ошибки: имя сервера в сертификате неверно.
Невозможно продолжить, так как требуется проверка подлинности.
Невозможно проверить удостоверение удаленного компьютера. Вы хотите подключиться в любом случае?
Ошибки сертификата Имя сервера в сертификате неверно сертификат не из доверенного органа сертификации.
Вы хотите подключиться, несмотря на эти ошибки сертификата?
Проблема возникает из-за неправильного сертификата, который используется для сеанса сервера терминала или удаленного рабочего стола.
Ниже ниже 1000 действий по проверке выбранного сертификата.
Устранение ошибки проверки подлинности RDP
8 мая 2018 г. Microsoft выпустило обновление, которое предотвращает удаленное выполнение кода с помощью уязвимости в протоколе CreedSSP.
После установки данного обновление пользователи не могут подключиться к удаленным ресурсам посредством RDP или RemoteApp. При подключении происходит такая ошибка:
Появление ошибки обусловлено установкой данных обновлений безопасности:
В данной статье мы рассмотрим варианты исправления данной ошибки.
Вариант №1: Убираем проверку подлинности.
Заходим в свойства компьютера, переходим на вкладку Удаленный доступ и снимаем галку с чекбокса.
Вариант №2 (рекомендуемый): Обновление клиентских и серверных ОС.
Устанавливаем специально выпущенные патчи обновления, которые закрыли уязвимость в RDP-клиенте. Данные обновления можно посмотреть на сайте Microsoft. После установки данного обновления, мы обновляем CredSSP.
Вариант №3: Через групповые политики.
В свойствах данной политики выбираем пункт Включено и ниже в параметрах выбираем уровень защиты Оставить уязвимость.
После того, как данные действия выполнены, необходимо зайти в командную строку от имени администратора и выполнить данную команду:
Вариант №4. Редактирование реестра.
Локально заходим на устройство, к которому пытаемся подключиться и нажимаем Win+R. Вводим regedit. После того, как откроется редактор реестра идем по следующему пути:
Затем находим параметр AllowEncryptionOracle, открываем его и ставим значение 2.
После выполнения данных действий с реестром выполняем перезагрузку устройства.
Нужна помощь в настройке RDP-подключений? Обращайтесь к нам!
6 / 6 / 1Регистрация: 28.06.2013Сообщений: 161
Server 2008Удаленный рабочий стол и ЭЦП27.12.2018, 08:59. Показов 75319. Ответов 10
Здравствуйте.
Такая ситуация. У нас есть 1С, работаем по терминалке. На сервере установлен серверный VipNet, а серверную версию Крипто-про не покупали и цены для нас на неё сейчас кусаются. Но в 1С подключен сервис с контрагентами 1С ЭДО, который для работы требует ЭЦП. Подпись у нас есть, на клиентах есть Крипто-про.
Как сделать чтобы при подключении к удаленному рабочему столу сервер подцеплял ЭЦП (как, например, принтер)? В настройках удаленного подключения полазила, но не увидела такой возможности.
0
ProgrammingЭксперт94731 / 64177 / 26122Регистрация: 12.04.2006Сообщений: 116,782
27.12.2018, 08:59
238 / 227 / 47Регистрация: 12.12.2012Сообщений: 1,943
Ни как. Переносить серты только. Крипто про при первой установке дает лицензию на месяца 3.
0
162 / 74 / 23Регистрация: 06.07.2017Сообщений: 315
Есть два варианта решения вашей задачи.
Если ключ у вас это физический токен, вы можете копировать контейнер с сертификатом и установить его на терминальный сервер для всех пользователей. Задайте пароль на контейнер посложнее. Этот способ конечно менее безопасный чем с токеном, но работа с токеном локально подключенным в сервер запрещена в RDP.
Так же можно попробовать пробросить через RDP. Смотрите настройки RDP подключения:
ПараметрыЛокальные ресурсыПодробнееСмарт-карты должна стоять галка.
0
kapitan_lyagysh, проброс через rdp токены не поддерживают. За всё время только встречал такой функционал у новых ключей в абсолют банке.
Обычно задача решается переносом ключа. Если нет ключа, через реестр с редактированием SID. А если домен, то не надо.
0
Сообщение от pEntity
проброс через rdp токены не поддерживают
Зависит от производителя токена, у меня у самого были случаи когда токен пробрасывался но контейнер не видел.
В мане по рутокену например говорится что такой метод с пробросом у них работает.
https://dev.rutoken.ru/display/KB/RU1003Добавлено через 1 минуту
etoken кстати тоже говорит, что такая схема должна работать.
1
Добавлено через 55 секунд
Сообщение от kapitan_lyagysh
Так же можно попробовать пробросить через RDP. Смотрите настройки RDP подключения:
ПараметрыЛокальные ресурсыПодробнееСмарт-карты должна стоять галка.
Да, галка на смарт-картах стоит. А что дальше?
0
Для начала огласить производителя токена
0
ESMART
0
Модератор7369 / 3892 / 491Регистрация: 13.03.2013Сообщений: 14,347Записей в блоге: 11
Ребята, зря теряете время, даже если Вам удастся перебросить токен по RDP, как его увидит софт, покуда не установлен «Крипто-про»? Никак!
Даже если Вы установите «крипто-про» на триальный период, то удалить и снова установить его с целью получения дополнительных 3-х месяцев также не получится, даже если Вы затрете реестр.
Выход только один: либо ставить «Крипто-про» на сервер, либо пусть клиент работает локально на своем ПК, а выгрузку необходимых данных делает на сервер, с целью импорта таковых в 1С.
0
1С ЭДО не обязательно требует крипто-про, может также работать и через vipnet
0
В данном разделе предполагается, что пользователь имеет некоторое представление о работе цепочек доверия сертификатов, процессе подписания сертификатов, об инфраструктуре открытого ключа и общих принципов конфигурации сертификатов. Сведения о конфигурации инфраструктуры открытого ключа в Windows Server 2008 см. на странице «ITPROADD-204: расширенные возможности инфраструктуры открытых ключей в операционных системах Windows Vista и Windows Server 2008 (страница может быть на английском языке) (https://go.microsoft.com/fwlink/?LinkId=93995). Сведения о конфигурации инфраструктуры открытого ключа в Windows Server 2003 см. в разделе «Инфраструктура открытого ключа» (страница может быть на английском языке) (https://go.microsoft.com/fwlink/?LinkID=54917).
Для шифрования соединений между клиентами Службы удаленных рабочих столов и серверами Шлюз удаленных рабочих столов при подключениях через Интернет по умолчанию применяется протокол TLS 1.0. Протокол TLS является стандартным протоколом, который используется для организации безопасных веб-соединений в интрасетях и в Интернете. Данный протокол представляет собой самую последнюю и наиболее защищенную версию протокола SSL. Дополнительные сведения о протоколе TLS см. в разделах:
Для правильной работы протокола TLS необходимо установить на сервере Шлюз удаленных рабочих столов SSL-совместимый сертификат X.509.
Обзор процесса установки и настройки сертификата
Процесс получения, установки и настройки сертификата для сервера Шлюз удаленных рабочих столов состоит из трех шагов.
Шаг 1. Получение сертификата для сервера шлюза удаленных рабочих столов
Получить сертификат для сервера Шлюз удаленных рабочих столов можно одним из следующих способов.Если используемый автономный ЦС либо ЦС предприятия настроен на выдачу SSL-совместимых сертификатов X.509, удовлетворяющих требованиям сервера Шлюз удаленных рабочих столов, можно создать и предоставить запрос на сертификат несколькими способами, в зависимости от политик и настройки ЦС организации. Способы получения сертификата перечислены ниже. Отправка заявки из оснастки «Сертификаты».Запрос сертификатов с помощью мастера запроса сертификата.Запрос сертификата через Интернет. Использование средства командной строки Certreq.
Дополнительные сведения об использовании перечисленных методов получения сертификатов для Windows Server 2008 R2 см. в разделе «Получение сертификата» в справке оснастки «Сертификаты», а также в разделе «Certreq» справочника по командам Windows Server 2008 R2. Для просмотра разделов справки оснастки «Сертификаты» нажмите кнопку Пуск, выберите пункт Выполнить, введите команду hh certmgr.chm и нажмите кнопку ОК. Дополнительные сведения о запросе сертификатов для Windows Server 2003 см. в разделе «Запрос сертификатов» (https://go.microsoft.com/fwlink/?LinkID=19638) (на английском языке).
Сертификат, выданный автономным ЦС либо ЦС предприятия, также должен быть подписан открытым доверенным ЦС, являющимся членом программы корневых сертификатов Майкрософт (https://go.microsoft.com/fwlink/?LinkID=59547) (на английском языке). В противном случае пользователи домашних компьютеров или киосков, вероятно, не смогут подключиться к серверам Шлюз служб терминалов или Шлюз удаленных рабочих столов. Невозможность подключения вызвана тем, что корень ЦС может не быть доверенным для домашних и прочих компьютеров, не являющихся членами домена.Если организация не имеет собственного автономного ЦС или ЦС предприятия, настроенного на выдачу SSL-совместимых сертификатов X.509, сертификат можно приобрести у доверенного открытого ЦС, являющегося участником программы корневых сертификатов корпорации Майкрософт (https://go.microsoft.com/fwlink/?LinkID=59547) (на английском языке). Некоторые из таких открытых ЦС могут бесплатно предоставлять сертификаты в целях тестирования.Кроме того, если организация не имеет собственного автономного ЦС или ЦС предприятия, а совместимый сертификат от доверенного открытого ЦС отсутствует, то для технической оценки и тестирования можно создать и импортировать самозаверяющий сертификат для сервера Шлюз удаленных рабочих столов. Дополнительные сведения см. в разделе Создание самозаверяющего сертификата для сервера шлюза удаленных рабочих столов.
Обратите внимание, что в хранилище доверенных корневых центров сертификации клиентов Службы удаленных рабочих столов должен присутствовать сертификат ЦС, выдавшего сертификат сервера. Пошаговые инструкции по установке сертификата на клиентском компьютере см. в разделе Установка корневого сертификата сервера шлюза удаленных рабочих столов на клиенте служб удаленных рабочих столов.
Если используется один из первых двух способов получения сертификата и клиентский компьютер Службы удаленных рабочих столов доверяет ЦС, выдавшему сертификат, не требуется устанавливать сертификат ЦС, выдавшего сертификат сервера, в хранилище сертификатов клиентского компьютера. Например, не требуется устанавливать сертификат ЦС, выдавшего сертификат, в хранилище сертификатов клиентского компьютера, если на сервере Шлюз удаленных рабочих столов установлен сертификат компании VeriSign либо любого другого открытого доверенного ЦС. Если для получения сертификата используется третий способ (то есть, если создается самозаверяющий сертификат), не требуется устанавливать сертификат ЦС, который выдал сертификат сервера в хранилище доверенных корневых центров сертификации на клиентском компьютере. Дополнительные сведения см. в разделе Установка корневого сертификата сервера шлюза удаленных рабочих столов на клиенте служб удаленных рабочих столов.
Шаг 2. Импорт сертификата
Используемые термины: Remote Desktop Gateway, Active Directory, Терминальный сервер.
В данном руководстве мы рассмотрим развертывание роли шлюза удаленных рабочих столов (Remote Desktop Gateway или RDG) на отдельном сервере с Windows Server 2019. Действия будут аналогичны для Windows Server 2012 и 2016 (даже, в основных моментах, 2008 R2). Предполагается, что в нашей инфраструктуре уже имеются:
1. Служба каталогов Active Directory — настроено по инструкции Как установить роль контроллера домена на Windows Server.
2. Два терминальных сервера — настроено по инструкции Установка и настройка терминального сервера на Windows Server.
Пошагово, мы выполним следующие действия:
Установка серверной роли Настройка шлюза Создание групп в AD Создание политик RDG Привязка сертификата Настройка клиента для подключения Remoteapp через Gateway DNS round robin Часто встречаемые ошибки
Установка роли
Открываем Диспетчер серверов:
Переходим в Управление — Добавить роли и компоненты:
При появлении окна приветствия нажимаем Далее (при желании, можно поставить галочку Пропускать эту страницу по умолчанию):
На страницы выбора типа установки оставляем выбор на Установка ролей или компонентов:
Выбираем целевой сервер — если установка выполняется на сервере локально, то мы должны увидеть один сервер для выбора:
Ставим галочку Службы удаленных рабочих столов:
Дополнительные компоненты нам не нужны:
На странице служб удаленных рабочих столов идем дальше:
Выбираем конкретные роли — нам нужен Шлюз удаленных рабочих столов. После установки галочки появится предупреждение о необходимости поставить дополнительные пакеты — кликаем по Добавить компоненты:
Откроется окно для настроек политик:
Откроется окно роли IIS:
При выборе служб ролей веб-сервера ничего не меняем:
В последнем окне ставим галочку Автоматический перезапуск конечного сервера, если требуется:
Дожидаемся окончания установки роли:
Сервер может уйти в перезагрузку.
Настройка RDG
Для настройки Microsoft Remote Desktop Gateway мы создадим группу компьютеров в Active Directory, настроим политику для RDG и создадим сертификат.
Создание групп для терминальных серверов
* в данном примере мы создаем группу All terminals в организационном юните Servers Group. Это группа безопасности (Security), локальная в домене (Domain local).
Добавим в нашу группу терминальные серверы:
* в данном примере у нас используются два сервера — Terminal-1 и Terminal-2.
Настройка политик
Для предоставления доступа к нашим терминальным серверам, создадим политики для подключений и ресурсов.
В диспетчере сервера переходим в Средства — Remote Desktop Services — Диспетчер шлюза удаленных рабочих столов:
Раскрываем сервер — кликаем правой кнопкой по Политики — выбираем Создание новых политик безопасности:
Устанавливаем переключатель в положении Создать политику авторизации подключений к удаленным рабочим столам и авторизации ресурсов удаленных рабочих столов (рекомендуется):
Даем название политике:
Задаем параметры авторизации:
В следующем окне есть возможность настроить ограничения использования удаленного рабочего стола. При желании, можно их настроить:
* в нашем случае ограничений нет. При необходимости, устанавливаем переключатель в положение Отключить перенаправление для следующих типов клиентских устройств и оставляем галочки пункты для ограничений.
Далее настраиваем временные ограничения использования удаленного подключения. Если в этом есть необходимость, оставляем галочки в состоянии Включить и указываем количество минут, по прошествии которых сеанс будет отключен:
В следующем окне мы увидим вне введенные настройки:
Откроется страница создания политики для авторизации ресурса — задаем для нее название:
Указываем группу пользователей, для которой будет применяться политика:
Теперь выбираем группу ресурсов, на которую будет разрешен доступ со шлюза терминалов:
* мы выбрали группу, созданную нами ранее в AD.
Указываем разрешенный для подключения порт или диапазон портов:
* в данном примере мы разрешим подключение по порту 3389, который используется по умолчанию для RDP.
Политики будут созданы.
Настройка сертификата
Для работы системы нам необходим сертификат, который можно купить или получить бесплатно от Let’s Encrypt. Однако, с некоторыми неудобствами, будет работать и самоподписанный. Мы рассмотрим вариант настройки с ним.
Запускаем «Диспетчер шлюза удаленных рабочих столов» — кликаем правой кнопкой по названию нашего сервера — выбираем Свойства:
Переходим на вкладку Сертификат SSL:
Выбираем вариант Создать сомозаверяющий сертификат и кликаем по Создать и импортировать сертификат:
Задаем или оставляем имя для сертификата — нажимаем OK:
Мы увидим информацию о создании сертификата:
Консоль диспетчера шлюза перестанет показывать ошибки и предупреждения:
Сервер готов к работе.
Подключение к серверу терминалов через шлюз
Выполним первое подключение с использованием шлюза. В качестве клиентской операционной системы могут использоваться Windows, Linux, Mac OS. Рассмотрим пример на Windows 10.
Запускаем «Подключение к удаленному рабочему столу» (приложение можно найти в Пуск или ввести команду mstsc). На вкладке Общие вводим локальное имя конечного сервера, к которому мы хотим подключиться:
* в нашем случае мы будем подключаться к серверу terminal-1.dmosk.local.
Переходим на вкладку Дополнительно и кликаем по Параметры:
Переключаем параметр приложения в положение Использовать следующие параметры сервера шлюза удаленных рабочих столов и указываем внешнее имя сервера:
Если мы используем самозаверенный сертификат, приложение выдаст ошибку. Кликаем по Просмотреть сертификат:
Переходим на вкладку Состав и кликаем Копировать в файл:
Указываем путь для выгрузки файла:
Открываем папку, куда сохранили сертификат. Кликаем по сохраненному файлу правой кнопкой и выбираем Установить сертификат:
Выбираем Локальный компьютер — Далее:
В качестве размещения сертификата выбираем Доверенные корневые центры сертификации:
После снова пробуем подключиться к удаленному рабочему столу через шлюз:
Настройка Remoteapp через Gateway
Предположим, у нас есть опубликованное приложение Remoteapp и мы хотим подключаться к терминальному серверу через настроенный шлюз. Для этого открываем rdp-файл приложения на редактирование (например, блокнотом) и вносим в него изменения:
Несколько терминальных серверов и dns round robin
При наличие нескольких серверов терминалов, мы можем создать несколько записей в DNS, чтобы получать по round robin разные серверы:
Однако, при попытке подключиться к незарегистрированному серверу мы увидим ошибку:
Для решения переходим в настройку шлюза — кликаем правой кнопкой по Политики авторизации ресурсов и выбираем Управление локальными группами компьютеров:
Выбираем нужную группу компьютеров и нажимаем Свойства:
* в моем случае это была единственная группа, созданная по умолчанию.
На вкладке Сетевые ресурсы добавляем имя, созданное в DNS:
Теперь подключение будет выполняться без ошибок.
Возможные ошибки
При подключении мы можем столкнуть со следующими ошибками.
1. Учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов.
Причиной является отсутствие пользователя, под которым идет подключение к шлюзу, в группе, которой разрешено использование политики. Для решения проблемы проверяем настройки политики — группы пользователей, которым разрешено использование политики и к каким ресурсам разрешено подключение. В итоге, наш пользователь должен быть в нужной группе, а терминальный сервер, к которому идет подключение должен быть указан в соответствующей группе ресурсов.
Обращение к терминальному серверу выполняется по незарегистрированному имени. Необходимо проверить настройку в клиенте подключения или зарегистрировать ресурс, как мы это делали при настройке нескольких терминальных серверов.
3. Сертификат шлюза удаленных рабочих столов просрочен или отозван.
В данном случае нужно проверить, какой сертификат привязан к RDG. Также нужно убедиться, что привязанный сертификат, на самом деле, не просрочен или отозван. В крайнем случае, можно заново создать сертификат.
Question
Ошибка «Не удалось подключиться к удалённому компьютеру, поскольку сертификат сервера шлюза удалённых рабочих столов отозван или просрочен».
При этом Windows 10 (8, 7) этот сертификат (выданный доменным Центром сертификации) не просрочен и подключение в этих ОC происходит без проблем. В хранилище Доверенные корневые центры сертификации (локальный компьютер) сертификат доменного ЦС есть.
Списки отзыва актуальные, серийного номера сертификата шлюза в них нет.
Пока нагуглил, что какие-то проблемы с Службой времени Windows в этой ОС. В Просмотре событий очень много 158 кодов про ошибку VMICTimeProvider. Вместе с тем, время в трее показывается актуальное, синхронизация с сервером времени time.windows.com происходит успешно.
Кто-нибудь сталкивался с подобной проблемой? Нашлось решение?
Буду признателен за любую помощь по существу проблемы.
Answers
Скорее всего на WIN11 старый TLS запрещен или его можно включить.
Спасибо за наводку! Включил TLS v.1 согласно этой статьи (выполнил пункты 3.1 и 3.2) и тоже всё заработало. ОГРОМНОЕ Спасибо! Конечно, со временем будем переходить новые серверные ОC.
Спасибо добрый человек, но чтоб долго не искать напишу тут, нужно создать reg файл с содержимым, добавить в реестр и перезагрузиться:
Спасибо, что ответили. Я уж думал, что я один с такой проблемой столкнулся. Я создал обращение в техподдержку MS, сегодня ко мне подключались специалисты, смотрели и недоумевали, обещали подключить спецов уровнем выше. Можно поинтересоваться, а какая у Вас версия Windows на Шлюзе удалённых рабочих столов? У меня 2008R2.
Есть такая же проблема, шлюз 2008R2. На самом деле по ошибкам time-service мы ничего не определим т.к. на ОС Win10 они точно такие же, но при этом все прекрасно работает.
Как бы товарищи из Microsoft не предложили обновляться до 2016.
Спасибо Вам за Ваш вопрос.
2. Убедитесь, что URL-адрес rdweb работает нормально.
3. Выдан ли сертификат шлюза удаленных рабочих столов доверенным государственным органом, например Thawte, GeoTrust, Comodo, GoDaddy, DigiCert и т. Д., Или он из другого источника, например внутреннего центра сертификации?
4. Также это может произойти, если время клиентского компьютера и время RD Server не синхронизированы. Если у вас есть домен AD, они синхронизируют время с вашим контроллером домена PDC для всех ваших серверов и клиентских ПК.
Не удалось проверить не был ли отозван этот сертификат rdp windows 7
Прочитал похожие темы и «тот самый блог Вадима.»
Все сделал как описано.
Пытаюсь из одной подсети(2008R2) подключится к терминальному серверу на 2008R2 в другой подсети, через интернет.
Результат и там и там одинаков » не удалось проверить не был ли отозван этот сертификат».
Серийный номер сертификата : 428d050d0000000001de
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 16 Hours, 59 Minutes, 32 Seconds
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 16 Hours, 59 Minutes, 32 Seconds
Issuer: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local
NotBefore: 12.04.2011 9:46
NotAfter: 11.04.2012 9:46
SubjectAltName: DNS- имя =MO1TS01.kaventdom.local
ca 63 de 3a 08 cd 49 a7 bb e0 56 9a 49 49 60 75 c9 18 d3 b6
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Проверено «Сертификат (0)» Время: 4
Проверено «Базовый CRL (20)» Время: 4
Проверено «Разностный CRL (20)» Время: 4
ОК «Разностный CRL (20)» Время: 4
Отсутствуют URL «Нет» Время: 0
64 1c 33 49 43 47 29 98 7d 7c b6 a0 93 2c 7e d1 80 6e b5 5a
ad f4 63 27 bd 1f 3e 47 09 e9 4c a1 57 45 ec ff ff b0 f1 06
NotBefore: 18.03.2011 18:29
NotAfter: 18.03.2031 18:39
Subject: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local
ff d2 72 dd e5 19 d8 ae 71 b1 cb 42 43 b5 8b cd d5 3d 06 ea
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
e0 99 12 cd 1f 0a bf f8 4e cd de 65 79 62 29 b6 d6 fd ee e9
fb 6e 1e e0 73 68 ba 3e 78 a7 08 24 a6 9b 65 d8 29 ca e4 6e
Проверенные политики выдачи: Нет
Проверенные политики применения:
1.3.6.1.5.5.7.3.2 Проверка подлинности клиента
1.3.6.1.5.5.7.3.1 Проверка подлинности сервера
Проверка отзыва сертификата выполнена
Итак, сертификат 61619b9c000000000013
а что у вас ссылка на CRT делает в расширении OCSP? Как минимум из-за этих ошибок у вас неполная цепочка сертификатов.
корневой сертификат этой цепочки (сервера DGET-CA) у вас не установлен в доверенные центры сертификации компьютерного хранилища.
61619b9c000000000013 — нужно удалить. Корректно настроить расширение AIA на издающем CA и выпустить новый сертификат.
61fb04be000000000017 — сертификат сервера DGET-CA нужно установить в доверенные центры сертификации компьютерного хранилища.
на самом деле, не знаю, чего она там делает =) сертификат сервера стоял и стоит в доверенных центрах удалённой машины.
переделал сертификаты. собственно, ничего не поменялось, ошибка та же:
Ошибка подключения к удаленному рабочему столу из-за невозможности проверить подлинность удаленного компьютера. Не удалось проверить подлинность удаленного компьютера из-за проблем с сертификатом безопасности. Продолжение может быть небезопасным. Имя в сертификате от удаленного компьютера: msk-db01.msk.dget.ru. Не удалось проверить, не был ли отозван сертификат. Продолжение невозможно из-за серьезных ошибок сертификатов.
Поставщик: CN=DGET-CA DC=msk DC=dget DC=ruСубъект: CN=compas.myftp.orgСерийный номер сертификата: 613796c600000000001d
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)SimpleChain.dwErrorStatus = CERT_TRUST_IS_UNTRUSTED_ROOT (0x20)SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
Поставщик: CN=DGET-CA DC=msk DC=dget DC=ruСубъект: CN=msk-db01.msk.dget.ruСерийный номер сертификата: 613f693700000000001e
Frage
Привет!, а Вас не смутило, то что Вы допустили две ошибки:
-вопросу уже более полутора лет;
-Автор вопроса, не Вы.
Правильнее задавать свой вопрос, указывая ссылкой на это обсуждение вопроса.
Начните с внимательного изучения серии статей, начав со статьи «Краткое руководство по Microsoft PKI». Особое внимание обратите на требование для Внешних Пользователей, и Корневой сертификат, должен быть подписан Доверенным корневым центром сертификации.
Да, я Жук, три пары лапок и фасеточные глаза :))
Alle Antworten
Сертификат запрашивал с компьютера с Windows 8 через оснастку сертификаты. Сейчас в личном хранилище кроме него больше нет сертификатов. На компьютере с Windows 7 только добавлен сертификат ЦС предприятия в доверенные корневые ЦС компьютера.
На всякий случай упомяну, при подключении «сервер» с Windows 8 выдает для проверки именно сертификат от ЦС, а не самоподписанный. Для этого подправил групповую политику, чтобы RDP использовал сертификаты с шаблоном Machine.
Запрос на создание Сертификата, должен создаваться на том компьютере, для которого он предназначен. Этот сертификат должен быть в Личных, этот Сертификат компьютер должен предъявить Серверу, и этот Сертификат должен проверяться на отзыв. Корневой доверенный Сертификат, как правило, не проверяется на отзыв.
Ваша цитата: «Да, на клиентском компьютере с Windows 7.», что входит в противоречие с Вашей же цитатой: «Сертификат запрашивал с компьютера с Windows 8 через оснастку сертификаты.».
Дополнительно, воспользуйтесь серией статей:
Я лично под клиентом понимаю компьютер с Windows 7, у него нет никаких своих сертификатов. Свой сертификат есть у компьютера с Windows 8 ( «Сертификат запрашивал с компьютера с Windows 8 через оснастку сертификаты.» ), я его экспортировал в файл, проверил на клиенте ( «Да, на клиентском компьютере с Windows 7.») и выложил лог в 1 сообщении. Но когда я подключаюсь с клиента к компьютеру с Windows 8, получаю ту самую ошибку, что не удается проверить, не отозван ли сертификат. Я тут же открываю сведения о сертификате, копирую оттуда URL на список отзыва и без проблем скачиваю этот самый список отзыва, в котором у меня уже штук 5 отозванных сертификатов.
За статьи спасибо, но не нашел в них решения своей проблемы.
https://www.dropbox.com/sh/y3qr6f34sf7ip5o/BgQLYhzgQr по данной ссылке выложил сертификаты ЦС, компьютера с Windows 8 и списки отзыва. Само собой, клиент может разрешить имена, указанные в сертификате.
Из статей, ссылки на которые Вам дал ранее, следует, что для того что бы Клиент мог проверить легитимность предъявляемого ему Сертификата, необходимо или в ручную установить СОС (Список Отзыва Сертификатов) или обеспечить Клиенту, OCSP проверку Сертификата.
Установите на Клиенте вручную, СОС сертификата, которого проверяет Клиент, проверьте и напишите результат.
СОС необходимо устанавливать в Промежуточные центры сертификации.
Руководствуясь разделом Q9 справки, загрузите в общедоступную папку SkyDrive, публичный Сертификат (cer-файл) компьютера Windows 8.
По 2 части я не понял, что это за СОС. Знаю только СОС, который публикуется ЦС в соответствии с настройками CDP.
Минимум же, первым в цепочке в Путь сертификации, должен быть SERVER-CA.TC-SOTKA.INT.
2. Список отзыва данного Вами сертификата, не доступен по указанному в сертификате адресу:
Выпущенный Вами сертификат для Windows 8, на этом компьютере в таком случае должен быть установлен в Корневые центры сертификации и Личные Сертификаты.
На компьютере Клиенте с Windows 7, он должен быть установлен в Корневые центры сертификации, список отзыва сертификатов для которых, не проверяется. Что неправильно.
1. Меня тоже сначала это смутило, но на компьютере с Windows 8 (сразу) и на компьютере с Windows 7 (после добавления сертификата ЦС в корневые доверенные) путь сертификации выглядит вот так https://www.dropbox.com/s/bxiyskoa0kgmvdy/2.jpg Как писал ранее, сертификат для Windows 8 запрашивался через оснастку сертификаты, там небыло иного выбора как запросить сертификат по шаблону Компьютер (Machine).
2. Он недоступен у Вас, потому что это внутренний адрес. В данный момент решил вопрос добавлением записи в файл hosts. У клиента доступ к сайту по имени работает.
Внимательно изучите серию статей:
Именно по этой статье я настраивал публикацию СОС.
Сегодня установил онлайн ответчик, с ним проверка сертификата отрабатывает корректно. Очень жаль, что так и не получилось довести до ума проверку СОС по HTTP, придется что-то делать с клиентами на Windows XP.
Жук, спасибо за желание помочь и с наступающим.
Ради интереса попробуй следующие:
В IIS manager, в настройках сайта для CRL, найдите Request Filtering:
Зайдите туда и справа будут Actions, нажмите там Edit feature settings. Откроется окно как на картинке, выставите там галку Allow double escaping
И посмотрите изменится ли что-то для машин с Win XP.
Взаимно, так же с наступающим новым годом.
У нас, есть хорошее правило: «Никогда не опускать лапки. «. Так что, могу только порекомендовать, передохнуть, выпить чашечку кофе, принять ванну :)), и засучив рукава, с новыми силами, всё же постараться разрешить эту проблему.
Жук, привет. Есть вопрос.
Сразу скажу что пока силен в вопросе слабо, но головняк уже поймал:
Есть пара машин вне домена + RDS доменный. вопрос вот о чем: 1я машина (ipsec + WIN 8.1) DNS конечно не понимает, поэтому по ip к RDS(генерированный фаил с rds), предлагает убедится в надежности издателя и дает запрос на лог/пас домена. Далее сертификат RDP, предупреждение: «Не удалось проверить подлинность удаленного компьютера из-за проблем с сертификатом безопасности». И вот проблема: «Не удается проверить не был ли отозван сертификат». В целом не велика, так как это всего лишь предупреждение и жить бы можно. НО хочется по уму. Сертификат тот же самый что предлагается вначале всего для того чтоб убедиться что подключение доверенное(ну зрительно, CA добавлен в доверенные корневые центры сертификации).
Как я и говорил и сам не ас. Поэтому буду очень рад ответам. И если заодно посоветуешь где на клиенте более подробные логи этого всего посмотреть буду очень благодарен?
Главная » Видео » Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение
Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов как исправить
Win Server 2012 Std
Поднята роли AD, Hyper-V, Шлюз RDS.
На VM (также Win Server 2012 Std) поднят TS и опубликованы приложения RemoteApp.
Внутри доменной сети %domain.local% RemoteApp работает. Снаружи — нет. О чём свидетельствует сабж.
Понимаю, что проблема в сертификатах, но как правильно настроить — не знаю.
В настройке развёртывания служб RDS при добавлении шлюза создал сертификат с FQDN для домена %publicdomain.ru%.
Каким образом настроить сертификат(ы?), чтобы RemoteApp запускались извне?
Загадочный IPsec Определение температуры процессора в Windows 10 через PowerShell. Синий экран смерти (BSOD) и причём тут DrWeb? Ноутбук с Windows 10 в качестве точки доступа Wi-Fi Сбой в алгоритме Яндекса заставил пользователей понервничать Что делать, если перестала работать панель задач и кнопка «ПУСК» в Windows 10
«Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов»
Первый раз столкнулась с подключением к удаленному рабочему столу,сертификат установила но вот только при подключении возникает ошибка с таким текстом: «Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов «server_name». Подключатся к серверам без удостоверений не безопасно. Обратитесь за помощью к администратору сети»
Подскажите что можно сделать, что бы решить эту ситуацию
Службы удаленных рабочих столовСлужбы удаленных рабочих столов- коллекции (можно несколько создать коллекция и как?)
Служба удаленных рабочих столовЗдравствуйте, вопрос состоит в следующем стоит Windows server 2008 r2 как активировать службу.
Ip виртуализация удаленных рабочих столовДобрый день! После настройки ip виртуализации удаленных рабочих столов для сеансов в Windows.
Если отключить проверку в клиенте RDP? При подключениидополнительновкладка подключениеПроверка подлинности сервера
Выбрано — «Подключатся без предупреждения».
У того сертификата что мне дали, закончился строк действия. Нажав на кнопку «Просмотреть сертификат», открывается новый сертификат, я его сохранила с помощью кнопки «Копировать в файл» и потом установила этот новый сертификат. Возможно причина в этом, и мне нужно попросить что бы мне сбросили новый сертификат и потом все получится? Хотя почему не выходит если я сама его скачала и установила.
Сервер удаленных рабочих столовЗдравствуйте. На работе установили новый сервер под управлением Windows Server 2012, настроил.
Заглючила служба удаленных рабочих столовЗдравствуйте. История такова. Мне потребовалось организовать поддержку нескольких одновременных.
Сервер лицензирования удалённых рабочих столовЗдравствуйте, Win 2008R2, 64x, SuperMicro Столкнулся с такой проблемой: Поднял терминальный.
Установка роли удаленных рабочих столовЗдравствуйте! При установки роли удаленных рабочих столов появляется ошибка (вложения). Как это.