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

Для того чтобы повысить уровень безопасности Windows-сервера бывает недостаточно сменить TCP-порт RDP . Рассмотрим настройку шлюза  удаленных рабочих столов (Remote Desktop Gateway / Terminal Services Gateway) в домене Active Directory.

Remote Desktop Gateway, что это?

Remote Desktop Gateway — это роль Windows-сервера, обеспечивающая защищенное соединение, с помощью протокола SSL, с сервером по RDP. Главное преимущество этого решения в том, что не требуется развертывание VPN-сервера, для этого и используется шлюз.

Следует отметить, что начиная с Windows Server 2008 R2, были изменены названия всех служб удаленных рабочих столов. Именуемые ранее службы Terminal Services были переименованы в Remote Desktop Services.

Преимущества Remote Desktop Gateway в следующем:

• Используя зашифрованное соединение, шлюз позволяет подключаться к внутренним сетевым ресурсам без необходимости использования VPN-соединения удаленными пользователями;
• Шлюз дает возможность контроля доступа к определенным сетевым ресурсам, тем самым реализуя комплексную защиту;
• Шлюз разрешает подключение к сетевым ресурсам, которые размещены за межсетевыми экранами в частных сетях или NAT;
• С помощью консоли диспетчера шлюза появляется возможность настраивать политики авторизации для тех или иных условий, которые должны быть выполнены при подключении к сетевым ресурсам удаленными пользователями. В качестве примера, можно указать конкретных пользователей, которые могут подключаться к внутренним сетевым ресурсам, а также должен ли клиентский компьютер при этом быть членом группы безопасности AD, допустимо ли перенаправление устройства и диска;
• Консоль диспетчера шлюза содержит инструменты, предназначенные для отслеживания состояния шлюза. Используя их, вы можете назначить отслеживаемые события для аудита, например, неудачные попытки подключения к серверу шлюза служб терминалов.

Важно! Шлюз служб терминалов должен входить в домен Active Directory. Настройка шлюза выполняется только от имени администратора домена, на любом сервере в домене.

Установим роль.

Настройка политики авторизации подключения и ресурсов.



Установим SSL-сертификат.

В том же окне “Диспетчер шлюза удаленных рабочих столов”, в левой окна кликаем по значку сервера, в основной части окна — “Просмотр и изменение свойств сертификата”.

В открывшемся окне “Свойства <имя_сервера>” переходим на вкладку “Сертификат SSL”. Устанавливаем переключатель “Создать самозаверяющий сертификат” и кликаем по кнопке “Создать и импортировать сертификат…”.

Хотя возможны еще 2 варианта:

• импорт ранее загруженного сертификата (самоподписанного ранее или стороннего);
• загрузка стороннего сертификата (например, Comodo) и его импорт;

В окне “Создание самозаверяющего сертификата” проверяем параметры и нажимаем кнопку “OK”.

Система уведомит, что сертификат был создан успешно. также присутствует информация, где можно найти сам файл сертификата. Нажимаем кнопку “OK”.

В окне свойств сервера, нажимаем кнопку “Применить”.

Самозаверенный сертификат установлен на TCP-порт 443 (SSL-порт по умолчанию).

Мы рекомендуем, в целях безопасности, изменить порт SSL, используемый по-умолчанию. Для этого, в основном меню окна, выбираем “Действия” → “Свойства”.

Переходим на вкладку “Параметры транспорта” и устанавливаем желаемое значение поля “HTTPS-порт”. Сохраняем параметры нажимая кнопку “Применить”.

Система запросит подтверждение — отвечаем ”Да”.

Выполним подключение через шлюз.

Открываем RDP-клиент, переходим на вкладку “Дополнительно” и нажимаем кнопку “Параметры”.

В открывшемся окне выбираем “Использовать следующие параметры сервера шлюза удаленных рабочих столов”. Указываем доменное имя сервера и через двоеточие (:) указываем SSL-порт. Метод входа — “Запрашивать пароль”. Нажимаем “OK”

Переходим на вкладку “Общие”. Указываем адрес компьютера и пользователя под которым будет выполняться подключение. Нажимаем кнопку “Подключить”

Программа запросит пароль от учетной записи.

Результаты работы шлюза можно проверить трассировкой — команда tracert.

220140
Минск
ул. Домбровская, д. 9

+375 (173) 88-72-49

ООО «ИТГЛОБАЛКОМ БЕЛ»

220140
Минск
ул. Домбровская, д. 9

+375 (173) 88-72-49

ООО «ИТГЛОБАЛКОМ БЕЛ»

В инструкции описана установка и настройка шлюза удаленных рабочих столов Remote Desktop Gateway (Terminal Services Gateway) в домене Active Directory. Описаны настройка SSL-сертификата для шлюза и пример подключения.

Что такое Remote Desktop Gateway?

Примечание: начиная с Windows Server 2008 R2 все службы удаленных рабочих столов были переименованы. Службы Terminal Services были переименованы в Remote Desktop Services.

Remote Desktop Gateway — роль, которая использует протокол удаленного рабочего стола RDP через протокол HTTPS, благодаря которому пользователи могут установить безопасное, зашифрованное соединение с внутренними сетевыми ресурсами, где выполняются их приложения. Основное преимущество заключается в том, что пользователю не нужно устанавливать VPN-соединение с корпоративной сетью перед подключением к серверу терминалов. Вместо этого они подключаются к серверу терминалов через шлюз.

RD Gateway предоставляет множество преимуществ:

