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

Обновлено: 03.07.2024

Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.

Нужно указывать имя сервера по которому вы обращаетесь к серверу из интернета. »

Имя чего?? Компьютера? Так не подойдет! Во первых собственного имени в сети интернет машина не имеет. Есть IP, но он может быть динамическим? Непонятно!

Кроме того когда данный сертификат переноситься на другой комп, путь сертификации в нем меняется на имя сервера!

Вот выдержка о создании такого сертификата с сайта microsoft:
"На странице Создание самозаверенного сертификата введите понятное имя сертификата в поле Понятное имя сертификата и нажмите кнопку ОК."

Неужели никто еще шлюз для RDP без домена не настраивал?

Последний раз редактировалось ZOOBR, 15-09-2010 в 15:32 .

Конфигурация компьютера
Процессор: Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz, 2266
Материнская плата: HP Pavilion dv6 Notebook PC
Память: 3072MB
HDD: 431GB
Видеокарта: NVIDIA GeForce G105M
CD/DVD: hp DVDRAM GT30L
Монитор: SEC3651, 15.3" (34cm x 19cm)
ОС: Windows 7 Pro x64
Индекс производительности Windows: 4,9
Прочее: HP Pavilion dv6 Notebook PC

Файл сертификатов шлюза (с открытым ключом) RDP можете привести?

Имя чего?? Компьютера? Так не подойдет! Во первых собственного имени в сети интернет машина не имеет. Есть IP, но он может быть динамическим? Непонятно! »

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

-------
Мы овладеваем более высоким стилем спора. Спор без фактов. Спор на темпераменте. Спор, переходящий от голословного утверждения на личность партнера. (c)Жванецкий

Сертфикат хоста всегда содержит DNS-имя или IP-хоста. »

Об этом я уже слышал, но я пробовал именно с IP сервера и ничего не получил. И тогда также напрашивается вопрос как быть если доступ на сервер идет с нескольких сетей? На входе то IP разные, а в настройках шлюза можно указать только один сертификат. Ну это ладно, хоть с одним бы заработал.

Файл сертификатов шлюза (с открытым ключом) RDP можете привести? »

Да пожалуйста, если это чем-то поможет! Выложил сертификат во вложении в форматах cert и prx(пароль на prx: 123). Сертификат самозаверенный. В качестве имени использую адрес сервера в локалке! Тестирую соответственно пока тоже в локалке на VMware.

Как по вашему, без имени или адреса, клиент проверит, что сервер является тем за кого себя выдает? »

В случае самозаверенного сертификата его копия передается на сторону клиента и по идее должно и так работать (так гласит microsoft)! А вот в случае доменного сертификата так действительно не получиться!

Списибо конечно за ссылку, но там немного не о том, а именно к Windows Server 2008 отношения не имеет. Да и если честно во всех этих книгах много теории и 0 практики. Меня интересует всего лишь один вопрос. Как правильно создать и потом использовать сертификат для доступа к шлюзу RDP на сервере не являющемся контроллером домена. Инет перерыл и нигде толковой информации не нашел. Инструкции есть только для домена, где соответственно используют доменный сертификат, чего у меня нет! Может я конечно чего-то не понял и может можно как-то создать доменный сертификат для моего случая (хотя он требует сервер сертификации), но как это сделать я не знаю.
Поэтому и прошу помочь.

Вот здесь вполне удобоваримая статья по настройке шлюза RDP. Там есть раздел про создание сертификата, но применительно к домену.

Последний раз редактировалось ZOOBR, 15-09-2010 в 22:59 .

Конфигурация компьютера
Процессор: Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz, 2266
Материнская плата: HP Pavilion dv6 Notebook PC
Память: 3072MB
HDD: 431GB
Видеокарта: NVIDIA GeForce G105M
CD/DVD: hp DVDRAM GT30L
Монитор: SEC3651, 15.3" (34cm x 19cm)
ОС: Windows 7 Pro x64
Индекс производительности Windows: 4,9
Прочее: HP Pavilion dv6 Notebook PC

