Шаг 5. Настройка использования сертификатов для служб удаленных рабочих столов.


После установки ролей Connection Broker, Web Access, Session Host и Gateway  крайне рекомендуется выполнить настройку  сертификатов служб для обеспечения доверенного шифрованного соединения к удаленным приложениями. Вариантов использования сертификатов как обычно 3:

  • использовать самоподписанный, который придется установить на все машины с которых будет происходить подключение.
  • использовать выданный доменным центром сертификации. Для этого, естественно, потребуется развернутый доменный центр сертификации. Все доменные машины будут доверять выданному сертификату. Если же машина, с которой происходит подключение, находится не в домене, то на неё придется установить корневой сертификат центра сертификации.
  • использовать коммерческий (3rd party), который, исходя из названия, придется приобрести за деньги.

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

Однако, в данном случае, я рассмотрю вариант использования сертификата, выданного доменным центром сертификации. Задача получить сертификат типа .pfx. Для этого сначала нужно подготовить запрос, самый простой способ, сделать его с имеющегося сервера с установленной ролью IIS. В данном случае все тот же RDCB1. В диспетчере служб IIS нужно перейти на «Сертификаты сервера» на начальной странице узла. Далее «создать запрос сертификата«.

В запросе надо указать CN имя сертификата RD.alekssh.com и заполнить остальные поля.

RDCB1-2014-09-03 15_08_33-Запросить сертификат

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

RDCB1-2014-09-03 15_08_41-Запросить сертификат

Далее перейти на веб страницу выдачи сертификатов, в данном случае http://ca.lab.local/cersrv и пройти по пути «Request a certificate | Advanced certificate request | Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.«

RDCB1-2014-09-03 15_10_53-Microsoft Active Directory Certificate Services

Далее вставить текст запроса из полученного текстового файла в поле Saved Request и выбрать «Web Server» в поле Certificate Template.

RDCB1-2014-09-03 15_13_50-Microsoft Active Directory Certificate Services

Далее скачать выданный сертификат .cer

RDCB1-2014-09-03 15_13_57-

Теперь надо завершить запрос сертификата, для этого из Диспетчера служб IIS  на том же сервере RDCB1 надо запустить «Запрос установки сертификатов».

RDCB1-2014-09-03 15_14_36-Диспетчер служб IIS

Выбрать полученный сертификат .cer и указать имя будущего сертификата .pfx. Затем завершить выпуск сертификата, нажав OK.

RDCB1-2014-09-03 15_16_01-Запрос установки сертификатов

По итогам выпуска получится сертификат типа .pfx. Теперь его надо экспортировать для использования в ферме серверов.

RDCB1-2014-09-03 15_16_12-Диспетчер служб IIS

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

RDCB1-2014-09-03 15_16_50-Экспорт сертификата

Для назначения сертификата службам удаленных рабочих столов нужно открыть Диспетчер серверов и выбрать «Изменить свойства развертывания».

RDCB1-2014-09-03 15_16_12-Настройка Сертификатов

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

RDCB1-2014-09-03 15_20_24-Свойства развертывания

Далее применить конфигурацию.

RDCB1-2014-09-03 15_21_23-Свойства развертывания

Сертификат успешно назначен.

RDCB1-2014-09-03 15_22_36-Свойства развертывания

Повторить шаги для остальных служб.

RDCB1-2014-09-03 15_35_02-Свойства развертывания

Сертификаты служб настроены.

Далее настройка сервера лицензирования.


 

Информация, используемая в этой статье:

http://blogs.technet.com/b/askperf/archive/2014/01/24/certificate-requirements-for-windows-2008-r2-and-windows-2012-remote-desktop-services.aspx

http://technet.microsoft.com/ru-ru/library/cc732906(v=ws.10).aspx


Реклама

Об авторе Alexander Shestakov

MCITP, MCSE. Компания "Динамика"
Запись опубликована в рубрике RDS 2012 R2 с метками , , , . Добавьте в закладки постоянную ссылку.

18 комментариев на «Шаг 5. Настройка использования сертификатов для служб удаленных рабочих столов.»

  1. alexey:

    как быть в случае с несколькими узлами сеансов удаленных рабочих столов? посредник, веб-доступ — на одном компе

    Нравится

    • Расскажите подробнее в чем вопрос?

      Нравится

      • alexey:

        есть server windows 2012 r2. на нем установлены роли посредник, веб-доступ, лицензирования, узел сеансов. создаю по вашей статье сертификат pfx. в свойствах развертывания указываю его у всех ролей (кроме шлюз). в iis соотвественно тоже.

        есть server1 windows 2012 (на hyper-v) на нем установлена лишь роль узла сеансов.

        создаю 2 коллекции в каждой по 1 узлу сеансов. в каждой коллекции публикую 1 программу.

        в rdweb вижу 2 иконки, скачиваются 2 rdp файла.
        прога на server — открывается нормально.
        на server1 — выдается сообщение, что программа отсутствует в списке разрешенных remoteapp программ. притом подключение производится к server.
        rdp-файл генерируется неправильно.

        я подумал, что это связано с сертификатами для RDS

        Нравится

  2. alexey:

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

    Нравится

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

      Нравится

  3. В ASA можно воспользоваться несколькими командами группы show в командной строке для проверки статуса сертификата.

    Нравится

  4. Какие FQDN нужно указать при заказе ком. сертифката ?
    Хотим использовать один сертификат для всех и вся 🙂
    вайлкард — не предлагать 🙂
    я пока нашел 3 имени: RD GW + RD CB + RD WA — ничего не забыл ?

    Нравится

    • Я так понимаю вам нужен коммерческий сертификат для внешнего доступа. Для терминальной фермы, как для публикации веб доступа, RemoteApp так и RD Gateway достаточно одного имени, того, к которому будут осуществляться подключение. В моем случае внешнее имя rd.alekssh.com.

      Нравится

    • Кстати, wildcard прекрасно работает 🙂

      Нравится

  5. Евгений:

    Отличные статьи! собираю на виртуалках подобную схему. Прошел шаги 0-4. На пятом понял, что нужен «доменный центр сертификации» Разрозненная информацию есть на многих сайтах. С удовольсвием почитал-бы ваше дополнение к этому циклу статей. Размышления о том с какими ролями совмещать роль центра сертификации, как обеспечить высокодоступность.

    Нравится

  6. Александр:

    Здравствуйте! Пытаюсь реализовать что-то похожее, но по упрощенной схеме: КД и сервер удаленных рабочих столов + роль РДП шлюза на нем же. Есть купленное доменное имя типа qwerty.ru. Я так понимаю, что для внешнего доступа из интернетов желательно купить ССЛ-сертификат. Сертификат покупать на домен qwerty.ru или непосредственно на сам шлюз терминалов rd.qwerty.ru? Заранее благодарен!

    Нравится

    • Доброго дня, да, собственно, на шлюз, точнее на то имя которое будете использовать при публикации сервиса RD Gateway. rd.qwerty.ru вполне подойдет

      Нравится

      • Александр:

        Спасибо за ответ! Можно уточнение — ведь для доступа будет использоваться стандартная веб-морда типа https://qwerty.ru/rdweb с опубликованными приложениями, тогда ССЛ-сертификат потребуется и для нее, т.е. на сам сайт?

        Нравится

        • Для веб интерфейса должно быть имя. Смотрите, это 2 сервиса. Один это веб доступ, второй это шлюз. Оба они работают по 443 https порту по умолчанию, поэтому если планируется использовать оба сервиса, то в сертификате должно быть 2 имени. Например, rdweb.qwerty.ru и rdgw.qwerty.ru

          Нравится

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s