• шлюз позволяет удаленным пользователям подключаться к внутренним сетевым ресурсам через Интернет, используя зашифрованное соединение, без необходимости подключения виртуальных частных сетей (VPN);
• шлюз предоставляет комплексную конфигурацию безопасности, которая позволяет контролировать доступ к определенным внутренним сетевым ресурсам;
• шлюз обеспечивает одноточечное RDP-соединение и не позволяет удаленным пользователям получать доступ ко всем внутренним сетевым ресурсам;
• шлюз позволяет подключаться к внутренним сетевым ресурсам, которые размещаются за брандмауэрами в частных сетях и между NAT;
• консоль диспетчера шлюза позволяет настраивать политики авторизации для определения условий, которые должны быть выполнены для удаленных пользователей при подключении к внутренним сетевым ресурсам. Например, можно указать: кто может подключаться к сетевым ресурсам и к каким сетевым ресурсам (группам серверов), должны ли клиентские компьютеры быть членами групп безопасности Active Directory, разрешено ли перенаправление устройства и диска;
• консоль диспетчера шлюза предоставляет инструменты, которые помогут отслеживать состояние шлюза. Используя диспетчер, вы можете указать события (например, неудачные попытки подключения к серверу шлюза служб терминалов), которые вы хотите отслеживать для целей аудита.

Примечание: для подключения через шлюз ваш сервер должен входить в домен Active Directory, настройка шлюза может выполняться на любом сервере в домене от имени администратора домена.

Установка роли

Откройте Диспетчер серверов и выберете пункт Add roles and features.

В качестве типа установки укажите Role-based or feature-based installation.

Выберете ваш сервер из пула.

В следующем окне отметьте Remote Desktop Services.

Далее вы увидите краткую информацию о роли.

Далее добавьте сервис Remote Desktop Gateway.

Для работы этого сервиса необходимо веб-сервер IIS и дополнительные административные инструменты, они будут предложены автоматически, если не были установлены ранее.

Добавьте данные функции.

Установите все выбранные компоненты на VPS с помощью кнопки Install.

Создание политики авторизации подключения и ресурсов

Чтобы открыть Remote Desktop Gateway Manager, в Диспетчере серверов выберете Tools и в открывшемся списке Remote Desktop Services → Remote Desktop Gateway Manager.

Перед вами откроется менеджер шлюза.

Для создания политик авторизации в древовидной структуре откройте RD Gateway Manager → <Имя сервера> → Policies → Connection Authorization Policies. В вертикальном меню Actions справа выберете Create New Policy → Wizard.

В открывшемся окне выберете Create RD CAP and RD RAP (recommended), чтобы с помощью одного процесса настроить обе политики.

Введите удобное имя для политики авторизации подключения.

На следующем шаге выберете наиболее удобный метод аутентификации: пароль или smartcard. Далее добавьте группы пользователей которые смогут подключаться к этому RD Gateway серверу, для это нажмите Add Group.

Выберете нужную группу, например администраторов домена или контроллеры домена. Выполнить поиск можно с помощью кнопки Check Names.

После добавления групп можно переходить к следующему действию.

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

Выберете нужные для вас значения таймаутов: времени простоя и времени работы сессии.

Перепроверьте выбранные настройки.

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

Также добавьте группы пользователей, которые смогут подключаться к сетевым ресурсам.

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

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

Убедитесь, что добавлена нужная группа.

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

Проверьте указанные настройки для политики.

Далее отобразится результат создания политик.

После создания политик менеджер будет выглядеть следующим образом.

Установка SSL-сертификата

Для шлюза удаленного рабочего стола должен быть установлен SSL-сертификат. Чтобы установить SSL-сертификат, щелкните имя сервера удаленного рабочего стола в консоли управления удаленным рабочим столом и выберете View or modify certificate properties.

Возможно 3 способа импорта сертификатов:

• создание самоподписанного сертификата и его импорт;
• импорт ранее загруженного сертификата (самоподписанного или стороннего);
• загрузка стороннего сертификата (например, Comodo) и его импорт;

Выберете подходящий вам способ, в нашем примере мы рассмотрим первый случай с генерацией и импортом самоподписанного сертификата.

Введите имя сертификата и его расположение на сервере. Нажмите OK.

Сертификат будет сгенерирован.

В результате отобразится — кому, кем и до какого числа выдан ssl-сертификат. Нажмите Apply для сохранения изменений.

Теперь самоподписанный SSL-сертификат успешно установлен на TCP-порт 443 (порт SSL по умолчанию).

В целях безопасности рекомендуется изменить порт SSL для шлюза удаленных рабочих столов на другой номер. Обычно компании делают это, чтобы попытаться обмануть хакеров, которые могут ориентироваться на стандартный порт 443.

Чтобы изменить номер порта для шлюза RD, щелкните правой кнопкой мыши имя сервера и выберите свойства в консоли управления удаленным рабочим столом (Action →Properties).

Измените значение HTTP-порта на любое удобное значение и сохраните изменения.

Подтвердите изменения, нажав Yes.

Подключение через шлюз

Для подключения откройте стандартное приложение Windows Подключение к удаленному рабочему столу (mstsc.exe). На вкладке Дополнительно нажмите на кнопку Параметры.

В открывшемся окне выберете Использовать следующие параметры сервера шлюза удаленных рабочих столов. Введите имя сервера в следующем формате и нажмите OK:
rdgateway.<ваш домен>:<порт>

На вкладке Общие в поле Компьютер введите домен, в поле Пользователь имя пользователя и нажмите Подключить. При необходимости можете сохранить параметры входа.

Примечание: пользователь должен иметь права подключения через шлюз, которые были настроены ранее.

Введите пароль от учетной записи.

В результате будет произведено подключение к удаленному рабочему столу через шлюз RD Gateway. Это можно проверить с помощью команды tracert:

Из вывода видно, что трассировка идет через шлюз.

В первой части статьи, опубликованной в предыдущем номере журнала, мы рассматривали технологии, реализующие виртуализацию настольных систем, включая виртуализацию приложений, перемещаемые профили, перенаправление папок и виртуализацию операционной системы. Я рассказал о том, как с помощью этих технологий можно динамически сформировать необходимую полнофункциональную рабочую среду в локальной операционной системе, на платформе виртуализации представления, такой как службы удаленных рабочих столов Remote Desktop Services (RDS), и на базе инфраструктуры виртуальных настольных систем Virtual Desktop Infrastructure (VDI). В данной статье речь пойдет о компонентах, необходимых для создания решения VDI на платформе Windows Server 2008 R2, использующего только продукты Microsoft.