Это очень просто, в файле host на клиенте прописываете, то DNS имя которое указано в сертификате.
Если клиентов не много - эт овполне приемлемо.

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

Вы, путаете сертификат и для чего он нужен.

Расшифрую:
- Главная функция это аутентификация сервера на стороне клиента, т. е. клиент (точнее компьютер клиента) пытается убедится, что сервер является тем, за кого себя выдает, а не какая либо бяка вставшая посередине вашего трафика или просто подправившая DNS-разрешения.
Способов аутентификации сервера много, но прижились двое:
- preshared key
- сертификат сервера

Самозаверенность это способ подтверждения валидности (действительности) сертификата в дереве CA (центров сертификации).
Например сертификаты выпущеные корневыми CA всегда самоподписанные, т. к. нет более высокого уровня центров сертификации.
С самоподписанными сертификатами одна морока - ими тяжело управлять, однако если клиентов мало, можно и руками (как вы и сделали).

Кстати, если имя сервера разрешаемое (при помощи DNS) на стороне клиента, не совпадает с именем в предъявлямом сертификате, то и домен вам не поможет.
Домен хорош когда все, и клиенты и серверы в нем находятся ,т.е. распознавание имен у них происходит при помощи одного механизма - серверов имен домена.
Т. е. заранее есть гарантия, что имя под которым себя осознает сервер будет таким же на клиенте.

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

Сертифкаты везеде одинаковые.
В той же MS можно развернуть центр сертифкации интегрированный в домен и не интегрированный.
Интегрированным в домент просто гораздо проще управлять (например с помощью групповых политик), выпускать и отзывать сертификаты.
По рекомендации той же MS корневой CA всегда автономен, т.е. не интегрируется в домен.

Установить службу шлюза удаленных рабочих столов (шлюз RD) на компьютере под управлением Windows Server 2008 R2.

Существует несколько привязок сертификат на порт 443 этого компьютера.

В этом случае шлюз удаленных рабочих Столов может работать неправильно. Некорректное поведение зависит от привязки выбранного сертификата имя хранилища сертификатов. Имя различные проблемы привязки вызывает хранилища сертификата следующие значения:

Имя хранилища сертификатов не равно NULL для привязки

В этом случае все соединения проходят за исключением в следующих случаях:

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

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

Имя хранилища сертификатов для привязки равно NULL

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

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

В командной строке введите следующую команду и нажмите клавишу ВВОД:

Проверьте значение из первой привязки, который прослушивает порт 443 Имя хранилища сертификатов . Значение (null) , указывает имя хранилища сертификатов для данной конкретной привязки равно NULL.

Причина

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

Решение

Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.

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

Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Чтобы получить полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание, посетите следующий веб-сайт корпорации Майкрософт:

http://support.microsoft.com/contactus/?ws=supportПримечание. В форме "Пакет исправлений доступен для скачивания" отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.

Предварительные условия

Для установки этого исправления компьютер должна быть запущена Windows Server 2008 R2.

Необходимость перезагрузки

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

Сведения о замене исправлений

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

Сведения о файлах

Английская версия данного исправления содержит атрибуты файла (или более поздние атрибуты файлов), приведенные в следующей таблице. Дата и время для этих файлов указаны в формате общего скоординированного времени (UTC). При просмотре сведений о файле, он преобразуется в локальное время. Чтобы узнать разницу между временем по Гринвичу и местным временем, следует использовать
Часовой пояс
вкладке
Дата и время
элемент панели управления.

В данном руководстве мы рассмотрим развертывание роли шлюза удаленных рабочих столов (Remote Desktop Gateway или RDG) на отдельном сервере с Windows Server 2019. Действия будут аналогичны для Windows Server 2012 и 2016 (даже, в основных моментах, 2008 R2). Предполагается, что в нашей инфраструктуре уже имеются:

1. Служба каталогов Active Directory — настроено по инструкции Как установить роль контроллера домена на Windows Server.

Пошагово, мы выполним следующие действия:

Установка роли

Открываем Диспетчер серверов:

