Не удается подключиться к удаленному компьютеру поскольку сертификат сервера шлюза у

Не удалось проверить не был ли отозван этот сертификат rdp windows 7

Привет!, а Вас не смутило, то что Вы допустили две ошибки:

-вопросу уже более полутора лет;

-Автор вопроса, не Вы.

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

Начните с внимательного изучения серии статей, начав со статьи «Краткое руководство по 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 добавлен в доверенные корневые центры сертификации).

Как я и говорил и сам не ас. Поэтому буду очень рад ответам. И если заодно посоветуешь где на клиенте более подробные логи этого всего посмотреть буду очень благодарен?

Устранение ошибки проверки подлинности RDP

8 мая 2018 г. Microsoft выпустило обновление, которое предотвращает удаленное выполнение кода с помощью уязвимости в протоколе CreedSSP.

После установки данного обновление пользователи не могут подключиться к удаленным ресурсам посредством RDP или RemoteApp. При подключении происходит такая ошибка:

Не удается подключиться к удаленному компьютеру поскольку сертификат сервера шлюза у

Появление ошибки обусловлено установкой данных обновлений безопасности:

В данной статье мы рассмотрим варианты исправления данной ошибки.

Вариант №1: Убираем проверку подлинности.

Заходим в свойства компьютера, переходим на вкладку Удаленный доступ и снимаем галку с чекбокса.

Не удается подключиться к удаленному компьютеру поскольку сертификат сервера шлюза у

Вариант №2 (рекомендуемый): Обновление клиентских и серверных ОС.

Устанавливаем специально выпущенные патчи обновления, которые закрыли уязвимость в RDP-клиенте. Данные обновления можно посмотреть на сайте Microsoft. После установки данного обновления, мы обновляем CredSSP.

Читать также:  Можно ли купить квартиру на сертификат молодая семья у родственников

Вариант №3: Через групповые политики.

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

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

Вариант №4. Редактирование реестра.

Локально заходим на устройство, к которому пытаемся подключиться и нажимаем Win+R. Вводим regedit. После того, как откроется редактор реестра идем по следующему пути:

После выполнения данных действий с реестром выполняем перезагрузку устройства.

Нужна помощь в настройке RDP-подключений? Обращайтесь к нам!

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

Сообщения: 12 Благодарности:

Сообщения: 425 Благодарности: 72

если порт отвечает снаружи, соединение должно проходить

нужно тогда больше информации с клиента смотрите логи по службе RDP

вы к серверу подключаетесь через шлюз?

то есть у вас 2 сервера, шлюз к которому вы изначально подключаетесь через HTTPS, и сам сервере терминалов?

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

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

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

Не удалось подключиться к удаленному компьютеру поскольку сертификат сервера шлюза просрочен

Этот форум закрыт. Спасибо за участие!

Лучший отвечающий

Пробовал поднять службы сертификации Active Directory на шлюзе, создать сертификат, картина та же 🙁

Ответы

на самом деле тут не всё так просто как кажется. Даже если вы решите проблему доверия корневому сертификату, у вас появится другая проблема — сертификат не сможет быть проверен на отзыв извне (из интернета) и снова случится фейл. Следовательно, я тут вижу 2 приемлемых варианта.

1) Простой и дорогой

Если вы планируете использовать только один (или несколько, но не более 10) сертификат для шлюза — проще будет купить сертификат у коммерческого CA.

2) сложный и относительно дешёвый.

Если вы планируете массово использовать сертификаты в своей организации и работе — придётся самостоятельно установить и сконфигурировать центры сертификации. Вот пример, как это можно сделать:

Путь долог и тернист, но весьма полезный. ————————————————————— И напоследок прокомментирую некоторые высказывания в этом топике:

это не минимальные усилия. Особенно, если в лесу несколько доменов. Тогда придётся создавать эту политику в *каждом* домене. Вместо этого проще сертификат опубликовать в AD:

в таком случае все компьютеры *леса* будут доверять этому корневому сертификату.

эмм..а зачем в PFX? Надо просто в CER.

неправильная последовательность. Чтобы установить корневой сертификат на изолированную рабочую станцию надо сделать:

1) запустить MMC.EXE с правами администратора

2) добавить оснастку Certificates с фокусом на *учётную запись компьютера*.

3) добавить сертификат в Trusted Root CAs

это вы заблуждаетесь и сильно. Сертификаты выпускаемые центром сертификации под управлением Windows Server 2003 ничем не отличаются от Windows Server 2008 или от центров сертификации VeriSign.

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