Предварительные сведения

Прежде чем рассмотреть все шаги типичного процесса подключения к развертываемой настольной системе, будет полезно определить типы служб, необходимых для построения архитектуры VDI. На рисунке показаны основные шаги, необходимые для функционирования VDI, от начального подключения пользователя до формирования рабочей сессии VDI, за исключением таких технологий, как виртуализация приложений от Microsoft Application Virtualization (App-V), перемещаемые профили и т. д.

Рисунок. Компоненты VDI

Данный процесс состоит из семи шагов. Сначала пользователи должны найти удаленные настольные системы, к которым они могут подключиться и которые могут быть либо сессиями виртуализации представления (службы терминалов), либо опубликованными приложениями, либо сессиями VDI. И хотя для этой цели можно создать файл RDP и передать его тем или иным способом пользователям, существует более динамичный подход, с использованием службы веб-доступа к удаленным рабочим столам Remote Desktop Web Access, позволяющей отображать в браузере список доступных подключений, из которых пользователь может выбирать. Альтернативой просмотру на сайте списка динамически публикуемых подключений и приложений является использование имеющегося в Windows 7 компонента подключения к удаленным рабочим столам и приложениям RemoteApp для подписки на каналы RSS с серверов веб-доступа к удаленным рабочим столам, автоматически формирующим доступные подключения, которые могут быть настроены через сценарии, распространяемые с помощью групповых политик. Пользователи могут видеть эти публикуемые службы непосредственно в главном меню своих систем.

Второй шаг — создание списка опубликованных приложений и подключений, доступных пользователям. Для выполнения этой задачи сервер веб-доступа к удаленным рабочим столам подключается к посреднику подключений к удаленному рабочему столу Remote Desktop Connection Broker, который получает информацию о пулах VDI, личных рабочих столах и других опубликованных подключениях и приложениях с помощью собственных процедур взаимодействия с настроенными источниками удаленных приложений RemoteApp.

На третьем шаге посредник подключений к удаленным рабочим столам взаимодействует с Active Directory для определения прав доступа пользователя. Благодаря этому взаимодействию в свойствах пользователя отображаются также настройки личных рабочих столов, которые мы обсудим ниже.

Независимо от используемого метода (это может быть веб-доступ к удаленным рабочим столам, либо компонент подключения к удаленным рабочим столам и приложениям RemoteApp, либо подготовленный файл RDP), пользователи получают файл RDP, который можно задействовать для инициализации подключения (шаг 4). Если пользователь находится вне корпоративной сети, прямое подключение RDP блокируется большинством корпоративных брандмауэров. Таким образом, необходимо устанавливать защищенное подключение VPN. Однако существует альтернативное решение, которое не требует каких-либо действий пользователя или дополнительного клиентского программного обеспечения. В Windows Server 2008 имеется шлюз служб терминалов Terminal Services Gateway, который позволяет инкапсулировать трафик протокола RDP в пакеты протокола HTTPS (порт 443). Шлюз служб терминалов в системе Server 2008 R2 переименован в шлюз удаленных рабочих столов Remote Desktop Gateway. Для использования шлюза удаленных рабочих столов мы помещаем данный сервер в так называемую демилитаризованную зону (DMZ) или, для более высокой степени защиты, за каким-либо брандмауэром или прокси-сервером. Клиенты теперь подключаются к серверу RDP через шлюз удаленных рабочих столов путем добавления адреса шлюза в настройки файла RDP, передаваемого клиенту. Клиент инкапсулирует трафик протокола RDP в протокол HTTPS и посылает инкапсулированные данные на шлюз удаленных рабочих столов, на котором данные RDP извлекаются и пересылаются на соответствующий сервер терминалов. При возврате данных от сервера RDP назад к клиенту шлюз удаленных рабочих столов снова инкапсулирует данные RDP в пакеты HTTPS и передает их клиенту. Таким образом клиент, находящийся вне корпоративной сети, получает доступ ко всем ресурсам RDP без дополнительных действий и программных продуктов. Пользователи в корпоративной сети без обращения к шлюзу удаленных рабочих столов напрямую подключаются к серверу RDP. Проверка подлинности на шлюзе удаленных рабочих столов может производиться традиционным для Windows способом (имя/пароль) или с помощью смарт-карт, включая возможность подключения с текущими введенными учетными данными, без повторного ввода.

На шаге 5 пользователю необходимо знать точку начального подключения RDP, так как назначенная ему виртуальная машина клиенту VDI пока что неизвестна, если только у пользователя нет настроенного личного рабочего стола. Сервер сеансов удаленных рабочих столов Remote Desktop Session Host настраивается в режиме перенаправления подключений, то есть сервер принимает запросы пользователей на подключение RDP-, а затем перенаправляет клиента к сеансу DVI. Узел сеансов удаленных рабочих столов подключается к посреднику подключений к удаленному рабочему столу Remote Desktop Connection Broker для определения точки подключения клиента. В данной архитектуре сервер сеансов удаленных рабочих столов и посредник подключений к удаленному рабочему столу — это один и тот же сервер, однако вы не обязаны их размещать на одном узле (хотя обычно делается именно так из-за тесной взаимосвязи между этими ролями).

На шаге 6 посредник подключений к удаленному рабочему столу подключается к узлу виртуализации удаленных рабочих столов Remote Desktop Virtualization Host, настроенному на серверах Hyper-V, для проверки состояния виртуальной машины, ее запуска, если это необходимо, и сбора всей необходимой информации, такой как IP-адрес операционной системы клиентской виртуальной машины, который затем передается посреднику подключений к удаленному рабочему столу, узлу сеансов удаленных рабочих столов в режиме перенаправления и, наконец, самому клиенту.