Переходим в Управление - Добавить роли и компоненты:

При появлении окна приветствия нажимаем Далее (при желании, можно поставить галочку Пропускать эту страницу по умолчанию):

На страницы выбора типа установки оставляем выбор на Установка ролей или компонентов:

Выбираем целевой сервер — если установка выполняется на сервере локально, то мы должны увидеть один сервер для выбора:

Ставим галочку Службы удаленных рабочих столов:

Дополнительные компоненты нам не нужны:

. просто нажимаем Далее.

На странице служб удаленных рабочих столов идем дальше:

Выбираем конкретные роли — нам нужен Шлюз удаленных рабочих столов. После установки галочки появится предупреждение о необходимости поставить дополнительные пакеты — кликаем по Добавить компоненты:

Откроется окно для настроек политик:

. нажимаем Далее.

Откроется окно роли IIS:

. также нажимаем Далее.

При выборе служб ролей веб-сервера ничего не меняем:

В последнем окне ставим галочку Автоматический перезапуск конечного сервера, если требуется:

Нажимаем Установить:

Дожидаемся окончания установки роли:

Сервер может уйти в перезагрузку.

Настройка RDG

Для настройки Microsoft Remote Desktop Gateway мы создадим группу компьютеров в Active Directory, настроим политику для RDG и создадим сертификат.

Создание групп для терминальных серверов

Политика ресурсов позволит задать нам конкретные серверы, на которые терминальный шлюз позволит нам подключаться. Для этого мы откроем консоль Active Directory - Users and computers (Пользователи и компьютеры Active Directory) и создаем группу:

* в данном примере мы создаем группу All terminals в организационном юните Servers Group. Это группа безопасности (Security), локальная в домене (Domain local).

Добавим в нашу группу терминальные серверы:

* в данном примере у нас используются два сервера — Terminal-1 и Terminal-2.

Закрываем консоль Active Directory - Users and computers.

Настройка политик

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

В диспетчере сервера переходим в Средства - Remote Desktop Services - Диспетчер шлюза удаленных рабочих столов:

Раскрываем сервер - кликаем правой кнопкой по Политики - выбираем Создание новых политик безопасности:

Устанавливаем переключатель в положении Создать политику авторизации подключений к удаленным рабочим столам и авторизации ресурсов удаленных рабочих столов (рекомендуется):

Даем название политике:

Задаем параметры авторизации:

* мы указали, что пользователи должны подтверждать право вводом пароля, также мы указали, что для применения политики они должны принадлежать группе Domain Users.

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

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

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

В следующем окне мы увидим вне введенные настройки:

Откроется страница создания политики для авторизации ресурса — задаем для нее название:

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

* как и при создании первой политики, мы добавили группу Domain Users.

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

* мы выбрали группу, созданную нами ранее в AD.

Указываем разрешенный для подключения порт или диапазон портов:

* в данном примере мы разрешим подключение по порту 3389, который используется по умолчанию для RDP.

Нажимаем Готово:

Политики будут созданы.

Настройка сертификата

Запускаем «Диспетчер шлюза удаленных рабочих столов» - кликаем правой кнопкой по названию нашего сервера - выбираем Свойства:

Переходим на вкладку Сертификат SSL:

Выбираем вариант Создать сомозаверяющий сертификат и кликаем по Создать и импортировать сертификат:

Задаем или оставляем имя для сертификата - нажимаем OK:

Мы увидим информацию о создании сертификата:

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

Сервер готов к работе.

Подключение к серверу терминалов через шлюз

Выполним первое подключение с использованием шлюза. В качестве клиентской операционной системы могут использоваться Windows, Linux, Mac OS. Рассмотрим пример на Windows 10.

Запускаем «Подключение к удаленному рабочему столу» (приложение можно найти в Пуск или ввести команду mstsc). На вкладке Общие вводим локальное имя конечного сервера, к которому мы хотим подключиться:

* в нашем случае мы будем подключаться к серверу terminal-1.dmosk.local.

Переходим на вкладку Дополнительно и кликаем по Параметры:

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

* важно указать именно имя сервера, а не IP-адрес. В моем примере имя сервера rdp.dmosk.local (данное имя не является правильным внешним, но это только пример).

Кликаем Подключить:

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

Переходим на вкладку Состав и кликаем Копировать в файл:

Указываем путь для выгрузки файла:

Открываем папку, куда сохранили сертификат. Кликаем по сохраненному файлу правой кнопкой и выбираем Установить сертификат:

Выбираем Локальный компьютер - Далее:

В качестве размещения сертификата выбираем Доверенные корневые центры сертификации:

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

Система запросит логин и пароль для подключения (возможно, дважды) — вводим данные для учетной записи с правами на подключение (на основе настройки политики RDG).

Настройка Remoteapp через Gateway

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

gatewayhostname:s:rdg.dmosk.local — добавленная строка. Настройка говорит, что если при подключении к серверу нужно использовать шлюз, то это должен быт rdg.dmosk.local.
gatewayusagemethod:i:1 — отредактированная строка. Указывает, что необходимо использовать шлюз.

Несколько терминальных серверов и dns round robin

При наличие нескольких серверов терминалов, мы можем создать несколько записей в DNS, чтобы получать по round robin разные серверы:

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

Выбираем нужную группу компьютеров и нажимаем Свойства:

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

На вкладке Сетевые ресурсы добавляем имя, созданное в DNS:

Теперь подключение будет выполняться без ошибок.

Возможные ошибки

При подключении мы можем столкнуть со следующими ошибками.

1. Учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов.

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

3. Сертификат шлюза удаленных рабочих столов просрочен или отозван.

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

09.07.2020

Windows 10, Windows Server 2016, Групповые политики

комментариев 18

В этой статье мы покажем, как использовать доверенные SSL/TLS сертификаты для защиты RDP подключений к компьютерам и серверам Windows в домене Active Directory. Эти сертфикаты мы будем использовать вместо самоподписанных RDP сертификатов (у пользователей появляется предупреждение о невозможности проверки подлинности при подключению к RDP хосту с таким сертификатом). В этом примере мы настроим специальный шаблон для выпуска RDP сертификатов в Certificate Authority и настроим групповую политику для автоматического выпуска и привязки SSL/TLS сертификата к службе Remote Desktop Services.

Предупреждение о самоподписанном сертификате RDP

По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный

сертификат. В результате при первом подключении к RDP/RDS серверу через клиента mstsc.exe, у пользователя появляется предупреждение:

При этом отпечаток RDP сертификата сохраняется на клиенте в параметре CertHash в ветке реестра с историей RDP подключений (HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers\). Если вы скрыли уведомление о невозможности проверить подлинность RDP сервера, чтобы сбросить настройки, удалите ключ с отпечатком сертификата из реестра.

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

Создаем шаблон RDP сертификата в центре сертификации (CA)

Попробуем использовать для защиты RDP подключений доверенный SSL/TLS сертификат, выданный корпоративным центром сертификации. С помощью такого сертификата пользователь может выполнить проверку подлинности RDP сервера при подключении. Предположим, что у вас в домене уже развернут корпоративной центр сертификации (Microsoft Certificate Authority), в этом случае вы можете настроить автоматическую выдачу и подключение сертификатов всем компьютерам и серверам Windows в домене.

Н на вашем CA нужно создать новый тип шаблона сертификата для RDP/RDS серверов.

Настройка групповой политики для выдачи RDP сертификатов

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

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

