Remote Desktop Services — Строим отказоустойчивую ферму RD Connection Broker

Не будем заострять внимания на описании функций служб Remote Desktop Services, так как этой информации более чем достаточно в официальных источниках Microsoft. Предметом этой заметки будет пошаговое практическое описание процесса создания фермы из трёх виртуальных серверов, на каждом из которых будут совмещены компоненты RD Session Host и кластеризованная служба RD Connection Broker. То есть мы попробуем при минимуме серверных экземпляров Windows Server 2008 R2 собрать отказоустойчивое решение RDS.

По информации доступной из блога TechNet Blogs > Mark Ghazai’s Blog > Windows Server 2008 R2 Highly Available (Clustered) Remote Desktop Connection Broker на каждом из серверов в кластере RD Connection Broker будет использоваться локальная база с информацией о всех пользовательских сессиях в ферме и лишь одна из нод кластера будет иметь активный экземпляр этой БД, который будет использоваться при обслуживании пользовательских запросов всей этой фермы. В случае недоступности активной ноды БД перестроится на другом сервере и начнёт обслуживать запросы клиентов.


Среда исполнения

Три виртуальных сервера на базе Windows Server 2008 R2 Enterprise EN. Корпоративная редакция ОС потребуется нам из-за необходимости использования средств Windows Failover Clustering.

Каждый из серверов имеет по два сетевых интерфейса.

Серверам присвоены имена — KOM-AD01-RDS01 , KOM-AD01-RDS02 и KOM-AD01-RDS03.

Создаваемый в процессе описания кластерный экземпляр Windows Failover Clustering будет иметь имя KOM-AD01-RDSCL.

Кластеризованный экземпляр службы RD Connection Broker будет иметь имя KOM-AD01-RDCB

С точки зрения сетевого взаимодействия, упрощённая схема отказоустойчивой фермы RDS в нашем случае будет выглядеть так:

 


Настраиваем сетевые параметры

Итак, на каждом сервере мы имеем по два сетевых интерфейса. Назовём их NIC1Public и NIC2 – Cluster и условимся, что согласно нашей схемы, NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера) а NIC2 будет отвечать за работу сервера в кластере Windows Failover Cluster.

Выполним описанные ниже настройки на каждом из трёх серверов.

Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections).

 


NIC1 должен иметь приоритет над NIC2, то есть в списке подключений должен стоять первым.

 


Интерфейс NIC1 настроим обычным образом, задав ему IP адрес (согласно нашей схемы), маску подсети, IP адрес шлюза, адреса DNS серверов. Несколько иначе будет настроен интерфейс NIC2.

В свойствах кластерного интерфейса NIC2 можно отключить все компоненты, за исключением TCP/IP:

 


В свойствах компонента TCP/IP зададим только выделенный IP адрес и маску подсети. Кластерная подсеть должна отличаться от от подсети интерфейса NIC1 иначе в дальнейшем при создании кластера могут возникнуть проблемы с автоматическим созданием кластерных сетей. Также нужно понимать, что так как мы не указываем на этом интерфейсе адрес шлюза, все три сервера через этот интерфейс должны находиться в одном физическом сегменте сети.

Здесь же, по кнопке Advanced откроем окно дополнительных настроек

 


В окне дополнительных настроек TCP/IP на закладке DNS отключаем опцию регистрации этого подключения в DNS – Register this connection’s addresses in DNS

 


Как было сказано ранее, указанные настройки сетевых интерфейсов нужно сделать по аналогии согласно нашей схемы на всех трёх серверах.


Устанавливаем роль Remote Desktop Services

На каждом из серверов выполняем установку необходимых нам компонент роли Remote Desktop Services. Для этого в оснастке Server Manager (ServerManager.msc) в разделе Roles вызываем мастер добавления ролей действием Add Roles

 


В открывшемся окне мастера выбираем роль Remote Desktop Services

 


Далее нам будет предложено выбрать соответствующие службы роли. Отмечаем Remote Desktop Session Host и Remote Desktop Connection Broker

 


На следующем шаге нужно выбрать режим аутентификации. Учитывая то, что в нашем окружении нет устаревших клиентов не поддерживающих NLA, выбираем рекомендуемый метод – Require Network Level Authentication

Значение этой настройки, как и всех других в этом мастере можно будет в изменить позже в любое время после установки роли с помощью оснасток управления RDS

 


На шаге выбора режима лицензирования выбираем опцию Configure later , так как для конфигурирования параметров режима лицензирования наших терминальных серверов мы в дальнейшем будем использовать возможности доменных групповых политик.

 


На шаге выбора групп добавим заранее созданную доменную группу безопасности, в которую будут включаться пользователи имеющие потребность в доступе к ресурсам расположенным на серверах создаваемой фермы RDS. После установки роли на сервере будет создана специальная локальная группа безопасности Remote Desktop Users в которую и будут включены выбранные нами на этом шаге группы

 


На следующем шаге мы сможем включить признак установки поддержки расширенных медиа компонент. Под Desktop Experience понимается установка дополнительных пользовательских компонент в составе:

  • Windows Calendar
  • Windows Mail
  • Windows Media Player
  • Desktop themes
  • Video for Windows (AVI support)
  • Windows Photo Gallery
  • Windows SideShow
  • Windows Defender
  • Disk Cleanup
  • Sync Center
  • Sound Recorder
  • Character Map
  • Snipping Tool

В многопользовательской среде должен быть взят за правило принцип необходимого минимума приложений и поэтому, следуя этому принципу мы не будем устанавливать этот «винегрет».

 


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

 


Включаем поддержку кластеров — Failover Clustering

На каждом из серверов выполняем установку компоненты для возможности работы с кластером — Failover Clustering. Для этого в оснастке Server Manager (ServerManager.msc) в разделе Features вызываем мастер добавления возможностей действием Add Features

 


В открывшемся окне мастера добавления возможностей выбираем Failover Clustering

 


Создаём кластер

На любом из трёх серверов, например на сервере KOM-AD01-RDS01 открываем оснастку Failover Cluster Manager (Cluadmin.msc) и в меню действий Action выбираем пункт создания нового кластера – Create a Cluster

 


В открывшемся мастере создания кластера добавляем все три сервера которые мы планируем включить в будущий кластер

 


На следующем шаге мастера укажем имя и IP адрес выделенный для администрирования кластера. Нужно учесть, что здесь задается не то имя, которое будет использоваться для подключения клиентов RDS, а то которое необходимо для обслуживания самого кластерного экземпляра Windows Server 2008 R2, на который мы в последствии будем добавлять кластеризованную службу RD Connection Broker.

 


Далее, исходя из нашей конфигурации, мастером будет автоматически создан кластер с моделью кворума большинства узлов — Node Majority. Это значит, что наш кластер будет оставаться в работоспособном состоянии (принимать запросы от клиентов) только в том случае, если будет доступно минимум два серверных узла из трёх. Такая модель кластера снимает требование к общему кластерному диску и мы можем получить дополнительный уровень абстрагирования от физической среды с использованием FC/SAS/iSCSI

 


В процессе создания кластера в домене должна быть создана его учетная запись (cluster name object) и выполнена регистрация указанного имени в DNS.

Настраиваем кластерные ресурсы

После того как экземпляр кластера создан, нам нужно настроить кластерные сети, чтобы один сетевой интерфейс использовался для клиентских подключений, а второй был ограничен исключительно для использования межузлового кластерного обмена. В свойствах кластерной сети, предназначенной для Cluster Heartbeat (в нашем случае это Cluster Network 2) должна быть отключена опция Allow clients to connect through this network. Таким образом, мы заставим кластер использовать данную кластерную сеть, состоящую из интерфейсов NIC2, только в целях межузлового обмена.

 


Теперь в нашем кластере мы можем создать службу RD Connection Broker. Для этого в разделе Services and applications выберем пункт Configure a Service or Application

 


В открывшемся мастере высокой доступности из списка доступных для кластеризации служб и приложений выберем службу Remote Desktop Connection Broker

 


Обратите внимание на то, что в официальной документации есть информация об ограничениях в ситуации когда вы хотите создать кластеризованный экземпляр службы RD Connection Broker в уже существующем кластере и при этом в этом кластере есть настроенные ранее службы типа Generic Service.

На следующем шаге мастера введём имя и IP адрес точки доступа к службе. Именно эти данные в дальнейшем и будут нами использоваться для настройки фермы RD Connection Broker

 


На этапе создания службы в кластере в домене также будет создана дополнительная учетная запись и будет произведена регистрация имени в DNS

 


После окончания работы мастера в консоли управления кластером мы можем убедиться в том что кластеризованный экземпляр службы успешно создан, запущен и его активным владельцем является сервер KOM-AD01-RDS02. Также обращаем внимание на то, что по умолчанию включён режим автозапуска данной службы при начале работы кластера.

 


