- Шаг 0. Исходные данные. Схема решения.
- Шаг 1. Установка основных ролей (Connection Broker + Web Access + Session Hosts).
- Шаг 2. Настройка высокой доступности Посредника подключений (Connection Broker High Availability).
- Шаг 3. Настройка высокой доступности Веб доступа (Web Access High Availability)
- Шаг 4. Настройка высокой доступности Шлюза удаленных рабочих столов (RD Gateway + Web Access High Availability).
- Шаг 5. Настройка использования сертификатов для служб удаленных рабочих столов.
- Шаг 6. Настройка сервера Лицензий (КВ Licensing).
- Шаг 7. Создание и настройка коллекции приложений.
- Шаг 8. Использование Дисков Профилей Пользователей (UPD). Настройка высокой доступности.
После установки ролей Connection Broker, Web Access, Session Host и Gateway крайне рекомендуется выполнить настройку сертификатов служб для обеспечения доверенного шифрованного соединения к удаленным приложениями. Вариантов использования сертификатов как обычно 3:
- использовать самоподписанный, который придется установить на все машины с которых будет происходить подключение.
- использовать выданный доменным центром сертификации. Для этого, естественно, потребуется развернутый доменный центр сертификации. Все доменные машины будут доверять выданному сертификату. Если же машина, с которой происходит подключение, находится не в домене, то на неё придется установить корневой сертификат центра сертификации.
- использовать коммерческий (3rd party), который, исходя из названия, придется приобрести за деньги.
Плюсы и минусы использования любого из них очевидны. Я, все же, рекомендую, если есть возможность использовать коммерческий сертификат (в т.ч. wildcard), это позволит избежать проблем доверия сертификата, т.к. подавляющее большинство машин должно ему доверять, независимо от того находится машина в домене или нет.
Однако, в данном случае, я рассмотрю вариант использования сертификата, выданного доменным центром сертификации. Задача получить сертификат типа .pfx. Для этого сначала нужно подготовить запрос, самый простой способ, сделать его с имеющегося сервера с установленной ролью IIS. В данном случае все тот же RDCB1. В диспетчере служб IIS нужно перейти на «Сертификаты сервера» на начальной странице узла. Далее «создать запрос сертификата«.
В запросе надо указать CN имя сертификата RD.alekssh.com и заполнить остальные поля.
Выбрать длину ключа 2048. И сохранить запрос в виде текстового файла.
Далее перейти на веб страницу выдачи сертификатов, в данном случае 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.«
Далее вставить текст запроса из полученного текстового файла в поле Saved Request и выбрать «Web Server» в поле Certificate Template.
Далее скачать выданный сертификат .cer
Теперь надо завершить запрос сертификата, для этого из Диспетчера служб IIS на том же сервере RDCB1 надо запустить «Запрос установки сертификатов».
Выбрать полученный сертификат .cer и указать имя будущего сертификата .pfx. Затем завершить выпуск сертификата, нажав OK.
По итогам выпуска получится сертификат типа .pfx. Теперь его надо экспортировать для использования в ферме серверов.
Указать папку для сохранения экспортируемого файла и пароль, с которым этот сертификат будет сохранен.
Для назначения сертификата службам удаленных рабочих столов нужно открыть Диспетчер серверов и выбрать «Изменить свойства развертывания».
Далее назначить службам сертификат выбрав существующий, только что экспортированный сертификат .pfx с указанием пароля.
Далее применить конфигурацию.
Сертификат успешно назначен.
Повторить шаги для остальных служб.
Сертификаты служб настроены.
Далее настройка сервера лицензирования.
Информация, используемая в этой статье:
http://technet.microsoft.com/ru-ru/library/cc732906(v=ws.10).aspx
- Шаг 0. Исходные данные. Схема решения.
- Шаг 1. Установка основных ролей (Connection Broker + Web Access + Session Hosts).
- Шаг 2. Настройка высокой доступности Посредника подключений (Connection Broker High Availability).
- Шаг 3. Настройка высокой доступности Веб доступа (Web Access High Availability)
- Шаг 4. Настройка высокой доступности Шлюза удаленных рабочих столов (RD Gateway + Web Access High Availability).
- Шаг 5. Настройка использования сертификатов для служб удаленных рабочих столов.
- Шаг 6. Настройка сервера Лицензий (КВ Licensing).
- Шаг 7. Создание и настройка коллекции приложений.
- Шаг 8. Использование Дисков Профилей Пользователей (UPD). Настройка высокой доступности.
Alexander Shestakov
как быть в случае с несколькими узлами сеансов удаленных рабочих столов? посредник, веб-доступ — на одном компе
НравитсяНравится
Расскажите подробнее в чем вопрос?
НравитсяНравится
есть server windows 2012 r2. на нем установлены роли посредник, веб-доступ, лицензирования, узел сеансов. создаю по вашей статье сертификат pfx. в свойствах развертывания указываю его у всех ролей (кроме шлюз). в iis соотвественно тоже.
есть server1 windows 2012 (на hyper-v) на нем установлена лишь роль узла сеансов.
создаю 2 коллекции в каждой по 1 узлу сеансов. в каждой коллекции публикую 1 программу.
в rdweb вижу 2 иконки, скачиваются 2 rdp файла.
прога на server — открывается нормально.
на server1 — выдается сообщение, что программа отсутствует в списке разрешенных remoteapp программ. притом подключение производится к server.
rdp-файл генерируется неправильно.
я подумал, что это связано с сертификатами для RDS
НравитсяНравится
забыл уточнить. что если переустановить роль rds на server уже без сертификатов. то подключение производится нормально за исключением того, что выдается сообщение о недоверенном подключении rdp
НравитсяНравится
не ваш ли случай? https://social.technet.microsoft.com/Forums/ru-RU/dd4be1d1-354e-4d0d-9183-1b9a031fbc5f/remoteapp-?forum=WS8ru
НравитсяНравится
нет. не мой.
у меня вопрос в чем: если есть 2 узла сеансов, один посредник и один сервер с веб-доступом. то сертификаты в свойствах развертывания я задаю одинаковый для посредник включение единого входа в систему, посредник публикация и веб-доступ?
НравитсяНравится
У вас один сервер к которому обращаются пользователи, для него и нужен сертификат. Для второго узла сеансов отдельный сертификат не нужен, да и назначить отдельно не получится. Посредник будет перенаправлять подключения на нужный узел сеансов. Действительно ли есть необходимость в двух коллекциях?
НравитсяНравится
В ASA можно воспользоваться несколькими командами группы show в командной строке для проверки статуса сертификата.
НравитсяНравится
Какие FQDN нужно указать при заказе ком. сертифката ?
Хотим использовать один сертификат для всех и вся 🙂
вайлкард — не предлагать 🙂
я пока нашел 3 имени: RD GW + RD CB + RD WA — ничего не забыл ?
НравитсяНравится
Я так понимаю вам нужен коммерческий сертификат для внешнего доступа. Для терминальной фермы, как для публикации веб доступа, RemoteApp так и RD Gateway достаточно одного имени, того, к которому будут осуществляться подключение. В моем случае внешнее имя rd.alekssh.com.
НравитсяНравится
Кстати, wildcard прекрасно работает 🙂
НравитсяНравится
Отличные статьи! собираю на виртуалках подобную схему. Прошел шаги 0-4. На пятом понял, что нужен «доменный центр сертификации» Разрозненная информацию есть на многих сайтах. С удовольсвием почитал-бы ваше дополнение к этому циклу статей. Размышления о том с какими ролями совмещать роль центра сертификации, как обеспечить высокодоступность.
НравитсяНравится
Спасибо. В данном случае, центр сертификации развернут на контроллере домена, настроны роли CA и CA Web Enrollment. Если же есть необходимость настроить центр сертификации, что называется, «по-взрослому», с оффлайновым корневым центром и прочим, то очень рекомендую цикл статей Вадима Поданса https://www.sysadmins.lv/blog-ru/ustanavlivaem-certification-authority-podvedenie-itogov.aspx если рекомендовать то лучшее 🙂
НравитсяНравится
Спасибо за оперативный ответ! сейчас как раз читал https://www.sysadmins.lv/blog-ru/obsuzhdenie-shem-ierarhii-certification-authority.aspx
НравитсяНравится
Здравствуйте! Пытаюсь реализовать что-то похожее, но по упрощенной схеме: КД и сервер удаленных рабочих столов + роль РДП шлюза на нем же. Есть купленное доменное имя типа 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
НравитсяНравится
Хороший цикл. Но всё же, применительно к нему не лишним бы было и описание настройки Центра сертификации и Веб службы регистрации сертификатов. Чтобы была логически понятная цепочка, что для чего и откуда берётся.
НравитсяНравится
Спасибо. Да как-то руки не доходят 🙂
НравитсяНравится
Добрый день,
Поднята ферма. 4 узла. На двух — брокер, лицензирование, шлюз. На двух других — сессионные хосты.
Проверяю на опубликованных приложениях.
Внутри все работает при снятой галке «не использовать шлюз для локальных пользователей». Проходит авторизация, получаю список, открываю и запускаю нужное.
Снаружи — авторизовываюсь, получаю список, открываю ПО и получаю «не удалось подключиться к удаленному компьютеру так как сервер шлюза удаленных рабочих столов недоступен».
ДНС-имена опубликованы верно, сертификаты валидные.
Помогите пожалуйста найти причину.
НравитсяНравится
Добрый день, шлюз опубликован наружу?
НравитсяНравится
Все получилось установить, но выходит ошибка https://pp.userapi.com/c841022/v841022685/69758/0RUhGXcYPR8.jpg
НравитсяНравится
Проверьте на какой срок выдан сертификат и есть ли к нему доверие.
НравитсяНравится
Проблему решил фиксом от MS
https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in
НравитсяНравится
Добрый день!
поднята RDS на windows 2012 r2+доменный CA. Сертификат получил доменный через iis. выгрузил в pfx, назначил в свойствах развертывания посредникам и для веб-доступа.
через rdweb скачал ярлык к этой программе. на клиентах через gpo задал отпечаток сертификата.
но все равно получаю сообщение: убедитесь что издатель надежен.
что упускаю?
НравитсяНравится