Откройте консоль управления доменными групповыми политиками gpmc.msc, создайте новый объект GPO и назначьте его на OU с RDP/RDS серверами или компьютерами, для которых нужно автоматически выдавать TLS сертификаты для защиты RDP подключения;
Перейдите в раздел GPO: Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security. Включите политику Server Authentication Certificate Template. Укажите имя шаблона CA, который вы создали ранее (RDPTemplate);
Затем в этом же разделе GPO включите политику Require use of specific security layer for remote (RDP) connections и установите для нее значение SSL;
Для автоматического продления RDP сертификата, перейдите в раздел GPO Computer configuration -> Windows settings -> Security Settings -> Public Key Policies и включите политику Certificate Services Client – Auto-Enrollment Properties. Выберите опции “Renew expired certificates, update pending certificates and remove revoked certificates” и “Update certificates that use certificate templates”;
Если вы хотите, чтобы клиенты всегда проверяли сертификат RDP сервера, вам нужно настроить политику Configure Authentication for Client = Warn me if authentication fails (секция GPO Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Settings -> Remote Desktop Connection Client);
Если нужно, можете через политики файервола открыть входящий RDP порт TCP/UDP 3389;
Осталось обновить политики на клиенте, запустить консоль сертификатов компьютера (Certlm.msc), и проверить, что в разделе Personal -> Certificates появился сертификат для Remote Desktop Authentication, выданный вашим CA.

Если политики не применились, для диагностики GPO воспользуйтесь утилитой gpresult и этой статьей.

Для применения нового RDP сертификата, перезапустите службу Remote Desktop Services:

Get-Service TermService -ComputerName msk-dc01| Restart-Service –force –verbose

Также можете в консоли Certification Authority в секции Issued Certificates проверить, что по шаблону RDPTemplate был выдан сертификат определённому Windows компьютеру/серверу. Также проверьте значение Thumbprint сертификата:

Теперь сравните полученные данные с отпечатком сертификата, который используется службой Remote Desktop Service. Вы можете посмотреть значение отпечатка сертификата службы RDS в реестре (ветка HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations, параметр TemplateCertificate) или командой PowerShell: Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices|select SSLCertificateSHA1Hash

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

Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата

Если у вас отсутствует CA, но вы хотите, чтобы при подключении к RDP/RDS серверу у пользователей не появлялось предупреждения, вы можете добавить сертификат в доверенные на компьютерах пользователей.

Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:

Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices|select|select SSLCertificateSHA1Hash

Используйте этот отпечаток для подписывания .RDP файла с помощью RDPSign.exe:

rdpsign.exe /sha256 65A27B2987702281C1FAAC26D155D78DEB2B8EE2 "C:\Users\root\Desktop\rdp.rdp"

Теперь через GPO добавим этот отпечаток сертификата в доверенные у пользователей. Укажите отпечатки (через точку с запятою) в политике Specify SHA1 thumbprints of certificates representing trusted .rdp publishers (Указать отпечатки SHA1 сертификатов, представляющих доверенных издателей RDP) в секции Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Settings -> Remote Desktop Connection Client.

Чтобы работал прозрачных RDP вход без ввода пароля (RDP Single Sign On), нужно настроить политику Allow delegation defaults credential и указать в ней имена RDP/RDS серверов (см. статью).

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

Какие преимущества дает нам защита RDP при помощи SSL? Во первых надежное шифрование канала, проверку подлинности сервера на основании сертификата и проверку подлинности пользователя на уровне сети. Последняя возможность доступна начиная с Windows Server 2008. Проверка подлинности на уровне сети позволяет повысить безопасность сервера терминалов за счет того, что проверка происходит еще до начала сеанса.

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

Для полноценного использования всех возможностей RDP через SSL клиентские ПК должны работать под управлением Windows XP SP3, Windows Vista или Windows 7 и использовать RDP клиент версии 6.0 или более поздней.

При использовании Windows Server 2003 SP1 и более поздних версий, будут доступны шифрование канала при помощи SSL (TLS 1.0) и проверка подлинности сервера, клиентские ПК должны иметь версию RDP клиента 5.2 или более позднюю.

В нашей статье мы будем рассматривать настройку терминального сервера на базе Windows Server 2008 R2, однако все сказанное будет справедливо и для Windows Server 2003 (за исключением отсутствующих возможностей).

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

Затем следует выполнить запрос сертификата подлинности сервера со следующими параметрами:

Если вы получали сертификат с помощью изолированного (автономного) ЦС (сеть не имеет доменной структуры) то он по умолчанию будет установлен в хранилище учетной записи пользователя и придется выполнить ряд дополнительных действий.

