Установка сертификата на удаленный компьютер
Обновлено: 05.07.2024
В этой статье описываются методы настройки сертификатов слушателей на сервере Windows Server 2012 или Windows Server 2012, который не является частью развертывания служб удаленного рабочего стола (RDS).
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 3042780
О доступности прослушиватель сервера удаленного рабочего стола
Компонент слушателя работает на сервере удаленного рабочего стола и отвечает за прослушивание и принятие новых подключений клиентов удаленного рабочего стола (RDP). Это позволяет пользователям создавать новые удаленные сеансы на сервере удаленного рабочего стола. Существует прослушиватель для каждого подключения удаленных настольных служб, которое существует на сервере удаленного рабочего стола. Подключения можно создавать и настраивать с помощью средства конфигурации служб удаленного рабочего стола.
Методы настройки сертификата слушателя
В Windows Server 2003 Windows Server 2008 или Windows Server 2008 R2 оснастка диспетчера конфигурации удаленного рабочего стола позволяет напрямую получать доступ к прослушивательу RDP. В оснастке можно привязать сертификат к слушателю и, в свою очередь, обеспечить безопасность SSL для сеансов RDP.
В Windows Server 2012 или Windows Server 2012 R2 этого оснастки MMC не существует. Таким образом, система не предоставляет прямой доступ к прослушивательУ RDP. Чтобы настроить сертификаты слушателя в Windows Server 2012 или Windows Server 2012 R2, используйте следующие методы.
Метод 1. Использование Windows инструментов управления (WMI)
Данные конфигурации для слушателя RDS хранятся в классе Win32_TSGeneralSetting WMI под Root\CimV2\TerminalServices пространством имен.
Сертификат для слушателя RDS ссылается на значение Thumbprint этого сертификата в свойстве SSLCertificateSHA1Hash. Значение отпечатка пальца является уникальным для каждого сертификата.
Перед запуском команд wmic сертификат, который необходимо использовать, должен быть импортироваться в хранилище персональных сертификатов для учетной записи компьютера. Если вы не импортируете сертификат, вы получите ошибку "Недействительный параметр".
Чтобы настроить сертификат с помощью WMI, выполните следующие действия:
Откройте диалоговое окно свойств для сертификата и выберите вкладку Details.
Прокрутите вниз в поле Thumbprint и скопируйте пространство, делимитированную гексадецимальной строкой, в нечто подобное Блокнот.
Следующий снимок экрана является примером отпечатка пальца сертификата в свойствах сертификата:
Если вы скопируете строку в Блокнот, она должна напоминать следующий скриншот:
После удаления пробелов в строке он по-прежнему содержит невидимый символ ASCII, видимый только в командной строке. В качестве примера приводится следующий снимок экрана.
Убедитесь, что этот символ ASCII удаляется перед запуском команды для импорта сертификата.
Удалите все пробелы из строки. Может быть невидимый символ ACSII, который также копируется. Это не отображается в Блокнот. Единственным способом проверки является копирование непосредственно в окно Командная подсказка.
В командной подсказке запустите следующую команду wmic вместе со значением отпечатка пальца, которое вы получите на шаге 3:
Следующий снимок экрана — успешный пример:
Метод 2. Использование редактора реестра
Точно следуйте всем указаниям из этого раздела. Внесение неправильных изменений в реестр может привести к возникновению серьезных проблем. Прежде чем изменить его, как восстановить и восстановить реестр в Windows в случае возникновения проблем.
Чтобы настроить сертификат с помощью редактора реестра, выполните следующие действия:
Установите сертификат проверки подлинности сервера в хранилище персональных сертификатов с помощью учетной записи компьютера.
Создайте следующее значение реестра с хешом SHA1 сертификата, чтобы можно было настроить этот пользовательский сертификат для поддержки TLS вместо использования самозаверяемого сертификата по умолчанию.
- Путь реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
- Имя значения: SSLCertificateSHA1Hash
- Тип значения: REG_BINARY
- Данные значения: отпечатки сертификатов
Значение должно быть отпечатком пальца сертификата и разделяться запятой (,) без пустых пробелов. Например, если вы экспортируете этот ключ реестра, значение SSLCertificateSHA1Hash будет следующим образом:
Служба удаленного рабочего стола выполняется в учетной записи NETWORK SERVICE. Поэтому необходимо настроить список управления доступом к системе (SACL) ключевого файла, используемого RDS, чтобы включить NETWORK SERVICE вместе с разрешениями на чтение.
Чтобы изменить разрешения, выполните следующие действия на оснастке Сертификаты для локального компьютера:
В этой статье мы покажем, как использовать доверенные 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 сертификата в центре сертификации (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.
Для применения нового 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 серверов (см. статью).
Многие компании используют инфраструктуру VDI для организации удаленной работы с неуправляемых компанией персональных станций. При публикации фермы VDI в интренет, внешние пользователи сталкиваются с проблемой недоверия к сертификату, который был выпущен корпоративным центром сертификации. В следствии этого, появляются предупреждения безопасности при установке удаленного подключения.
В данном случае, предупреждение появляется дважды: первый раз не доверенным является Connection Broker сервер, а второй – виртуальная машина фермы VDI.
Для решения поставленной проблемы необходимо использовать «белый» сертификат, выписанный доверенным Certificate Authority для фермы VDI. Имя данного внешнего сертификата и имена компьютеров VDI должны совпадать.
РЕШЕНИЕ ПРОБЛЕМЫ
Добавление нового DNS Суффикса в домене:
Следующую политику необходимо включить и добавить через запятую значения внутреннего доменного имени и внешнего доменного имени: Computer Configuration \ Policies \ Administrative Templates \ Network \ DNS Client\ DNS suffix search list.
Установка сертификата на RD сервера
Далее создаем новую ферму VDI, основываясь на выбранных серверах Microsoft Windows Server 2012 R2. Информацию по данной процедуре можно легко найти в сети.
После того, как pfx файл сертификата будет на руках, можно приступить к установке его на новую VDI ферму. На сервере RD Connection Broker переходим Server Manager -> Remote Desktop Services -> Overview. В поле Deployment Overview в выпадающем списке TASKS выбираем Edit Deployment Properties.
После чего данные сертификаты будут установлены на серверах VDI, но не на виртуальных машинах. В реестре на Connection Broker сервере появится SSLCertificateSHA1Hash REG_BINARY параметр со значением thumbprint сертификата по следующему адресу:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp.
Данный параметр отвечает за выбор сертификата, который будет использоваться при установке RDP сессии. Это параметр необходимо будет установить и на клиентские машины.
Установка сертификата на виртуальные машины
Для использования белого сертификата на виртуальных машинах необходимо:
Данная политика должна выполнить Startup Script ExportVDICert.bat на виртуальных машинах.
В указанном скрипте используются утилиты certutil и FindPrivateKey от Microsoft. Certutil является встроенной утилитой, FindPrivateKey предоставляется в качестве Samle tool для разработчиков и может быль скомпилирован самостоятельно. Скрипт необходимо расположить внутри политики.
Сертификат и утилиту FindPrivateKey необходимо разместить в сетевой папке, откуда скрипт будет забирать файлы для установки. Текст скрипта:
При помощи данного скрипта после перезагрузки виртуальной машины будет установлен новый сертификат и для него будут настроены права.
Следующая часть политики касается установки параметра SSLCertificateSHA1Hash. Необходимый ключ настраивается через Preferences \ Windows Settings \ Registry
После перезагрузки, машина получит новый FQDN, соответствующий белому сертификату. После проведения данных операций, пользователи больше не увидят надоедливые предупреждения безопасности.
В данном руководстве мы рассмотрим развертывание роли шлюза удаленных рабочих столов (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. Также нужно убедиться, что привязанный сертификат, на самом деле, не просрочен или отозван. В крайнем случае, можно заново создать сертификат.
Читайте также: