Windows Server 2012 R2 Remote Desktop – сертификаты

Как я уже писал 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 сильно упрощает настройку сертификатов особенно для решений с большим числом терминальных серверов. При этом она работает удобным образом и для небольших развертываний. Классическая модель сохранена, но настройка поддерживается только через командную строку.

Реклама