Произведите его экспорт. При экспорте укажите следующие опции:

Да, экспортировать закрытый ключ
Удалить закрытый ключ после успешного экспорта

Выберите необходимое подключение и откройте его свойства. В самом низу нажмите кнопку Выбрать и выберите полученный на предыдущем шаге сертификат (в Windows Server 2003 это окно выглядит несколько по другому).

После выбора сертификата укажите остальные свойства:

Сохраните введенный параметры, на этом настройка сервера закончена.

Чтобы данный ПК доверял сертификатам выданным нашим центром сертификации не забудьте установить на него сертификат ЦС в хранилище Доверенные корневые центры сертификации.

В Windows 7 (при использовании RDP клиента версии 7) данный сертификат требуется установить в хранилище учетной записи компьютера, для этого импортируйте его через оснастку Сертификаты (локальный компьютер) в консоли MCC, аналогично тому, как это делали выше. В противном случае подключение будет невозможно и вы получите следующую ошибку:

Установив сертификат ЦС можете пробовать подключиться, обратите внимание, что имя пользователя и пароль будет предложено ввести еще до создания RDP сессии. При успешном соединении обратите внимание на замок в заголовке окна, который свидетельствует о работе через SSL. Нажав на него можно просмотреть информацию о сертификате.

И напоследок капля дегтя в бочке меда. Терминальные службы Windows не умеют проверять подлинность подключающихся клиентов, поэтому если стоит такая необходимость следует использовать дополнительные методы защиты, такие как SSH туннель или IPSec VPN.

Я просто попытался удалиться на свой рабочий компьютер из дома и получил запрос «Личность не может быть проверена», как показано ниже. Я отметил поле «Не спрашивать меня снова для подключения к этому компьютеру», а затем случайно нажал «Нет» (не подключаться) вместо «Да». Теперь, когда я пытаюсь подключиться, он спрашивает меня о моем пароле, но потом он не подключается и возвращается к приглашению входа в RDC.

Как я могу отменить этот параметр? Я просмотрел оснастки MMC Certificates, но не нашел ничего похожего на мой рабочий компьютер. Я также попытался удалить Default.rdp, но в этом файле нет ничего существенного. Любая помощь очень ценится!

2 ответа

Откройте редактор реестра (regedit.exe)
Перейдите к HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientServers
Удалить информацию о подключении для компьютера, который вы хотите сбросить.

При следующем входе в систему введите имя и запрос вернется.

Я протестировал это.

Это сработало и для меня, и для Windows 7. Из-за этой проблемы мне не удалось войти в RDP.

Тут можно пойти двумя путями:

Если у вас есть AD CS и нет особых требований к именам, указываемым в сертификате. В этом случае можно сделать полностью автоматическую выдачу сертификатов и их подключение. Это простой способ.
Если у вас в домене нет центра сертификации Active Directory, или если у вас есть особые требования к Subject Name или Subject Alternative Name. В этом случае придется получать и подключать сертификат вручную. Понадобится подобный сценарий вам может, если, например вы выдаете сертификат для компьютера, находящегося в отказоустойчивом кластере, и соответственно вам нужно будет указать в качестве SAN или SN как имя кластера так и имя хоста.

Начнем с более простого сценария.

У вас уже должен быть установлен и настроен AD CS. Идем на компьютер где он установлен и создаем шаблон для сертификата, который будет использоваться при подключении по RDP. Для этого заходим в консоль Certification Authority и щелкаем правой кнопкой мыши на Ceritificate Templates, выбираем Manage.

В открывшемся окне щелкаем правой кнопкой мыши по шаблону компьютера и выбираем Duplicate Template.

В Compatibility, выбираем уровень CA и получателей, в зависимости от ваших нужд, я поставлю уровень CA и Certificate Recipient на уровень 2008R2.

Во вкладке General задаёмR понятное имя сертификату, например RDPTmpl, так же если хотите можете изменить время жизни и обновления сертификата, а также разрешить публикацию в AD. Я эти опции оставил как есть.

Во вкладке Subject Name по желанию можно выбрать Subject name format, например Common Name, так же обязательно оставьте, что бы публиковалось DNS имя в alternate subject name.

Идем во вкладку Sucurity – тут разрешаем Enroll и Autoenroll для группы компьютеров, для которых должен будет получаться сертификат.

Далее переходим во вкладку Extensions, выбираем Application Policy и жмем Edit.

Здесь нужно удалить Client Authorization, а так же по желанию можно заменить Server Authorization на политику для проверки подлинности RDP. Для этого жмем Add, далее New, в Object identifier вводим 1.3.6.1.4.1.311.54.1.2 и даем понятное имя политике, например Remote Desktop Authentication.

Выбираем созданную политику и удаляем из шаблона Client и Server Authorization.

Жмем ОК и закрываем консоль с шаблонами. Возвращаемся в консоль Certification Authority и снова жмем правой кнопкой по Certificate Templates и выбираем New -> Certificate Template to issue.

Выбираем созданный нами шаблон и жмем ОК.

Теперь идем в редактор групповой политики, создаем или правим существующий объект групповой политики, который прилинкован к OU в которой находятся компьютеры, которым необходимо получить сертификат. Идем в Computer configuration -> Administrative Templates -> Windows components -> Remote Desktop Services -> Security. Тут нам нужен параметр Server authentication certificate template.

Включаем его и указываем имя нашего шаблона (RDPTmpl).

Что бы сертификаты продлялись автоматически, идем в Computer configuration -> Windows settings -> Security Settings -> Public Key Policies. Тут включаем параметр Certificate Services Client – Auto-Enrollment Properties.

Всё дожидаемся, пока обновится групповая политика или обновляем ее сами (gpupdate /force), сервер должен будет получить сертификат, и при подключении по RDP будет использоваться именно этот сертификат. Проверить это можно подключившись к серверу не по доменному имени, а по IP адресу, например.

Если что, хранится этот сертификат в сертификатах компьютера, в личных сертификатах.

Теперь расскажу про то, что делать во втором случае. В общем и целом, сперва нам так, как и с первым случаем необходимо создать шаблон для сертификата. Тут всё точно так же, как и с первым случаем, за исключением вкладки Subject Name. В этот раз нужно выбрать Supply in the request. Так же, думаю лучше поставить галку, что бы при продлении бралась информация из существующего сертификата.

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

Щелкаем правой кнопкой по Личное и выбираем – запросить новый сертификат. На приветственном окне жмем далее. В окне выбора политики регистрации сертификатов оставляем Политику регистрации Active Direcotory.

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

Во вкладке объект указываем полное имя DN в качестве Subject Name (например CN = CL01.test.loc) и разные dns имена в качестве Alternate Subject Name.

Жмем далее, точнее кнопку Заявка, и дожидаемся окончания процесса.

Теперь нам необходимо каким-то образом подключить полученный сертификат к RDP. Тут опять же есть несколько способов.

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

Смотрим отпечаток в свойствах только что полученного сертификата.

Для упрощения его копирования можно воспользоваться командой powershell:

Копируем нужный отпечаток, далее выполняем команду:

Где thumbprint – ваш скопированный отпечаток.

Посмотреть отпечаток подключенного сертификата можно командой:

В случае, если у вас используется старая версия ОС, например Windows 2008R то можно воспользоваться более наглядным способом подключения. Это же касается и случаев, если у вас версия системы выше, чем 2012, и при этом установлены роли RDS.

Устанавливаем фичу Remote Desktop Services Tools. Если что она находится в Remote Server Administration Kit, Role Administration Tools.

Устанавливаем эти компоненты, после установки нужно будет перезагрузить сервер. После перезагрузки идем в Пуск – Администрирование – Службы удаленных рабочих столов – Конфигурация узла сеансов удаленных рабочих столов.

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

Всё. Теперь при подключении по RDP будет использоваться правильный сертификат.

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