Windows Server 2008 R2: Сертификаты определяют безопасность подключений к удаленным рабочим столам. Часть 2

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

Сертификаты нужно использовать во всех службах роли RDS. Вот, что нужно знать для установки сертификатов для каждой серверной роли с помощью локальных инструментов или групповой политики. Сначала нужно сконфигурировать параметры безопасности всех серверов узлов сеансов удаленных рабочих столов на вкладке General окна свойств средства прослушивания протокола в средстве конфигурирования удаленных рабочих столов. Для этого надо выбрать Administrative Tools/Remote Desktop Services/Remote Desktop Session Host Configuration. После этого надо дважды щелкнуть RDP-Tcp в разделе Connections в средней панели. Здесь добавляется серверный сертификат SSL.

Эти параметры можно конфигурировать индивидуально для отдельных серверов. Эти параметры можно также средствам групповых политик, применяя следующий набор параметров объекта групповой политики (GPO) к подразделению сервера узлов сеансов удаленных рабочих столов в узле Computer Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Security:

• Установить уровень шифрования для клиентских подключений
• Требовать использования специального уровня безопасности для удаленных подключений по методу RDP
• Шаблон сертификата проверки подлинности сервера
• Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети

Проверка подлинности на уровне сети

По умолчанию проверка подлинности на уровне сети (NLA) необязательна. Чтобы она требовалась при подключении к серверу узлов сеансов удаленных рабочих столов, нужно установить соответствующий флажок. Это не позволит подключиться к серверу клиентам, не поддерживающим NLA (а именно клиентам с RDC версии более ранней, чем 6.x, и под управлением ОС, не поддерживающей CredSSP). CredSSPOnly поддерживают только клиенты под управлением Windows 7, Windows Vista и Windows XP SP3.

Проверка подлинности сервера

Параметры проверки подлинности сервера настраиваются в разделе Security Layer. По умолчанию выбран вариант Nego¬tiate, который означает, что для аутентификации сервера клиент и сервер используют протокол TLS, если он поддерживается.

Можно изменить этот параметр, чтобы проверка подлинности сервера выполнялась средствами TLS. Если проверка подлинности сервера не выполняется, определить поведение клиента можно на вкладке Advanced клиента удаленного рабочего стола:

• Не подключаться, если проверка не прошла
• Предупреждать, если проверка не прошла
• Подключаться, даже если проверка не прошла

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

Сертификат должен содержать DNS-имя сервера узлов сеансов удаленных рабочих столов, например rdsh1.domain.local. Если развернута ферма серверов, сертификат должен содержать DNS-имя сервера узлов сеансов удаленных рабочих столов фермы, например farm.domain.local.

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

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

Подписывание личных ВМ и ВМ в пулах

Подписывание личные ВМ или ВМ в пулах можно, установив сертификат SSL на посреднике подключений к удаленным рабочим столам средствами Диспетчера подключений к удаленным рабочим столам (рис. 1).

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

Подписывание приложений RemoteApps

RemoteApps подписывают с использованием сертификата, установленного на диспетчере RemoteApp на сервере узлов сеансов удаленных рабочих столов (рис. 2).

Рис. 2. Можно также подписывать приложения RemoteApps, для чего используеться сертификат в диспетчере удаленных приложений RemoteApp

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

Для этого нужно экспортировать сертификат вместе с закрытым ключом с сервера. Импортируйте сертификат, используя MMC-оснастку Certificates (Сертификаты), добавив при этом учетную запись компьютера, а не пользователя.

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

1. Сеанс, в котором устанавливается сертификат на посреднике подключений к удаленным рабочим столам называется Virtual Desktops: Resources and Configuration (Виртуальные рабочие столы: ресурсы и настройка). Устанавливаемый сертификат не только используется для подписания ВМ инфраструктуры виртуальных рабочих столов, но также применяется в процессе единого входа для интернет-решений для подписания приложений RemoteApps, когда используется посредник подключений к удаленным рабочим столам. Сертификаты подписания в посреднике и диспетчере RemoteApp серверов узлов сеансов удаленных рабочих столов должны совпадать иначе единый вход для интернет-решений работать не будет.
2. Если при запуске RemoteApp сертификат на посреднике отличается от сертификата на серверах узлов сеансов удаленных рабочих столов, единый вход для интернет-решений не работает. При этом никакой информации о различии сертификатов не предоставляется. В открывающемся окне показан только набор сертификатов в диспетчере RemoteApp, поэтому сложно узнать, что проблема в сертификатах.

Подробнее о настройке единого входа для интернет-решений см. веб-страницу «Introducing Web Single Sign-On for RemoteApp and Desktop Connections» по адресу

Защита сайта веб-доступа к удаленным рабочим столам

Безопасность сайта веб-доступа обеспечивается стандартными средствами. Для этого нужно добавить на IIS-сервер сертификат с DNS-именем сайта веб-доступа к удаленным рабочим столам (рис. 3).

Рис. 3. Добавление сертификата с именем DNS позволяет защитить сайт веб-доступа к удаленным рабочим столам

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

Настройка сертификата на шлюзе удаленных рабочих столов

При установке шлюза удаленных рабочих столов нужен сертификат, который будет использоваться для шифрования связи между клиентом и сервером, особенно при связи через Интернет. Этот сертификат SSL должен содержать DNS-имя сервера шлюза удаленных рабочих столов, которое будут получать в результате разрешения имен внешние пользователи (это должно быть внешнее DNS-имя, например rdgateway.domain.com).

Установка сертификата шлюза удаленных рабочих столов выполняется на вкладке SSL Certificate свойств диспетчера шлюза удаленных рабочих столов (рис. 4). Подробнее о сертификатах шлюза удаленных рабочих столов см. в библиотеке TechNet статью.

Рис. 4. Установка сертификата шлюза удаленных рабочих столов

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

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

Вопрос: Как устанавливать на сервер сертификаты, которые я мог бы использовать в службах удаленных рабочих столов (RDS)?

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

1. Откройте консоль MMC, выполнив команду mmc.
2. Добавьте оснастку Certificates (File, Add/Remove Snap-ins).
3. Последовательно выберите Choose Computer Account и Add, после чего щелкните OK.
4. Перейдите к папке Personal, а затем к Certificates.
5. Щелкните папку правой кнопкой и выберите Import, чтобы импортировать сертификат, полученный в центре сертификации.

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

Вопрос: Как отключить все сообщения-предупреждения, отображаемые при запуске подписанного RDP-файла?

Ответ: Включите параметр политики. Задайте SHA1-отпечатки сертификатов, представляющих доверенных издателей RDP-файлов. При включении этой политики задаются сертификаты, которые клиент будет считать доверенными. Если клиент доверяет сертификату, все RDP-файлы, подписанные этим сертификатом считаются доверенными. В этом случае никаких предупреждений с предложением подтвердить доверие издателю не отображается. Подробнее см. веб-страницу.

Вопрос:  Я установить правильные сертификаты на свои серверы узлов сеансов удаленных рабочих столов, но подключиться все равно не удается.

Ответ: Существует немного известных проблем с сертификатами в применении с реализацией служб RDS:

1. Похоже, что неполадки возможны при использовании сертификатов SGC (Server Gated Cryptography). Используйте другие сертификаты. Подробнее см. следующие статьи на форуме по RDS: http://social.technet.microsoft.com/Forums/ru-ru/w7itpronetworking/thread/b6545e0e-8a86-4b44-a118-0489fe76fdd1 и http://social.technet.microsoft.com/Forums/ru-ru/winserverTS/thread/12258c68-df6e-432f-932b-22f014e8d4c5.
2. Если подключающиеся клиенты получают ошибку «The certificate is not valid for this usage.» (Данный сертификат не подходит для такого использования.), цепочка сертификата сервера узлов сеансов удаленных рабочих столов может быть слишком длинной. Подробнее см. статью.

Вопрос: Можно ли в службах RDS использовать групповой сертификат или сертификат SAN?

Ответ: Да, такое возможно. Сертификат SAN содержит несколько имен узлов, поэтому его можно использовать в нескольких местах, где требуется сертификат. Примером сертификата SAN может быть сертификат, содержащий DNS-имена вашего шлюза удаленных рабочих столов и сервера веб-доступа к удаленным рабочим столам, а также имя, используемое для подписания файлов RemoteApp:

• rdgateway.domain.com
• rdweb.domain.com
• sign.domain.com

При использовании групповых сертификатов для реализации типичной фермы потребуется всего два сертификата. Ферма узла сеансов удаленных рабочих столов должна ссылаться на DNS-имя фермы, это обычно внутреннее DNS-имя (domain.local). Это не то же самое, что внешняя DNS-зона (domain.com), поэтому для этого вам потребуется отдельный сертификат.

Вопрос: На моем сервере установлено несколько серверных ролей. Нужно ли мне устанавливать сертификаты во всех службах ролей, которые у меня используются?

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