Сервер RDP находится за маршрутизатором. На маршрутизаторе был проброшен 403 порт.

Захожу по адресу https://хх.хх.хх.хх/RDWeb/,

Программы не запускаются, а скачиваются *.rdp файлы.

Через эти файлы программы не запускаются, так как в них указан удаленный компьютер и сервис шлюза в формате ServerName.DomainName.

Как исправить ситуацию?

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

Удаленный компьютер- внешний IP?

Шлюз тоже внешний IP?

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

Обратитесь к администратору сети за помощью.

Здравствуйте. Пытаюсь поднять RDS, столкнулся с проблемой.

Все необходимые роли службы удаленных рабочих столов заведены на одном сервере. Доменное имя сервера внутри сети server.mydomen.com совпадает с «внешним» доменным именем. Настроил веб-доступ к удаленным рабочим столам, личные рабочие столы для пользователей и тд.

Если так же заходить снаружи, не из домена, ошибка следующая:

Удаленному рабочему столу не удалось подключиться к удаленному компьютеру «server.mydomen.com» по одной из этих причин: 1) Данной учетной записи пользователя не предоставлены права на доступ к шлюзу удаленных рабочих столов «server.mydomen.com» 2) Данный компьютер не авторизован для доступа к шлюзу удаленых рабочих столов «server.mydomen.com» 3) Используется несовместимый метод проверки подлинности (например, шлюз удаленных рабочих столов ожидает смарт-карту, а предоставлен пароль)

Переустановил роль rdg, перенастроил точно так же. В итоге получил ещё одну ошибку (в дополнение к трём существующим):

4. В группе «Пользователи удаленного рабочего стола» на сервере узла сеансов удаленных рабочих столов должны присутствовать пользователи или группы домена.

После этого на клиенте через rdweb появилась уже другая ошибка:

«При отправке данных на сервер шлюза удаленных рабочих столов произошла ошибка. Сервер временно недоступен или не работает сетевое подключение.»

Нашел в интернете про CredSSP (ОС MS WinXp SP3) и установил _http://support.microsoft.com/kb/951608 Всё заработало.

ПС: давно не работал с виндовс, совсем забыл про актуальность шутки:

Едут в машине таксист, бизнесмен и программист. Вдруг машина ломается. Таксист говорит: — Давайте мотор смотреть. Бизнесмен: — Да ладно, давай тачку поймаем. Программист: — А давайте все выйдем и снова войдем, может, она заработает?

Все ответы

При этом политики диспетчера шлюза удаленных рабочих столов:

Политики авторизации подключений

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

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. Политики есть и они включены.

3. Сертификат действительный. http://s017.radikal.ru/i415/1211/22/687a1425a3e0.png

Точно такие же проблемы на форуме видел, но решения там не было.

General discussion

Прочитал похожие темы и «тот самый блог Вадима.»

Все сделал как описано.

