Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата
Если у вас отсутствует CA, но вы хотите, чтобы при подключении к RDP/RDS серверу у пользователей не появлялось предупреждения, вы можете добавить сертификат в доверенные на компьютерах пользователей.
Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:
Чтобы работал прозрачных RDP вход без ввода пароля (RDP Single Sign On), нужно настроить политику Allow delegation defaults credential и указать в ней имена RDP/RDS серверов (см. статью).
Устанавливаем сертификат
Дальше скопируйте строку ниже и введите имя домена, по которому хотите подключатсяь к серверу и выполните команду.
После этого сертификат подписывающий домен встанет на место старого. Обновлять вручную ничего не нужно, через 60 дней программа продлит сертификат сама.
Готово! Вы великолепны и избавились от надоедливой ошибки.
А какие системные ошибки раздражают вас?
Неправильный сертификат или цепочка сертификатов код ошибки 0x10000 rdp
Итак, сертификат 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
Сертификат или связанная цепочка недействительны —
Несколько пользователей сообщают, что они не могут подключиться к другому компьютеру, используя Подключение к удаленному рабочему столу. Затронутые пользователи сообщают, что получают следующее предупреждение: «Сертификат или связанная цепочка недействительны ». В большинстве случаев проблема возникает, если пользователь пытается использовать подключение к удаленному рабочему столу в качестве гостя с компьютера Mac OS.
Обновить: Во всех случаях, которые нам удалось выявить, проблема возникает, когда пользователь пытается использовать MAC-версию Remote Control для подключения к ПК с Windows 10. Большинство пользователей сообщают, что проблема возникла только после их обновления до Sierra.
Что является причиной ошибки «Сертификат или связанная цепочка недействительны»?
Мы исследовали эту конкретную проблему, изучив различные пользовательские отчеты и стратегии исправления, которые обычно используются для решения этой конкретной проблемы. Из наших исследований кажется, что есть несколько потенциальных виновников, которые могут в конечном итоге вызвать это сообщение об ошибке:
Если вы пытаетесь разрешить это конкретное сообщение об ошибке, эта статья предоставит вам несколько стратегий устранения неполадок, которые другие пользователи в аналогичной ситуации успешно использовали для обхода или устранения «Сертификат или связанная цепочка недействительны ».
Изменение метода удаленной аутентификации гостевого предпочтения
Это, безусловно, самое эффективное решение из всех. Подавляющее большинство пострадавших пользователей сообщили, что «Сертификат или связанная цепочка недействительны » ошибка была устранена после того, как они обновили настройку «Подключение к удаленному рабочему столу» с гостевого компьютера на «Всегда подключаться, даже если аутентификация не удалась».
Вот краткое руководство о том, как это сделать:
Если вы все еще видите «Сертификат или связанная цепочка недействительны» Ошибка при попытке подключения, перейдите к следующему способу ниже.
Способ 2. Установка последней версии Microsoft Remote Desktop Connection
Как выясняется, эта конкретная проблема также может возникать, если используемая вами версия Microsoft Remote Desktop сильно устарела. Несколько пострадавших пользователей сообщили, что «Сертификат или связанная цепочка недействительны» ошибка больше не возникала после обновления до последней версии RDC.
Обновление до последней версии Remote Desktop Connection чрезвычайно просто — просто перейдите по этой ссылке (Вот) и загрузите последнюю версию. Ваша система MAC автоматически отменит вашу текущую установку и заменит ее последней.
Обновление вашего клиента RDC до последней версии
Если этот метод неприменим или у вас уже установлена последняя версия подключения к удаленному рабочему столу, перейдите к следующему способу ниже.
Разрешение удаленных подключений на хост-компьютере
Еще один потенциальный сценарий, в котором «Сертификат или связанная цепочка недействительны» ошибка произойдет, если хост-компьютер (тот, к которому вы пытаетесь подключиться) не разрешает удаленное подключение. Несколько пользователей, пытающихся решить эту проблему, сообщили, что проблема была устранена, как только они включили удаленные подключения из меню «Свойства системы».
Включение удаленного управления на компьютере с Windows
Открываем 80 порт
Выполните приведенные ниже действия, если клиенту Удаленного рабочего стола не удается подключиться к удаленному рабочему столу, и отсутствуют сообщения или другие признаки, по которым можно определить причину.
Не удалось проверить не был ли отозван этот сертификат 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.dwRevocationFreshnessTime: 16 Hours, 59 Minutes, 32 Seconds
Issuer: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local
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)
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 Проверка подлинности сервера
Проверка отзыва сертификата выполнена
Предупреждение о самоподписанном сертификате RDP
По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный
сертификат. В результате при первом подключении к RDP/RDS серверу через клиента mstsc.exe, у пользователя появляется предупреждение:
Чтобы продолжить установление RDP подключении пользователь должен нажать кнопку Да. Чтобы RDP предупреждение не появлялось каждый раз, можно включить опцию “Больше не выводить запрос о подключениях к этому компьютеру».
Добавляем А запись
Просто добавляем A запись и вписываем в неё IP адрес сервера. На этом работа с доменом окончена.
Устранение ошибки проверки подлинности RDP
8 мая 2018 г. Microsoft выпустило обновление, которое предотвращает удаленное выполнение кода с помощью уязвимости в протоколе CreedSSP.
После установки данного обновление пользователи не могут подключиться к удаленным ресурсам посредством RDP или RemoteApp. При подключении происходит такая ошибка:
Появление ошибки обусловлено установкой данных обновлений безопасности:
В данной статье мы рассмотрим варианты исправления данной ошибки.
Вариант №1: Убираем проверку подлинности.
Заходим в свойства компьютера, переходим на вкладку Удаленный доступ и снимаем галку с чекбокса.
Вариант №2 (рекомендуемый): Обновление клиентских и серверных ОС.
Устанавливаем специально выпущенные патчи обновления, которые закрыли уязвимость в RDP-клиенте. Данные обновления можно посмотреть на сайте Microsoft. После установки данного обновления, мы обновляем CredSSP.
Вариант №3: Через групповые политики.
В свойствах данной политики выбираем пункт Включено и ниже в параметрах выбираем уровень защиты Оставить уязвимость.
После того, как данные действия выполнены, необходимо зайти в командную строку от имени администратора и выполнить данную команду:
Вариант №4. Редактирование реестра.
Локально заходим на устройство, к которому пытаемся подключиться и нажимаем Win+R. Вводим regedit. После того, как откроется редактор реестра идем по следующему пути:
После выполнения данных действий с реестром выполняем перезагрузку устройства.
Нужна помощь в настройке RDP-подключений? Обращайтесь к нам!
Причина
Проблемы возникают потому, что служба шлюза удаленных рабочих Столов получает привязку неверный сертификат.
Создаем шаблон RDP сертификата в центре сертификации (CA)
Попробуем использовать для защиты RDP подключений доверенный SSL/TLS сертификат, выданный корпоративным центром сертификации. С помощью такого сертификата пользователь может выполнить проверку подлинности RDP сервера при подключении. Предположим, что у вас в домене уже развернут корпоративной центр сертификации (Microsoft Certificate Authority), в этом случае вы можете настроить автоматическую выдачу и подключение сертификатов всем компьютерам и серверам Windows в домене.
Н на вашем CA нужно создать новый тип шаблона сертификата для RDP/RDS серверов.
Установка КриптоПро
Когда установочный файл скачен, его нужно запустить для установки на ваш компьютер. Система отобразит предупреждение, что программа запрашивает права на изменение файлов на ПК, разрешите ей это сделать.
Перед установкой программы на свой компьютер, все ваши токены должны быть извлечены. Браузер должен быть настроен на работу, исключением является браузер Opera, в нем уже произведены все настройки по умолчанию. Единственное, что остается пользователю — это активировать специальный плагин для работы. В процессе вы увидите соответствующее окно, где Opera предлагает активировать этот плагин.
После запуска программы, нужно будет ввести ключ в окне.
Найти программу для запуска можно будет по следующему пути: «Пуск», «Все программы», «КриптоПро», «КриптоПро CSP». В открывшемся окне нажмите кнопку «Ввод лицензии» и в последней графе введите ключ. Готово. Теперь программу необходимо настроить соответствующим образом под ваши задачи. В некоторых случаях для электронной подписи используют дополнительные утилиты — КриптоПро Office Signature и КриптоАКМ. Можно устранить ошибку — нет возможности построить цепочку сертификатов для доверенного корневого центра — простой переустановкой КриптоПро. Попытайтесь это сделать, если другие советы не помогли.
Ошибка «Не удается построить цепочку сертификатов» все еще появляется? Отправьте запрос в службу поддержки, в котором нужно разместить скриншоты ваших последовательных действий и объяснить подробно свою ситуацию.
Не удается построить цепочку сертификатов для доверенного корневого центра
Проверка корневого сертификата УЦ в браузере
Проверку можно выполнить в браузере.
Теперь попробуйте снова выполнить те действия, в процессе которых возникла ошибка. Чтобы получить корневой сертификат, необходимо обратиться в соответствующий центр, где вы получили СКП ЭП.
Устранение ошибки при создании создания цепочки сертификатов для доверенного корневого центра
В первую очередь убедитесь, что у вас нет проблем с интернет-подключением. Ошибка может появляться при отсутствии доступа. Сетевой кабель должен быть подключен к компьютеру или роутеру.
При подключенном интернете у вас должны отобразиться данные об отправленных пакетах, скорости передачи и прочая информация. Если Интернета нет, вы увидите, что пакеты не дошли до места назначения.
Теперь проверим наличие корневого сертификата Удостоверяющего Центра. Для этого:
Качаем WinAcme
Качаем WinAcme с их сайта. Архив лучше всего распаковать туда, куда вы не доберетесь, исполняемые файлы и скрипты вам еще пригодятся в будущем для автоматического обновления сертификата. Лучше всего вытряхнуть архив в C:WinAcme.
Настройка доверенных SSL/TLS сертификатов для защиты RDP подключений
В этой статье мы покажем, как использовать доверенные SSL/TLS сертификаты для защиты RDP подключений к компьютерам и серверам Windows в домене Active Directory. Эти сертфикаты мы будем использовать вместо самоподписанных RDP сертификатов (у пользователей появляется предупреждение о невозможности проверки подлинности при подключению к RDP хосту с таким сертификатом). В этом примере мы настроим специальный шаблон для выпуска RDP сертификатов в Certificate Authority и настроим групповую политику для автоматического выпуска и привязки SSL/TLS сертификата к службе Remote Desktop Services.
Произошла ошибка проверки подлинности. Указанная функция не поддерживается
После установки обновления KB4103718 на моем компьютере с Windows 7 я не могу удаленно подключится к серверу c Windows Server 2012 R2 через удаленный рабочий стол RDP. После того, как я указываю адрес RDP сервера в окне клиента mstsc.exe и нажимаю «Подключить», появляется ошибка:
Произошла ошибка проверки подлинности.
Указанная функция не поддерживается. Удаленный компьютер: computername
После того, как я удалил обновление KB4103718 и перезагрузил компьютер, RDP подключение стало работать нормально. Если я правильно понимаю, это только временное обходное решение, в следующем месяце приедет новый кумулятивный пакет обновлений и ошибка вернется? Можете что-нибудь посоветовать?
Ответ
Вы абсолютно правы в том, что бессмысленно решать проблему удалением обновлений Windows, ведь вы тем самым подвергаете свой компьютер риску эксплуатации различных уязвимостей, которые закрывают патчи в данном обновлении.
В своей проблеме вы не одиноки. Данная ошибка может появится в любой операционной системе Windows или Windows Server (не только Windows 7). У пользователей английской версии Windows 10 при попытке подключится к RDP/RDS серверу аналогичная ошибка выглядит так:
The function requested is not supported.
Remote computer: computername
Ошибка RDP “An authentication error has occurred” может появляться и при попытке запуска RemoteApp приложений.
Почему это происходит? Дело в том, что на вашем компьютере установлены актуальные обновления безопасности (выпущенные после мая 2018 года), в которых исправляется серьёзная уязвимость в протоколе CredSSP (Credential Security Support Provider), использующегося для аутентификации на RDP серверах (CVE-2018-0886) (рекомендую познакомится со статьей Ошибка RDP подключения: CredSSP encryption oracle remediation). При этом на стороне RDP / RDS сервера, к которому вы подключаетесь со своего компьютера, эти обновления не установлены и при этом для RDP доступа включен протокол NLA (Network Level Authentication / Проверку подлинности на уровне сети). Протокол NLA использует механизмы CredSSP для пре-аутентификация пользователей через TLS/SSL или Kerberos. Ваш компьютер из-за новых настроек безопасности, которые выставило установленное у вас обновление, просто блокирует подключение к удаленному компьютеру, который использует уязвимую версию CredSSP.
Что можно сделать для исправления эту ошибки и подключиться к вашему RDP серверу?
Проверка состояния служб RDP
На локальном компьютере (клиентском) и удаленном компьютере (целевом) должны быть запущены следующие службы:
Для локального или удаленного управления службами можно использовать оснастку MMC. Вы также можете использовать PowerShell для управления службами в локальном или удаленном расположении (если удаленный компьютер настроен для приема удаленных командлетов PowerShell).
На любом компьютере запустите одну или обе службы, если они запущены.
Если вы запускаете службу удаленных рабочих столов, нажмите кнопку Да, чтобы служба перенаправителя портов пользовательского режима служб удаленного рабочего стола перезапустилась автоматически.
Настройка групповой политики для выдачи RDP сертификатов
Теперь нужно настроить доменную политику, которая будет автоматически назначать RDP сертификат компьютерам/серверам согласно настроенного шаблона.
Для применения нового RDP сертификата, перезапустите службу Remote Desktop Services:
Теперь при RDP подключении к серверу перестанет появляться запрос на доверие сертификату (чтобы появился запрос о доверии сертификату, подключитесь к серверу по IP адресу вместо FQDN имени сервера, для которого выпущен сертификат). Нажмите кнопку “Посмотреть сертификат”, перейдите на вкладку “Состав”, скопируйте значение поля “Отпечаток сертификата”.
Также можете в консоли Certification Authority в секции Issued Certificates проверить, что по шаблону RDPTemplate был выдан сертификат определённому Windows компьютеру/серверу. Также проверьте значение Thumbprint сертификата:
Теперь, при подключении к удаленном столу любого сервера или компьютера, на который действует эта политика, вы не увидите предупреждения о недоверенном RDP сертификате.
Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов windows 7
Здравствуйте. Пытаюсь поднять RDS, столкнулся с проблемой.
Все необходимые роли службы удаленных рабочих столов заведены на одном сервере. Доменное имя сервера внутри сети server.mydomen.com совпадает с «внешним» доменным именем. Настроил веб-доступ к удаленным рабочим столам, личные рабочие столы для пользователей и тд.
Если так же заходить снаружи, не из домена, ошибка следующая:
Удаленному рабочему столу не удалось подключиться к удаленному компьютеру «server.mydomen.com» по одной из этих причин: 1) Данной учетной записи пользователя не предоставлены права на доступ к шлюзу удаленных рабочих столов «server.mydomen.com» 2) Данный компьютер не авторизован для доступа к шлюзу удаленых рабочих столов «server.mydomen.com» 3) Используется несовместимый метод проверки подлинности (например, шлюз удаленных рабочих столов ожидает смарт-карту, а предоставлен пароль)
Ответы
Переустановил роль rdg, перенастроил точно так же. В итоге получил ещё одну ошибку (в дополнение к трём существующим):
4. В группе «Пользователи удаленного рабочего стола» на сервере узла сеансов удаленных рабочих столов должны присутствовать пользователи или группы домена.
После этого на клиенте через rdweb появилась уже другая ошибка:
«При отправке данных на сервер шлюза удаленных рабочих столов произошла ошибка. Сервер временно недоступен или не работает сетевое подключение.»
ПС: давно не работал с виндовс, совсем забыл про актуальность шутки:
Едут в машине таксист, бизнесмен и программист. Вдруг машина ломается. Таксист говорит: — Давайте мотор смотреть. Бизнесмен: — Да ладно, давай тачку поймаем. Программист: — А давайте все выйдем и снова войдем, может, она заработает?
Все ответы
При этом политики диспетчера шлюза удаленных рабочих столов:
Политики авторизации подключений
Если пользователь является членом любой из перечисленных ниже групп пользователей:
mydomen.comАдминистраторы предприятия, mydomen.comГости домена, mydomen.comСотрудники mydomen.com Если клиентский компьютер является членом любой из следующих групп компьютеров: mydomen.comГости домена, mydomen.comКомпьютеры домена Если пользователь использует следующие поддерживаемые методы проверки подлинности Windows: Пароль Разрешить пользователю подключение к этому серверу шлюза удаленных рабочих столов и отключить перенаправление устройств для следующих клиентских устройств: Неприменимо (перенаправление устройств включено для всех клиентских устройств) По истечении времени ожидания в режиме простоя: — Не применяется (без времени ожидания простоя) По истечении времени ожидания сеанса: — Не применяется (без времени ожидания простоя)
Политики авторизации ресурсов
PROGRESS-MАдминистраторы предприятия, mydomen.comГости домена, mydomen.comСотрудники mydomen.com
Сетевой ресурс: разрешить подключение пользователей к любому сетевому ресурсу
1. Проверьте наличие учетной записи RDG в группе безопасности RAS and IAS Servers в Active Directory.
1. Что вы имеете в в виду под «учетной записью RDG»? Группу RAS and IAS Servers нашел. Вот список моих групп:
2. Настройку осуществил, выбрал уровень безопасности RDP. Только в статье тип подключения 6.1, а у меня 7.1. Немного изменился ход подключения, но ошибка в итоге та же самая.
Никто ещё что-нибудь не подскажет?
бывает если подключаться к члену фермы через имя компьютера, а не фермы. У вас случайно не включена эта фича?
Вот она по-моему где включается. Видимо нет.
Таким образом настроено.
Про виртуальные машины ранее информации не было, то есть это физическая машина одна. Может быть еще информация какая-нибудь будет? Где стоит Web-Access и что происходит на виртуальных машинах?
Да, всё на одной машине. Чтобы наружу не пробрасывать кучу портов на вирт. машины. Да и безопаснее.
Физическая машина вообще одна. На ней 11 виртуальных машин. Все роли установлены на хостовой системе. Домен active directory mydomen.com. Сервер (хостовая система) server.mydomen.com. Всем пользователям назначены виртуальные рабочие столы (например vm1.mydomen.com). При заходе в rdweb (без разницы извне или снаружи) пользователи авторизуются и нормально видят свои опубликованные столы. При попытке подключения ошибка в первом посте. Сертификат используется самоподписанный, один для всех служб, занесённый на сервере и на клиентах в доверенные. Ещё какая информация, вроде всё описал? Сейчас в службах удаленных рабочих столов обнаружил три ошибки: 1. Cервер шлюза удаленных рабочих столов должен иметь возможность подключения к доменным службам Active Directory. 2. На сервере шлюза удаленных рабочих столов необходимо включить хотя бы одну политику авторизации подключений к удаленным рабочим столам. 3. На сервере шлюза удаленных рабочих столов следует настроить использование действительного SSL-сертификата
1. RDG стоит на контроллере домена. Каким образом он не может достучаться до AD?
2. Политики есть и они включены.
Точно такие же проблемы на форуме видел, но решения там не было.
Разрешаем выполнение скриптов
Чтобы WinAcme смог без проблем импортировать новый сертификат, нужно разрешить выполнение скриптов. Для этого переходив в папку /Scripts/
Перед запуском WinAcme нам нужно разрешить выполнение двух скриптов. Для этого двойным кликом запустите PSRDSCerts.bat из папки со скриптами.
Проверка состояния прослушивателя протокола RDP
В точности следуйте инструкциям из этого раздела. Неправильное изменение реестра может вызвать серьезные проблемы. Прежде чем редактировать реестр, создайте резервную копию реестра, чтобы вы могли восстановить его в случае ошибки.
Проверка состояния прослушивателя RDP
Для выполнения этой процедуры используйте экземпляр PowerShell с разрешениями администратора. На локальном компьютере также можно использовать командную строку с разрешениями администратора. Но для этой процедуры используется PowerShell, так как одни и те же командлеты выполняются локально и удаленно.
Чтобы подключиться к удаленному компьютеру, выполните следующий командлет:
Экспортируйте конфигурацию прослушивателя RDP с рабочего компьютера.
Чтобы импортировать конфигурацию прослушивателя протокола RDP, откройте окно PowerShell с разрешениями администратора на затронутом компьютере (или откройте окно PowerShell и подключитесь к этому компьютеру из удаленного расположения).
Чтобы создать резервную копию для существующей записи реестра, воспользуйтесь таким командлетом:
Чтобы удалить резервную копию для существующей записи реестра, воспользуйтесь таким командлетом:
Чтобы импортировать новую запись реестра и перезапустить службу, воспользуйтесь такими командлетами:
Замените именем экспортированного REG-файла.
Проверьте конфигурацию, попытавшись еще раз подключиться к удаленному рабочему столу. Если подключиться все равно не удается, перезагрузите затронутый компьютер.
Проверка состояния самозаверяющего сертификата протокола RDP
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 отозванных сертификатов.
За статьи спасибо, но не нашел в них решения своей проблемы.
Из статей, ссылки на которые Вам дал ранее, следует, что для того что бы Клиент мог проверить легитимность предъявляемого ему Сертификата, необходимо или в ручную установить СОС (Список Отзыва Сертификатов) или обеспечить Клиенту, OCSP проверку Сертификата.
Установите на Клиенте вручную, СОС сертификата, которого проверяет Клиент, проверьте и напишите результат.
СОС необходимо устанавливать в Промежуточные центры сертификации.
Руководствуясь разделом Q9 справки, загрузите в общедоступную папку SkyDrive, публичный Сертификат (cer-файл) компьютера Windows 8.
По 2 части я не понял, что это за СОС. Знаю только СОС, который публикуется ЦС в соответствии с настройками CDP.
Минимум же, первым в цепочке в Путь сертификации, должен быть SERVER-CA.TC-SOTKA.INT.
2. Список отзыва данного Вами сертификата, не доступен по указанному в сертификате адресу:
Выпущенный Вами сертификат для Windows 8, на этом компьютере в таком случае должен быть установлен в Корневые центры сертификации и Личные Сертификаты.
На компьютере Клиенте с Windows 7, он должен быть установлен в Корневые центры сертификации, список отзыва сертификатов для которых, не проверяется. Что неправильно.
2. Он недоступен у Вас, потому что это внутренний адрес. В данный момент решил вопрос добавлением записи в файл hosts. У клиента доступ к сайту по имени работает.
Внимательно изучите серию статей:
Именно по этой статье я настраивал публикацию СОС.
Жук, спасибо за желание помочь и с наступающим.
Ради интереса попробуй следующие:
В 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 добавлен в доверенные корневые центры сертификации).
Как я и говорил и сам не ас. Поэтому буду очень рад ответам. И если заодно посоветуешь где на клиенте более подробные логи этого всего посмотреть буду очень благодарен?
Отключение NLA для протокола RDP в Windows
Если на стороне RDP сервера, которому вы подключаетесь, включен NLA, это означает что для преаутентификации RDP пользователя используется CredSPP. Отключить Network Level Authentication можно в свойствах системы на вкладке Удаленный доступ (Remote), сняв галку «Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети / Allow connection only from computers running Remote Desktop with Network Level Authentication (recommended)» (Windows 10 / Windows 8).
В Windows 7 эта опция называется по-другому. На вкладке Удаленный доступ нужно выбрать опцию «Разрешить подключения от компьютеров с любой версией удаленного рабочего стола (опасный) / Allow connections from computers running any version of Remote Desktop (less secure)».
Также нужно в политике «Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP» (Require use of specific security layer for remote (RDP) connections) выбрать уровень безопасности (Security Layer) — RDP.
Для применения новых настроек RDP нужно обновить политики (gpupdate /force) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.
Как убрать назойливое предупреждение о сертификате для RDP
Привет Хабр, это супер короткое и простое руководство для новичков о том, как подключаться по RDP по доменному имени, чтобы не вылезало назойливое предупреждение о сертификате, подписанным самим сервером. Нам понадобится WinAcme и домен.
Все, кто хоть раз пользовался RDP, видели эту надпись.
В руководстве приведены готовые команды для пущего удобства. Скопировал, вставил и заработало.
Так вот, это окно можно в принципе пропустить, если выдать сертификат подписанный сторонним, трастовым центром сертификации. В данном случае, Let’s Encrypt.
Другие способы устранить ошибку цепочки сертификатов
В следующем окне вы должны увидеть сообщение о предварительной регистрации.
Нажмите на соответствующую ссылку и введите данные в форму предварительной регистрации. Подтвердите лицензионное соглашение, и вы получите ссылку на скачивание пакета программы.
Проверка состояния протокола RDP
Сведения о том, как проверить и изменить состояние протокола RDP на локальном компьютере, см. в разделе How to enable Remote Desktop (Как включить удаленный рабочий стол).
Проверка состояния протокола RDP на удаленном компьютере
Чтобы проверить и изменить состояние протокола удаленного рабочего стола на удаленном компьютере, используйте подключение сетевого реестра:
Проверка блокировки объектом групповой политики протокола RDP на локальном компьютере
Если не удается включить протокол RDP в пользовательском интерфейсе или для fDenyTSConnections возвращается значение 1 после его изменения, объект групповой политики может переопределять параметры на уровне компьютера.
Чтобы проверить конфигурацию групповой политики на локальном компьютере, откройте окно командной строки с правами администратора и введите следующую команду:
Когда команда будет выполнена, откройте файл gpresult.html. Выберите Конфигурация компьютераАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовПодключения и найдите политику Разрешить пользователям удаленное подключение с использованием служб удаленных рабочих столов.
Если для параметра этой политики задано значение Включено, групповая политика не блокирует подключения по протоколу RDP.
Если же для параметра этой политики задано значение Отключено, проверьте результирующий объект групповой политики. Ниже показано, какой объект групповой политики блокирует подключения по протоколу RDP.
Проверка блокировки объектом групповой политики протокола RDP на удаленном компьютере
Чтобы проверить конфигурацию групповой политики на удаленном компьютере, нужно выполнить почти такую же команду, что и для локального компьютера.
Изменение блокирующего объекта групповой политики
Эти параметры можно изменить в редакторе объектов групповой политики (GPE) и консоли управления групповыми политиками (GPM). Дополнительные сведения об использовании групповой политики см. в статье Advanced Group Policy Management (Расширенное управление групповыми политиками).
Чтобы изменить блокирующую политику, используйте один из следующих методов.
Предыдущая статья Следующая статья
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 они точно такие же, но при этом все прекрасно работает.
Спасибо Вам за Ваш вопрос.
2. Убедитесь, что URL-адрес rdweb работает нормально.
3. Выдан ли сертификат шлюза удаленных рабочих столов доверенным государственным органом, например Thawte, GeoTrust, Comodo, GoDaddy, DigiCert и т. Д., Или он из другого источника, например внутреннего центра сертификации?
4. Также это может произойти, если время клиентского компьютера и время RD Server не синхронизированы. Если у вас есть домен AD, они синхронизируют время с вашим контроллером домена PDC для всех ваших серверов и клиентских ПК.