На шаге 7 клиент подключается по протоколу RDP к своей виртуальной машине через шлюз удаленных рабочих столов (если подключение осуществляется извне корпоративной сети); на этом процесс подключения завершается. При регистрации пользователя загружается его перемещаемый профиль, а также данные из перенаправленных папок и приложения, доступные через App-V.

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

На рисунке показан элемент, который мы не рассматривали, — это Microsoft System Center Virtual Machine Manager (VMM). И хотя VMM не является абсолютно необходимым для среды VDI, он будет очень полезен в управлении этой средой с помощью средств управления фермой Hyper-V, библиотек, поддержки PowerShell и других инструментов.

Для среды VDI можно использовать бесплатный продукт Microsoft Hyper-V Server и сэкономить на покупке Server 2008 R2. Полнофункциональный Server 2008 R2 предоставляет те же возможности Hyper-V, что и бесплатный Hyper-V Server, но при этом он предоставляет много дополнительных функций, помимо виртуализации. Кроме того, у Hyper-V из состава Server 2008 R2 имеются дополнительные лицензии на экземпляры виртуальных серверов, в которых в данном случае нет необходимости, поэтому вы можете сэкономить и использовать бесплатное решение.

Если мы посмотрим на шаги, осуществляемые в процессе подключения, то увидим, что мы используем пять служб роли RDS. Если вы решите задействовать RemoteFX с SP1 (о котором я расскажу в одной из следующих статей), получится шесть служб роли удаленных рабочих столов. Использование любой из служб роли удаленных рабочих столов требует клиентских лицензий для доступа к RDS, в дополнение к лицензиям на доступ к виртуальным настольным системам/подписке Software Assurance. Теперь рассмотрим подробнее все эти службы и особые моменты, относящиеся к VDI. Полную информацию о развертывании VDI можно найти в статье Microsoft TechNet «Getting Started: Remote Desktop Services» по адресу technet.microsoft.com/en-us/library/dd736539(WS.10).aspx (на русском языке — «Начало работы. Службы удаленных рабочих столов» на странице http://technet.microsoft.com/ru-ru/library/dd736539(WS.10).aspx).

Веб-доступ к удаленным рабочим столам

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

В Windows 7 появился компонент подключения к удаленным рабочим столам и приложениям RemoteApp and Desktop Connection, который, не являясь напрямую частью веб-доступа к удаленным рабочим столам, позволяет передавать от сервера веб-доступа к удаленным рабочим столам содержимое, отображаемое на данном веб-сайте, напрямую в главное меню, избавляя от необходимости использования сайта. На экране 1 показаны локальное главное меню и представление с веб-сайта. Заметим, что мы здесь можем видеть не только пул VDI, но и приложения, опубликованные на серверах сеансов удаленных рабочих столов.

Экран 1. Представление опубликованных приложений и рабочих столов в веб-браузере и через подключения к удаленным рабочим столам и приложениям RemoteApp

Если вы хотите создать конфигурационный файл для автоматической настройки компонента подключения к удаленным рабочим столам и приложениям RemoteApp для клиентов Windows 7, используйте параметр Create Configuration File в диспетчере подключений к удаленному рабочему столу. При этом создается файл, который можно запускать на клиенте Windows 7 для автоматической настройки. Это очень удачное решение для крупных систем.

Посредник подключений к удаленному рабочему столу

Служба посредника подключений к удаленному рабочему столу Remote Desktop Connection Broker в системе Server 2008 R2 — один из основных компонентов, позволяющий построить решение VDI на продуктах Microsoft. Он предоставляет роли RDS возможность балансировать нагрузку и отслеживать подключения к системам, не являющимся серверами терминалов, в особенности — возможность управлять подключениями к клиентским операционным системам. И, кроме того, в системе Server 2008 R2 у службы посредника подключений к удаленному рабочему столу появилась возможность осуществлять балансировку удаленных приложений и поддерживать серверы с различными опубликованными приложениями, что позволяет получить суммарное представление различных приложений, собранных со всех серверов фермы, отображаемое у пользователя, и вам уже не потребуется иметь на всех серверах один и тот же набор приложений.

Служба Remote Desktop Connection Broker — это мозг среды VDI. Она обменивается информацией и управляет всеми остальными компонентами, наиболее тесно взаимодействуя с сервером сеансов удаленных рабочих столов в режиме перенаправления, поэтому посредник подключений к удаленному рабочему столу и сервер сеансов удаленных рабочих столов в режиме перенаправления часто устанавливаются в одной и той же системе. Однако, если у вас более 250 одновременных подключений, вам может потребоваться установка данных ролей на различных серверах.

Пулы VDI создаются с помощью службы Remote Desktop Connection Broker посредством инструмента Remote Desktop Connection Manager, который управляет опубликованным приложением, опубликованным сеансом и ресурсами виртуального рабочего стола. Диспетчер подключений к удаленным рабочим столам будет вашим любимым инструментом при управлении средой DVI. Этот инструмент не только создает пулы VDI, но и настраивает службы Remote Desktop Virtualization Host, Remote Desktop Web Access и Remote Desktop Session Host. Он также переводит сервер сеансов удаленных рабочих столов в режим перенаправления, избавляя вас от настройки вручную каждой службы для роли VDI.

Когда создается пул VDI, необходимо указать серверы Hyper-V, на которых размещаются виртуальные машины, а затем выбрать клиентские виртуальные машины, которые будут входить в состав пула. Мастер создания пула VDI выполнит остальные настройки.

Служба Remote Desktop Connection Broker обрабатывает все входящие запросы VDI и вначале проверяет, не остался ли у пользователя отключенный сеанс в пуле VDI. Если да, то пользователь подключается к этому сеансу, в противном случае ему назначается не используемый в настоящий момент виртуальный рабочий стол.

Узел сеансов удаленных рабочих столов в режиме перенаправления

Идея использования сервера сеансов удаленных рабочих столов в режиме перенаправления не нова. Такой подход применялся в предыдущей версии Windows Server при создании большой фермы терминальных серверов. Чтобы избавить пользователей от необходимости подключения к разным серверам терминалов, начальная точка входа всегда является выделенным сервером сеансов, который только взаимодействует с посредником подключений и перенаправляет подключения RDP на нужный сервер. Такой же процесс происходит и в среде VDI, нам по-прежнему нужна начальная точка подключения RDP для клиентов RDP, каковой является сервер сеансов удаленных рабочих столов в режиме перенаправления. Данный узел перенаправляет клиентов RDP к соответствующей клиентской виртуальной машине, предоставляющей операционную систему.

Сервер сеансов удаленных рабочих столов — это то, что мы привыкли называть сервером терминалов, то есть сервер, на котором размещены пользовательские сеансы. Но, поскольку в Server 2008 R2 имеется много различных компонентов RDS, надо точнее определять сервер, предоставляющий пользовательские сеансы, отсюда использование термина «сервер сеансов удаленных рабочих столов».

Можно вручную настроить сервер сеансов удаленных рабочих столов для работы в режиме перенаправления. Однако, если мы используем мастер создания пула VDI в диспетчере подключений к удаленным рабочим столам, настройка сервера сеансов удаленных рабочих столов выполняется автоматически, как показано на экране 2. Заметим, что, как только сервер сеансов удаленных рабочих столов переводится в режим перенаправления, он уже не может более запускать обычные сеансы, а только будет выполнять перенаправление подключений.

Экран 2. Автоматическая настройка сервера сеансов удаленных рабочих столов с помощью мастера пула VDI

Узел виртуализации удаленных рабочих столов

Служба Remote Desktop Virtualiza­tion Host устанавливается на каждом узле Hyper-V, который включается в пул VDI. Эта служба позволяет службе посредника подключений к удаленному рабочему столу обмениваться информацией с узлами Hyper-V, запускать и останавливать виртуальные машины и собирать внутреннюю информацию для обеспечения клиентских подключений.

Шлюз удаленных рабочих столов

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

Высокодоступные решения VDI

Построение решения VDI требует централизации среды рабочих столов в едином центре обработки данных. Если происходит сбой на сервере, то пользователь может продолжать работу в локальной операционной системе. Но если мы разворачиваем VDI, то вся среда рабочих столов теперь находится в центре обработки данных, так что если какая-то часть VDI выходит из строя, пользователь полностью лишается настольной среды и не может работать. Обеспечение отказоустойчивости всех элементов VDI становится критически важной задачей. К счастью, у нас есть решения для каждой части архитектуры VDI.

Считая службу Remote Desktop Connection Broker мозгом всей среды VDI, необходимо использовать отказоустойчивый кластер, так как данная служба поддерживает кластеризацию, что обеспечивает доступность этой службы при выходе из строя любого узла. Поскольку обычно служба сервера сеансов удаленных рабочих столов в режиме перенаправления устанавливается совместно с посредником подключений к удаленному рабочему столу, необходимо установить службу сервера сеансов удаленных рабочих столов и настроить на работу в режиме перенаправления на всех узлах кластера. На сервере DNS создается ресурсная запись для узлов сеансов, которая ссылается на IP-адреса всех узлов сеансов. При подключении эти IP-адреса пересылаются клиентам в различном порядке. Если один из серверов недоступен, клиенты будут пытаться подключиться, используя следующий IP-адрес.

Служба балансировки сетевой нагрузки Network Load Balancing (NLB) применяется для распределения запросов между несколькими экземплярами шлюза удаленных рабочих столов. Мы можем задействовать как службу NLB, встроенную в систему Windows, так и аппаратный балансировщик нагрузки. Те же технологии NLB можно использовать для обеспечения высокой доступности службы веб-доступа к удаленным рабочим столам.

Узлы Hyper-V могут быть размещены в отказоустойчивом кластере таким образом, что при сбое узла Hyper-V клиентская виртуальная машина перемещается на другие узлы. Если потребуется, технология динамической миграции Live Migration может быть использована для перемещения работающих клиентских виртуальных машин между узлами при техническом обслуживании серверов. Однако, поскольку пользовательские настройки и данные отделены от экземпляра операционной системы, если один экземпляр выходит из строя, пользователям нужно всего лишь переключиться на альтернативный экземпляр операционной системы. Настройки и данные пользователя снова будут доступны.

Личные рабочие столы или рабочие столы в составе пула

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

Рабочие столы в составе пула должны быть рабочими столами по умолчанию для всех пользователей. Однако для некоторых пользователей может возникнуть необходимость иметь один и тот же экземпляр операционной системы при каждом подключении. Возможно, они каким-то особым образом настраивают свою систему или им нужно установить приложение, которое не может быть виртуализовано. В любом случае у нас есть возможность статического назначения отдельной виртуальной машины какому-либо пользователю, чтобы этот пользователь всегда получал одну и ту же клиентскую операционную систему. Это называется личным рабочим столом и настраивается в консоли Active Directory Users and Computers, как показано на экране 3. Пользователю можно назначить только один личный рабочий стол, виртуальная машина в качестве личного рабочего стола может быть назначена только одному пользователю, личный рабочий стол не должен входить в состав пула VDI, а должен быть обычной виртуальной машиной в среде виртуализации. Необходимо, чтобы имя личного рабочего стола совпадало с именем виртуальной машины, которое должно быть полным именем FQDN, например client.savilltech.net, то есть виртуальной машине необходимо назначать имя FQDN экземпляра клиентской операционной системы.

Экран 3. Назначение пользователю личного рабочего стола

Настройка клиентской виртуальной машины

Для удобства в качестве клиентской операционной системы лучше всего использовать Windows 7. При развертывании VDI на базе служб RDS необходимо заранее создать все экземпляры виртуальных машин и включить их в пул; в настоящий момент нет возможности динамического создания или направления потока операционной системы для создания пула виртуальных машин (такая возможность имеется в Citrix XenDesktop). Для упрощения процесса развертывания виртуальных машин и операционной системы можно задействовать такие технологии, как VMM.

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

• разрешить удаленный рабочий стол Remote Desktop;
• добавить соответствующих пользователей в группу Remote Desktop Users;
• разрешить RPC;
• настроить исключения в брандмауэре для удаленного управления службами;
• настроить разрешения в протоколе RDP для сервера виртуализации удаленных рабочих столов.

Все необходимые действия для каждой виртуальной машины могут быть выполнены вручную. Подробнее об этом рассказано в статье Microsoft TechNet Remote Desktop Services in Windows Server 2008 R2, Appendix A, «Configuring the Virtual Machine Manually», размещенной по адресу technet.microsoft.com/en-us/library/ff603843(WS.10).aspx); можно использовать и групповые политики для автоматизации применения этих настроек, а также задействовать разработанный Microsoft сценарий для упрощения всего процесса (gallery.technet.microsoft.com/ScriptCenter/en-us/bd2e02d0-efe7-4f89-84e5-7ad70f9a7bf0).

Есть еще один интересный момент, относящийся к среде операционных систем клиентских виртуальных машин. У нас имеется несколько вариантов клиентской операционной системы, разделяемых между многими пользователями. Необходимо ограничить доступ к этим разделяемым клиентским средам, чтобы пользователи не могли изменять настройки операционной системы, а также устанавливать или удалять программы. Однако, в зависимости от конкретной среды, нам может потребоваться возвращать операционную систему в определенное состояние при каждом завершении сеанса работы с системой. Для этого можно использовать снимки Hyper-V и RDS.

Для каждой виртуальной машины можно сделать снимок, в имени которого имеется текст RDV_Rollback. Данный снимок должен быть сделан, когда виртуальная машина находится в «чистом» состоянии, так как нам нужно возвращаться к этому состоянию при каждом завершении сеанса работы с системой. Снимок можно сделать и при работающей, и при неработающей виртуальной машине, но необходимо, чтобы в процессе создания снимка в системе не было сеанса пользователя. Когда пользователь завершает сеанс работы с виртуальной машиной в среде VDI, к которой он подключился через службу посредника подключений к удаленному рабочему столу, состояние данной виртуальной машины возвращается к снимку RDV_Rollback. Заметим, что возможность создания снимка RDV_Rollback имеется только у виртуальных машин в пуле, но не у личных виртуальных рабочих столов.

Если вы выбираете применение RDV_Rollback для того, чтобы каждый пользователь при регистрации получал «чистую» среду, в среде VDI приходится применять некий прием, относящийся к членству в домене AD. Обычно пароль учетной записи компьютера автоматически изменяется каждые 30 дней. Если мы периодически будем возвращать систему к контрольной точке — например, после каждого завершения сеанса в системе, — старый пароль учетной записи компьютера, который присутствует в снимке RDV_Rollback, перестанет действовать, после того как компьютер поменяет пароль. Это может произойти, когда пользователь зарегистрируется в системе на 30-й день действия пароля, и может привести к сбоям в проверке подлинности учетной записи компьютера и необходимости сброса его пароля. Имеется несколько способов решения этой проблемы. Один из них — запрет смены пароля учетной записи компьютера, который можно реализовать с помощью групповых политик. Однако данный подход может иметь нежелательные последствия в отношении безопасности и поэтому не рекомендован к использованию.

Другой способ заключается в периодическом удалении всех клиентских виртуальных машин, их пересоздании и генерации новых снимков RDV_Rollback (с интервалом, меньшим, чем интервал смены пароля компьютерных учетных записей). Такой подход может показаться неразумным, но вы можете использовать VMM и сценарии от Microsoft для создания виртуальных машин в среде VDI (сценарий доступен по адресу gallery.technet.microsoft.com/scriptcenter/en-us/904bd2c8-099d-4f27-83da-95f5536233bc). Данные сценарии позволяют автоматизировать массовое создание виртуальных машин для среды VDI, что значительно облегчает повторное создание виртуальных машин в VDI по мере необходимости, а также периодическое пересоздание виртуальных машин. Использование этого подхода решает и еще одну проблему. Если мы используем виртуальные машины в течение длительного времени, нам необходимо устанавливать на них обновления и осуществлять регулярное обслуживание настольных систем. Если мы пересоздаем виртуальные машины каждые 4 недели, нам необходимо устанавливать обновления только на единственный мастер-образ, который используется при создании всех виртуальных машин в пуле VDI.

Следующие шаги