Пытаюсь из одной подсети(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

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 Проверка подлинности сервера

Проверка отзыва сертификата выполнена

Итак, сертификат 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

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

Ошибка «Не удалось подключиться к удалённому компьютеру, поскольку сертификат сервера шлюза удалённых рабочих столов отозван или просрочен».

При этом Windows 10 (8, 7) этот сертификат (выданный доменным Центром сертификации) не просрочен и подключение в этих ОC происходит без проблем. В хранилище Доверенные корневые центры сертификации (локальный компьютер) сертификат доменного ЦС есть.

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

Пока нагуглил, что какие-то проблемы с Службой времени Windows в этой ОС. В Просмотре событий очень много 158 кодов про ошибку VMICTimeProvider. Вместе с тем, время в трее показывается актуальное, синхронизация с сервером времени time.windows.com происходит успешно.

Кто-нибудь сталкивался с подобной проблемой? Нашлось решение?

Буду признателен за любую помощь по существу проблемы.

Скорее всего на WIN11 старый TLS запрещен или его можно включить.

Спасибо, что ответили. Я уж думал, что я один с такой проблемой столкнулся. Я создал обращение в техподдержку MS, сегодня ко мне подключались специалисты, смотрели и недоумевали, обещали подключить спецов уровнем выше. Можно поинтересоваться, а какая у Вас версия Windows на Шлюзе удалённых рабочих столов? У меня 2008R2.

Есть такая же проблема, шлюз 2008R2. На самом деле по ошибкам time-service мы ничего не определим т.к. на ОС Win10 они точно такие же, но при этом все прекрасно работает.

Спасибо Вам за Ваш вопрос.

2. Убедитесь, что URL-адрес rdweb работает нормально.

3. Выдан ли сертификат шлюза удаленных рабочих столов доверенным государственным органом, например Thawte, GeoTrust, Comodo, GoDaddy, DigiCert и т. Д., Или он из другого источника, например внутреннего центра сертификации?

4. Также это может произойти, если время клиентского компьютера и время RD Server не синхронизированы. Если у вас есть домен AD, они синхронизируют время с вашим контроллером домена PDC для всех ваших серверов и клиентских ПК.

Question

Не удается подключиться к удаленному компьютеру поскольку сертификат сервера шлюза у

В связи с недавними обновлениями безопасности 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 снова работает 🙂

Вы так конкретно и доступно всё описали, что до меня наконец-то дошло почему не удаётся подключиться к удалённому компу. Спасибо за помощь!

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

Ошибка ‘Ваш компьютер не может подключиться к серверу шлюза удаленных рабочих столов’, Когда вы не можете подключиться к удаленной системе. Причиной ошибки, по-видимому, является использование HTTP / UDP-соединения клиентом удаленного рабочего стола. Клиент удаленного рабочего стола время от времени получает обновления от Microsoft, и они обычно предлагают более новую версию с выпуском новой Windows. С течением времени они также выпустили поддержку RDP-соединений по HTTP.

Не удается подключиться к удаленному компьютеру поскольку сертификат сервера шлюза у

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

Что вызывает ошибку «Ваш компьютер не может подключиться к серверу удаленного рабочего стола» в Windows 10?

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

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

Создайте новый ключ реестра ‘RDGClientTransport’

Решение указанной проблемы довольно простое и понятное. Вам просто нужно добавить новый ключ DWORD в реестр Windows с именем ‘RDGClientTransport». Это заставляет клиента RDP использовать соединение RPC-HTTP через соединение HTTP / UDP. Вот как добавить ключ:

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

Причина

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

Не удаётся подключиться к RDP через шлюз?

Пробовал подключаться с двух разных компьютеров, которые территориально находятся совсем в разных местах (разные провайдер, IP и пр.). На обеих стоит Windows 7 x64 uk-UA (без SP, без обновлений), оба настраивались и используются мной. Нет даже предположений, в чём проблема. Какой-то софт, либо сделанные мной настройки, или ещё что.

Ну и, собственно, вопрос. Что не так и что делать? Как локализовать проблему? Чем мои компьютеры так уникальны и не нравятся шлюзу?

Четверг, 29 сентября 2016 г.

Не удается подключиться к удаленному компьютеру поскольку сертификат сервера шлюза у

Поиск виновника «торжества» привел к обновлению, известному как Windows 10 Anniversary Update, повышающему версию ОС до 1607. При этом, судя по всему, проблеме подвержены в основном ПК под управлением 32-х битной версии ОС. К сожалению долгий поиск официального решения данной проблемы ни к чему не привел, поэтому пришлось воспользоваться найденными на просторах сети «костылями», а именно подменой проблемного RDP клиента и соответствующей ему системной библиотеки с версии 10.0.14393.187 (Windows 10 build 1607) на версию 10.0.10586.589 (Windows 10 build 1511).

Для этого необходимо:

Все службы RDS установлены на одном сервере W2012.

Все работает в пределах домена, есть пользователи в удаленной сети (другая подсеть+VPN до офиса).

Через Rdp-сессию сидят без проблем.

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

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

Если вы поставили галки, то этого происходить не должно.

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

На машинках в какой сети возникает ошибка?

Какая версия клиентских ОС?

Используется ли у вас шлюз для внутренних сетей?

Если True, то авторизация для пользователей внутри сети на шлюзе не происходит.

На машинах из внешки.

в основном 7х64. и та с корой надо заставить работать тоже.

насчет шлюза не понял? филиал выходит в инет через другого провайдера. между роутерами впн-канал(ходят на файл шару, 1с.) впринципе именно 1с в remoteapp и не работает.

развернуты службы удаленных рабочих столов.

сейчас залез в свойства развертывания

Попробуйте с включенной галкой обновить подключение RemoteApp

Какой сертификат у вас используется?

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

Значит у вас используется дефолтный самоподписный сертификат.

Когда вы подключаете RemoteApp вы прописываете путь подключения к серверу в виде

Соединение по https, соответственно нужен сертификат.

Если у вас есть доменный центр сертификации рекомендую выдать сертификат для вашего сервера.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *