Сертификат для rdp windows server 2012

Как я уже писал Windows Server 2012 R2 Remote Desktop – теперь две модели есть два способа настройки Remote Desktop Services. Это также касается сертификатов.

Как мы настраиваем сертификаты в классической модели. Когда стартует сервис RDS, он проверяет наличие сертификата, если его нет, то либо получает сертификат из Certification Authority леса, либо создает самоподписанный сертификат. И наконец, мы можем получить сертификат из внутреннего CA вручную, либо взять коммерческий сертификат и назначить такой сертификат сервису RDS вручную. Автоматический и ручной методы описаны в статье Configuring Remote Desktop certificates. В Windows Server 2012 R2 отсутствует GUI для настройки RDS в классической модели. Это касается и сертификатов: нужно использовать командную строку для назначения сертификатов сервису RDS.

Теперь рассмотрим практические сценарии. Если у вас один-два терминальных сервера, то совсем не трудоёмко назначить им сертификат вручную. Даже можно использовать самоподписанный сертификат: только его необходимо будет распространить на клиентские компьютеры с помощью GPO.  Если терминальных серверов больше, чем один-два, то хорошо помогает автоматическое назначение сертификатов внутреннего CA: клиенты им доверяют по умолчанию. А вот если у вас не просто терминальные серверы, а несколько ферм из нескольких серверов, то сертификаты не могут быть автоматически установлены: либо их надо копировать на все серверы и вручную назначать сервису RDS, либо делать тоже самое, но скриптом; ни о каком автоматическом продлении сертификата речи быть не может.

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

Что нам предлагает новая модель. Сертификаты больше не нужно ставить на терминальные серверы! В любом развертывании (deployment) есть брокер – сертификат (сертификаты) устанавливаются только на нем (или на двух брокерах, если они сконфигурированы в режиме High Availability). В новой модели сертификаты могут быть назначены брокеру через GUI или с помощью Powershell.

Почему так и как это работает. В новой модели брокер, коллекции и серверы в коллекциях это единое целое с точки зрения установления доверия. Клиент подключается к брокеру, производятся все проверки (аутентификация, авторизация, NLA), формируется токен подключения к конкретному серверу, после чего выполняется подключение к этому серверу без необходимости дополнительных проверок.

Можете оценить насколько это удобно. Вы настраиваете сертификат(-ы) один раз на брокере, после чего можете создавать любое количество коллекций с любым количеством серверов, на лету включать в коллекции дополнительные серверы – и все это без заботы о сертификатах.

Теперь собственно о сертификатах.

Новая модель требует 4 сертификата.

1.       RD Connection Broker – Single Sign On

– используется для аутентификации серверов. Точнее сказать в нем указывается FQDN имя развертывания (при одном брокере по умолчанию это его FQDN).

2.       RD Connection Broker – Publishing

– используется для подписи RDP файлов, чтобы пользователи не получали дополнительный вопрос о доверии. Соответствующее свойство сертификата должно быть включено при его создании. (В локальной сети для исключения окна уведомления о доверии нужно к тому же настроить GPO «Specify SHA1 thumbprints of certificates representing trusted .rdp publishers».)

3.       RD Web Access

– используется для аутентификации сервера RD Web и для включения RemoteApp and Connection Subscription – доставка на клиентские компьютеры ярлыков. Это типичный Web сертификат для IIS. В качестве FQDN указывается имя сервера или фермы RD Web Access.

4.       RD Gateway

– используется для аутентификации сервера RD Gateway.

Варианты использования сертификатов.

На практике все эти сертификаты это обычно один и тот же сертификат.

Использовать самоподписанные сертификаты неудобно: клиенты получают много дополнительных предупреждений и вопросов при подключении.

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

Сертификаты публичного CA. Клиенты внутри домена должны иметь возможность проверять CRL. Внешние клиенты и внутренние клиенты работают прозрачно и удобно.

Можно ли внутри использовать сертификаты внутреннего CA, а наружу опубликовать RD Web Access и RD Gateway с публичным сертификатом? Можно, но это усложнение решения и  к тому же прозрачной работы пользователей все равно не будет: можно опубликовать RD Web Access как вэб-сервер с публичным сертификатом, например, на TMG, и он будет прозрачно работать, теоретически тоже самое можно сделать с RD Gateway, но клиент в результате подключения все равно неявно получит RDP файл, который подписан внутренним сертификатом и ссылается на внутренние ресурсы с внутренним сертификатом, которому нужно доверять и который нужно проверять на отзыв – доверие к пограничным серверам не распространяется на ресурсы. Иначе говоря, число предупреждений и вопросов к клиенту будет меньше, чем при использовании только внутренних сертификатов, но они все равно будут.

Рекомендуемый (мной) сценарий – если нужен доступ извне, то использовать внутри и снаружи публичные сертификаты. Как частный случай, когда много клиентов работают извне – использовать один wildcard сертификат и Split DNS для RD Web Access и RD Gateway. Во-первых, клиенты работают прозрачно без лишних запросов. Во-вторых, используют для подключения одно и тоже имя.

В место заключения.

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

Filed under: Remote Desktop | Tagged: Certificates, Remote Desktop, Windows |

It turns out that much of the configuration data for RDSH is stored in the Win32_TSGeneralSetting class in WMI in the rootcimv2TerminalServices namespace. The configured certificate for a given connection is referenced by the Thumbprint value of that certificate on a property called SSLCertificateSHA1Hash.

UPDATE: Here’s a generalized Powershell solution that grabs and sets the thumbprint of the first SSL cert in the computer’s personal store. If your system has multiple certs, you should add a -Filter option to the gci command to make sure you reference the correct cert. I’ve left my original answer intact below this for reference.

# get a reference to the config instance
$tsgs = gwmi -class "Win32_TSGeneralSetting" -Namespace rootcimv2terminalservices -Filter "TerminalName='RDP-tcp'"

# grab the thumbprint of the first SSL cert in the computer store
$thumb = (gci -path cert:/LocalMachine/My | select -first 1).Thumbprint

# set the new thumbprint value
swmi -path $tsgs.__path -argument @{SSLCertificateSHA1Hash="$thumb"}

In order to get the thumbprint value

1. Open the properties dialog for your certificate and select the Details tab
2. Scroll down to the Thumbprint field and copy the space delimited hex string into something like Notepad
3. Remove all the spaces from the string. You’ll also want to watch out for and remove a non-ascii character that sometimes gets copied just before the first character in the string. It’s not visible in Notepad.
4. This is the value you need to set in WMI. It should look something like this: 1ea1fd5b25b8c327be2c4e4852263efdb4d16af4.

Now that you have the thumbprint value, here’s a one-liner you can use to set the value using wmic:

wmic /namespace:\rootcimv2TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="THUMBPRINT"

Or if PowerShell is your thing, you can use this instead:

$path = (Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace rootcimv2terminalservices -Filter "TerminalName='RDP-tcp'").__path
Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash="THUMBPRINT"}

Note: the certificate must be in the ‘Personal’ Certificate Store for the Computer account.

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

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

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

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

Не удалось проверить подлинность удаленного компьютер из-за проблем с сертификатом безопасности.
Ошибка сертификата: сертификат выдан не имеющим доверия центром сертификации.

Чтобы продолжить установление RDP подключении пользователь должен нажать кнопку Да. Чтобы RDP предупреждение не появлялось каждый раз, можно включить опцию “Больше не выводить запрос о подключениях к этому компьютеру».

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

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

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

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

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

1. Запустите консоль Certificate Authority и перейдите в секцию Certificate Templates;
2. Сделайте копию шаблона сертификата Computer (Certificate Templates -> Manage -> Computer -> Duplicate);
   
3. На вкладке General укажите имя нового шаблона сертификата – RDPTemplate. Убедитесь, что значение поля Template Name полностью совпадает с Template display name;
   
4. На вкладке Compatibility укажите минимальную версию клиентов в вашем домене (например, Windows Server 2008 R2 для CA и Windows 7 для клиентов). Тем самым будут использоваться более стойкие алгоритмы шифрования;
5. Теперь на вкладке Extensions в политике приложений (Application policy) нужно ограничить область использования такого сертификата только для Remote Desktop Authentication (укажите следующий object identifier — 1.3.6.1.4.1.311.54.1.2). Нажмите Add -> New, создайте новую политику и выберите ее;
   
6. В настройках шаблона сертификата (Application Policies Extension) удалите все политики кроме Remote Desktop Authentication;
7. Чтобы использовать данный шаблон RDP сертификатов на контролерах домена, откройте вкладку Security, добавьте группу Domain Controllers и включите для нее опцию Enroll и Autoenroll;
   
8. Сохраните шаблон сертификата;
9. Теперь в оснастке Certificate Authority, щёлкните по папке Certificate Templates, выберите New -> Certificate Template to Issue -> выберите созданный шаблон RDPTemplate.
   

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

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

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

1. Откройте консоль управления доменными групповыми политиками gpmc.msc, создайте новый объект GPO и назначьте его на OU с RDP/RDS серверами или компьютерами, для которых нужно автоматически выдавать TLS сертификаты для защиты RDP подключения;
2. Перейдите в раздел GPO: Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security. Включите политику Server Authentication Certificate Template. Укажите имя шаблона CA, который вы создали ранее (RDPTemplate);
   
3. Затем в этом же разделе GPO включите политику Require use of specific security layer for remote (RDP) connections и установите для нее значение SSL;
4. Для автоматического продления 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”;
   
5. Если вы хотите, чтобы клиенты всегда проверяли сертификат 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);
6. Если нужно, можете через политики файервола открыть входящий RDP порт TCP/UDP 3389;
7. Осталось обновить политики на клиенте, запустить консоль сертификатов компьютера (Certlm.msc), и проверить, что в разделе Personal -> Certificates появился сертификат для Remote Desktop Authentication, выданный вашим CA.

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

   

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

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

Теперь при RDP подключении к серверу перестанет появляться запрос на доверие сертификату (чтобы появился запрос о доверии сертификату, подключитесь к серверу по IP адресу вместо FQDN имени сервера, для которого выпущен сертификат). Нажмите кнопку “Посмотреть сертификат”, перейдите на вкладку “Состав”, скопируйте значение поля “Отпечаток сертификата”.

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

Теперь сравните полученные данные с отпечатком сертификата, который используется службой Remote Desktop Service. Вы можете посмотреть значение отпечатка сертификата службы RDS в реестре (ветка HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStations, параметр TemplateCertificate) или командой PowerShell:
Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace rootcimv2terminalservices|select SSLCertificateSHA1Hash

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

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

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

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

Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace rootcimv2terminalservices|select|select SSLCertificateSHA1Hash

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

rdpsign.exe /sha256 65A27B2987702281C1FAAC26D155D78DEB2B8EE2 "C:UsersrootDesktoprdp.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 серверов (см. статью).