Нужно проверить то, что адрес кластерного ресурса службы RDCB корректно зарегистрировался в DNS и доступен в сети.

 


Включаем сервера в ферму RD Connection Broker

На каждом сервере с службой RD Connection Broker добавляем все наши сервера RD Session Host в локальную группу безопасности Session Broker Computers. В нашем случае это нужно сделать на всех трёх серверах.

 


Затем, на каждом из трёх наших серверов RD Session Host открываем консоль Remote Desktop Session Host Configuration (Start > Administrative Tools > Remote Desktop Services) и в разделе Edit settings, выбираем настройку Member of farm in RD Connection Broker.

 


На вкладке RD Connection Broker нажимаем кнопку Change Settings.

 


В окне RD Connection Broker Settings выбираем Farm member и вводим имя кластерного экземпляра службы RDCB. Имя создаваемой фермы в поле Farm name
по рекомендации оставим схожим с именем кластерного экземпляра.

 


Отметим опцию Participate in Connection Broker Load-Balancing для включения механизма балансировки нагрузки в ферме RD Connection Broker. Значение Relative weight определяет относительный вес данного сервера в ферме (по умолчанию – 100). В том случае, если вы зададите вес одного сервера 100, а другого 50, это приведёт к тому, что сервер с меньшим весом будет получать в 2 раза меньше подключений.

 


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

В типичной конфигурации фермы RD Connection Broker предлагается использовать механизм DNS Round Robin для подключения клиентов к ферме. Вместо этого, в нашем случае, для подключения клиентов будет использоваться имя кластеризованного экземпляра RD Connection Broker и в дополнительных манипуляциях с DNS нет необходимости.

Для того чтобы проверить то, что наша ферма действительно создалась, в корневом элементе консоли Remote Desktop Services Manager в меню действий выберем пункт Import from RD Connection Broker

 


… и укажем FQDN имя нашего кластеризованного экземпляра RD Connection Broker

 


После этого в консоли должна появиться информация о созданной ферме и задействованных в ней серверах с ролью RD Session Host

 


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

Настраиваем сертификаты серверов RDSH фермы RDCB

При попытке подключения к ферме RD Connection Broker по короткому имени или FQDN клиенты могут получать предупреждение безопасности, говорящее о том что нет доверия сертификату того сервера сеансов на который он был перенаправлен

 


Если открыть свойства этого сертификата мы увидим что сертификат создаваемый на сервере RDSH по умолчанию является самоподписанным.

 


Чтобы избежать таких предупреждений нам нужно создать для каждого сервера сеансов сертификат подписанный доверенным Центром сертификации (ЦС), например локальным изолированным или доменным ЦС.

При создании запроса на сертификат необходимо использовать политику применения — Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)

Если в перспективе на ваших терминальных серверах вы планируете использование технологии RemoteApp с использованием цифровой подписи распространяемых RDP-файлов, то возможно вам резонно будет в запрос включить так же и политику применения  — Подписывание кода (1.3.6.1.5.5.7.3.3)

Также при создании запроса на сертификат нужно учесть то, что создаваемый сертификат желательно иметь с альтернативными именами объекта – Subject Alternative Name (SAN). В противном случае при подключении клиенты могут получать предупреждение безопасности RDP клиента о том, что имя которое мы используем для подключения не совпадает с именем сервера на который его перенаправляет RD Connection Broker

 


Мы можем создать единый сертификат который будет установлен на все сервера фермы и будет содержать в себе все возможные имена SAN.

Для того чтобы наш локальный ЦС мог корректно обрабатывать запросы сертификатов с SAN он должен быть настроен для этого. На примере изолированного ЦС проверить это можно выполнив на сервере ЦС команду.

certutil -getreg PolicyEditFlags

 


Если среди выведенных значений нет флага EDITF_ATTRIBUTESUBJECTALTNAME2, то его можно добавить с последующим перезапуском службы сертификации:

certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc


Подробнее об использовании Subject Alternative Name в цифровых сертификатах можно найти по ссылкам:

Подготовим файл параметров для создания запроса на получение нужного нам сертификата. Это обычный текстовый файл, назовём его например RequestPolicy.inf

Содержимое этого файла в нашем примере выглядит так:

[Version]

Signature=«$Windows NT$»

 

[NewRequest]

Subject = «CN=KOM-AD01-RDSCB.holding.com» ;

Exportable = TRUE; Private key is exportable

KeyLength = 2048

KeySpec = 1; Key Exchange – Required for encryption