VDI на платформе RDS — очень достойное решение, которое реально может использоваться в производственной среде. Для некоторых крупных организаций статичная природа клиентских виртуальных машин может стать препятствием, и на решение этого вопроса сейчас направлены усилия в рамках партнерства Microsoft и Citrix. Об этом я расскажу в своей следующей статье. А пока рекомендую посетить веб-страницу «Getting Started: Remote Desktop Services» на сайте Microsoft TechNet по адресу technet.microsoft.com/en-us/library/dd736539(WS.10).aspx (русский вариант — «Начало работы. Службы удаленных рабочих столов» на странице http://technet.microsoft.com/ru-ru/library/dd736539(WS.10).aspx), содержащую пошаговые руководства по развертыванию среды VDI. Вполне реально в течение дня развернуть среду VDI в тестовой лаборатории и приступить к экспериментам.

Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP

Remote Desktop Gateway это один из сервисов роли Remote Desktop Services в Windows Server для организации защищенного доступа из Интернета к службам рабочих столов и опубликованным RemoteApp приложениям через HTTPS шлюз. Сервер с ролью RD Gateway выступает в роли посредника между внешними клиентами и развернутыми внутри службами RDS. При использовании RDGW пользователям не нужно настраивать VPN для подключения к RDS в корпоративной сети. Для подключения используется стандартный клиент Remote Desktop Connection (mstsc.exe). В этой статье рассмотрим процесс развертывания шлюза Remote Desktop Gateway на Windows Server 2019 (инструкция применима для Windows Server 2022/2016 и 2012 R2).

Установка роли RDS-Gateway в Windows Server

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

Предполагается, что в вашей сети уже развернута служба каталогов Active Directory и ферма серверов RDS.

Вы можете установить роль Remote Desktop Gateway через Server Manager (Add roles & Features -> Server Role -> Remote Desktop Services) или с помощью PowerShell.

При установке службы RDGW также устанавливаются веб сервер IIS и роль NPS (Network Policy Server).

Убедитесь, что роль RDS-Gateway установлена:

Get-WindowsFeature RDS*

Или установите роль в Windows Server с помощью команды Install-WindowsFeature:

Install-WindowsFeature RDS-Gateway -IncludeAllSubFeature –IncludeManagementTools

Создайте группы доступа в Active Directory с помощью консоли ADUC или с помощью PowerShell:

• rdgwExtUsers – группа пользователей, которым разрешено аутентифицироваться на RDGW;
• rdgwExternalAdmins – группа для доступа к терминальным серверам через RDGW;
• msk-rds-farm — должна включать в себя все хосты RDSH и RD Conneciton Broker, к которым вы хотите разрешить подключаться через шлюз удаленных рабочих столов.

Настройка политик доступа RDS Gateway

Для управления политиками и правилами доступа на RDGW используется консоль RD Gateway Manager (tsgateway.msc). Здесь нужно настроить два типа политик:

• Connection Authorization Policies (RD CAP) – определяют кому разрешено авторизоваться на шлюзе RDS;
• Resource Authorization Policies (RD RAP)– определяют кому и к каким ресурсам (компьютерам) внутренней сети разрешено подключаться через RDGW.

Создайте сначала политику RD CAP:

1. Разверните Policies -> Connection Authorization Policies и выберите пункт меню Create New Policy -> Wizard;
2. Укажите имя политики (rdgwExtUsers);
3. Выберите тип аутентификации (по паролю и/или по смарт карте), укажите группу пользователей, которым разрешено аутентифицироваться на RDGW;
4. В окне Enable or Disable Device Redirection можно указать какие устройства разрешено прокидывать в RDP сессию (буфер обмена, принтера, локальные диски и т.д.);
5. Далее можно настроить таймауты для RDP сеансов;
6. Подтвердите создание политики.

Также вы можете создать политику клиентского доступа RDGW с помощью PowerShell:

Import-Module -Name RemoteDesktopServices
New-Item -Path 'RDS:GatewayServerCAP' -Name 'rdgwAllowAutht-CAP' -UserGroups rdgwExtUsers -AuthMethod '1'

Затем создайте политику RD RAP:

1. В консоли RD Gateway Manager выберите Policies -> Resource Authorization Policies и выберите пункт меню Create New Policy -> Wizard;
2. Укажите имя политики: rdgwExternalAdmins;
3. Укажите имя группу, которой разрешено подключаться к внутренним RDS ресурсам;
4. На вкладке Network Resources нужно указать к каким RDS серверам разрешено подключаться вашим внешним пользователям (msk-rds-farm);
5. Далее укажите разрешенные для подключения порты. По-умолчанию рекомендуется открыть только стандартный RDP порт 3389. Но вы можете открыть и дополнительные порты;
6. Политика готова.

Правило RAP также можно создать с помощью PowerShell:
New-Item -Path RDS:GatewayServerRAP -Name allowextAdminMskRDS -UserGroups [email protected] -ComputerGroupType 1 -ComputerGroup [email protected]

Настройка SSL сертификата для Remote Desktop Gateway

Для защиты подключения к шлюзу RDS на нем нужно установить сертификат. Оптимально использовать коммерческий сертификат, выданный внешним центром сертификации. Возможно использовать бесплатного SSL сертификат Let’s Encrypt (установка Let’s Encrypt сертификата на IIS для Remote Desktop Gateway). Также вы можете использовать самоподписанный SSL сертификат Windows, но здесь имейте в виду что внешние клиенты должны обязательно доверять такому сертификату. Если клиент не доверяет сертификату на сервере RDGW, он не сможет подключиться к шлюзу (самоподписанные SSL сертификаты можно импортировать на клиентов вручную или через GPO) .

В поле Subject Name (CN) или Subject Alternative Name сертификата должно обязательно содержаться DNS имя сервера RDGW, которое будет использоваться для подключения внешними клиентами (доступное из интернета).

1. Откройте свойства сервера RDGW в консоли RD Gateway и перейдите на вкладку SSL Certificate;
2. В этом примере мы используем самоподписанный сертификат. Выберите пункт Create a self-signed certificate -> Create and Import Certificate;
3. Укажите имя сертификата (это DNS будет использоваться вашими клиентами для подключения к RDGW) и каталог, в который нужно сохранить сертификат (это сертификат нужно распространить на клиентов);

В Windows Server 2019 для подключения к RDGateway используются следующие порты:

• HTTPPort (default) —
  443/TCP
• UDPPort (default) —
  3391/UDP
  (использование транспортного протокола UDP не обязательно, но его поддержка позволяет значительно улучшить производительность туннеля и качество картинки в RDP сессии)

Не забудьте открыть (пробросить) эти порты на ваш RDGW хост на сетевом оборудовании.

Откройте консоль RDGW Manager и убедитесь, что в ней нет ошибок и все пункты зелёные.

Настройка RDP клиента для подключения шлюзу RD Gateway

Теперь можно настроить клиент Remote Desktop Connection для подключения к вашим внутренним RDS хостам через шлюз удаленных рабочих столов.

1. Запустите клиент
   mstsc.exe
   ;
2. На вкладке General укажите имя RDSH хоста, RDS фермы, или компьютера к которому вы хотите подключиться по RDP (можно также указать имя пользователя и использовать сохраненные учетные данные для RDP подключения);
3. Затем перейдите на вкладку Advanced и щелкните на кнопку Settings в разделе Connect from anywhere (Configure settings to connect through Remote Desktop Gateway when I am working remotely);
4. Выберите опцию Use these RD Gateway server settings, укажите внешнее DNS имя по которому доступен ваш RDGW сервер (напоминаю, что это имя должно быть указано в сертификате).Если вы используете нестандартный порт для RDGW, его нужно указать после имени сервера через двоеточие, например: gw.winitpro.ru:4443;
5. Чтобы не при подключении клиент не запрашивал пароль два раза, включите опцию Use my RD Gateway credentials for the remote computer;
6. Нажмите кнопку Connect и введите пароль для подключения к RDGW серверу в окне RD Gateway Server Credentials;
7. Клиент должен установить подключение с RDS/RDP хостом в вашей локальной сети;
8. Запустите консоль RD Gateway Manager, перейдите в раздел Monitoring и проверьте, что в списке отображается подключение вашего клиента.

Если вы используете утилиту RDCMan для RDP подключений, параметры RD Gateway можно задать на вкладке GatewaySetting. Включите опцию Use a TS Gateway server и укажите параметры подключения.

Отслеживать удачные и неудачные подключения пользователей через RDGW можно с помощью журнала событий Applications and Services Logs -> Microsoft -> Microsoft-Windows-TerminalServices-Gateway -> Operational.

При успешном подключении пользователя через RDGW в журнале появится событие с Event ID 205 от источника TerminalServices-Gateway

The user "winitprokbuldogov", on client computer "xx.xx.xx.xx", successfully connected to the remote server "msk-rdsman.winitpro.ru" using UDP proxy. The authentication method used was: "Cookie".

Если вы хотите запускать RemoteApp через RD Gateway, нужно добавить в *.rdp файл remoteapp следующие строки:

gatewayhostname:s:gw.winitpro.ru
gatewayusagemethod:i:1

В этой статье мы показали, как настроить роль Remote Desktop Gateway на Windows Server для реализации защищенного удаленного доступа в вашу сеть с помощью RDP over HTTPS.

Шлюз удаленных рабочих столов

Remote Desktop Gateway

Служба роли шлюза удаленных рабочих столов (Remote Desktop Gateway, или RD Gateway) позволяет пользователям обращаться к сетевым ресурсам (таким как серверы RD Session Host, выполняющие приложения RemoteApp, виртуальные машины на основе RD Virtualization Host или компьютеры с включенной службой Remote Desktop Services), которые расположены за брандмауэрами в частной сети, с любого клиента, находящегося в Интернете (или внутренних клиентов, если ТСР-порт 3389 является внутренне ограни­ченным портом). Для этого такой шлюз RD применяет так называемую SSL-ретрансляцию (также известную под названием виртуальной частной сети SSL (SSL VPN)). Выражаясь кратко, ретрансляция SSL позволяет клиентам подключаться к внутренним ресурсам через защищенное шифрованное HTTPS-соединение. В этом случае трафик, передаваемый через ретрансляцию SSL — это просто RDP (TCP 3389).

Шлюз RD должен быть установлен на Windows Server 2008 R2, но может выполнять SSL-ретрансляцию как для серверов Windows Server 2008 R2 RD Session Host, так и для Windows Server 2008/2003 Terminal Services.

Шлюз RD впервые появился в Windows Server 2008 как шлюз терминальных служб (TS Gateway). Причина, по которой Microsoft включила это средство в Windows Server 2008, состояла в том, что средства безопасности в основном были настроены на блокирование такого трафика, как RDP (TCP 3389). Другими словами, подразделения информационной безопасности обычно блокировали RDP или сопротивлялись открытию портов на своих брандмауэрах для них. С согласия сетевых компаний в Microsoft встроили решение SSL VPN в свои службы удаленных рабочих столов. Результатом их усилий стал шлюз RD, кото­рый позволяет пользователям получать доступ к службам удаленных рабочих столов, неза­висимо от их расположения.

Применение Remote Desktop Gateway

Шлюз RD применяет туннель HTTP Secure Sockets Layer/ Transport Layer Security (SSL/TLS) для передачи трафика RDP. Поскольку сервер шлюза RD использует HTTPS, требуется установка серверного сертификата аутентификации. Более того, устанавливаемый сертификат должен быть выпущен центром сертификации (СА), ко­торому доверяют клиенты, имеющие доступ к шлюзу RD. Другими словами, сертификат СА, который подписывает сертификат шлюза RD, должен располагаться в клиентском храни­лище Trusted Root Certification Authority. Доверенный сертификат может быть получен либо от публично доверенного СА, либо от внутреннего СА организации, которому уже доверяют клиенты.

Ниже перечислены дополнительные требования, которые должны быть приняты во внимание при использовании шлюза RD.

• Должна быть установлена служба удаленного вызова процедур через НТТР-прокси (Remote Procedure Call (RPC) over HTTP Proxy); она устанавливается при установке роли службы RD Gateway.
• Для успешного функционирования RPC over HTTP Proxy должна быть установлена и запущена служба Internet Information Services 7.5.
• На существующем сервере NPS, который может использоваться шлюзом RD, должна быть установлена служба сетевых политик (Network Policy Server — NPS).
• Серверы шлюзов RD и клиенты служб удаленных рабочих столов могут быть сконфи­гурированы на использование защиты сетевого доступа (Network Access Protection — NAP).