KeyUsage = 0xA0; Digital Signature, Key Encipherment

MachineKeySet = TRUE

ProviderName = «Microsoft RSA SChannel Cryptographic Provider»

RequestType = PKCS10

 

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

OID=1.3.6.1.5.5.7.3.3 ; Code signing

 

[RequestAttributes]

SAN  = «dns=KOM-AD01-RDSCB.holding.com&»

_continue_ = «dns=KOM-AD01-RDS01.holding.com&»

_continue_ = «dns=KOM-AD01-RDS02.holding.com&»

_continue_ = «dns=KOM-AD01-RDS03.holding.com&»

_continue_ = «dns=KOM-AD01-RDSCB&»

_continue_ = «dns=KOM-AD01-RDS01&»

_continue_ = «dns=KOM-AD01-RDS02&»

_continue_ = «dns=KOM-AD01-RDS03&»

_continue_ = «dns=10.160.0.39&»

_continue_ = «dns=10.160.0.41&»

_continue_ = «dns=10.160.0.42&»

_continue_ = «dns=10.160.0.43&»

 

 

С помощью встроенной в ОС утилиты CertReq.exe создадим файл запроса на основе файла параметров:

 

 

cd /d C:Temp
CertReq –New RequestPolicy.inf RequestFile.req

Далее, на основании полученного файла запроса RequestFile.req в локальном центре сертификации можно получить сертификат. В нашем случае для отправки запроса и получения сертификата будет использоваться веб-узел локального изолированного ЦС Active Directory Certificate Services. Действия по запросу и получению сертификата нужно выполнять непосредственно с одного из тех серверов для которых будем создавать этот сертификат. В нашем примере мы выполним запрос и получения сертификата с сервера KOM-AD01-RDS01

Итак на веб-узле локального ЦС последовательно перейдём по ссылкам:

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.

и скопируем содержимое сгенерированного ранее запроса из файла RequestFile.req

 


После того как размещённый запрос на сертификат обработан администратором центра сертификации, мы можем с этого же веб-узла локального ЦС загрузить сертификат в формате Base 64 encoded пройдя по ссылке:

View the status of a pending certificate request

 


Будет предложено загрузить файл сертификата в формате PKCS #7 с именем certnew.p7b

Устанавливаем в систему полученный сертификат командой:

CertReq -accept certnew.p7b

После этого в консоли управления сертификатами в хранилище Local ComputerPersonal можно будет увидеть новый установленный сертификат, подписанный доверенным локальным ЦС

 


Затем на этом же сервере открываем консоль Remote Desktop Session Host Configuration и в разделе Connections, открываем свойства подключения.

 


В окне свойств подключения на закладке General в секции Security нажимаем кнопку Select для того чтобы выбрать только что установленный в систему сертификат

 


В окне выбора сертификатов выбираем соответствующий сертификат…

 


После этого сохраняем настройки свойств подключения

 


Теперь нам нужно установить этот же сертификат на другие два сервера – KOM-AD01-RDS02 и KOM-AD01-RDS03. Для этого в консоли управления сертификатами на сервере KOM-AD01-RDS01 выполним экспорт сертификата с закрытым ключом из хранилища Certificates /Local Computer/Personal.

 


В открывшемся мастере экспорта сертификата на странице Export Private Key выберем опцию Yes, export the private key

 


На странице Export File Format выбран один возможный вариант формата выгрузки — Personal Information Exchange – PKCS #12 (.PFX)

 


Затем вводим пароль для защиты закрытого ключа, который мы в дальнейшем будем использовать для импорта сертификата на серверах KOM-AD01-RDS02 и KOM-AD01-RDS03

 


Далее указываем имя файла в который будет экспортирован сертификат

 


Полученный файл в формате PFX копируем на другие два сервера и, открыв на них консоль управления сертификатами в хранилище Local ComputerPersonal вызываем мастер импорта сертификата

 


В открывшемся мастере импорта сертификата указываем расположение PFX файла содержащего сертификат с закрытым ключом

 


Затем указываем пароль, с которым ранее сертификат был экспортирован. Устанавливать признак экспортируемости ключа (Mark this key as exportable..) вовсе не обязательно.

 


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

 


После того как сертификат импортирован, откроем консоль Remote Desktop Session Host Configuration в разделе Connections, открываем свойства подключения и выполним привязку к установленному сертификату методом описанным ранее.

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

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

Запись опубликована в рубрике Администрирование. Добавьте в закладки постоянную ссылку.

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Solve : *
24 ⁄ 12 =