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

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.

title	description	author	ms.topic	ms.date	ms.author	manager
Deploy Remote Desktop Gateway role for Remote Desktop Services	How to deploy the Remote Desktop Gateway role for Remote Desktop Services.	Heidilohr	how-to	02/23/2021	helohr	femila

Deploy the Remote Desktop Gateway role

This article will tell you how to use the Remote Desktop Gateway (RD Gateway) role to deploy Remote Desktop Gateway servers in your Remote Desktop environment. You can install the server roles on physical machines or virtual machines depending on whether you are creating an on-premises, cloud-based, or hybrid environment.

Install the RD Gateway role

1. Sign into the target server with administrative credentials.

2. In Server Manager, select Manage, then select Add Roles and Features. The Add Roles and Features installer will open.

3. In Before You Begin, select Next.

4. In Select Installation Type, select Role-Based or feature-based installation, then select Next.

5. For Select destination server, select Select a server from the server pool. For Server Pool, select the name of your local computer. When you’re done, select Next.

6. In Select Server Roles > Roles, select Remote Desktop Services. When you’re done, select Next.

7. In Remote Desktop Services, select Next.

8. For Select role services, select only Remote Desktop Gateway When you’re prompted to add required features, select Add Features. When you’re done, select Next.

9. For Network Policy and Access Services, select Next.

10. For Web Server Role (IIS), select Next.

11. For Select role services, select Next.

12. For Confirm installation selections, select Install. Don’t close the installer while the installation process is happening.

Configure the RD Gateway role

Once the RD Gateway role is installed, you’ll need to configure it.

To configure the RD Gateway role:

1. Open the Server Manager, then select Remote Desktop Services.

2. Go to Servers, right-click the name of your server, then select RD Gateway Manager.

3. In the RD Gateway Manager, right-click the name of your gateway, then select Properties.

4. Open the SSL Certificate tab, select the Import a certificate into the RD Gateway bubble, then select Browse and Import Certificate….

5. Select the name of your PFX file, then select Open.

6. Enter the password for the PFX file when prompted.

7. After you’ve imported the certificate and its private key, the display should show the certificate’s key attributes.

[!NOTE]
Because the RD Gateway role is supposed to be public, we recommend you use a publicly issued certificate. If you use a privately issued certificate, you’ll need to make sure to configure all clients with the certificate’s trust chain beforehand.

Next steps

If you want to add high availability to your RD Gateway role, see Add high availability to the RD Web and Gateway web front.

title	description	author	ms.topic	ms.date	ms.author	manager
Deploy Remote Desktop Gateway role for Remote Desktop Services	How to deploy the Remote Desktop Gateway role for Remote Desktop Services.	Heidilohr	how-to	02/23/2021	helohr	femila

Deploy the Remote Desktop Gateway role

This article will tell you how to use the Remote Desktop Gateway (RD Gateway) role to deploy Remote Desktop Gateway servers in your Remote Desktop environment. You can install the server roles on physical machines or virtual machines depending on whether you are creating an on-premises, cloud-based, or hybrid environment.

Install the RD Gateway role

1. Sign into the target server with administrative credentials.

2. In Server Manager, select Manage, then select Add Roles and Features. The Add Roles and Features installer will open.

3. In Before You Begin, select Next.

4. In Select Installation Type, select Role-Based or feature-based installation, then select Next.

5. For Select destination server, select Select a server from the server pool. For Server Pool, select the name of your local computer. When you’re done, select Next.

6. In Select Server Roles > Roles, select Remote Desktop Services. When you’re done, select Next.

7. In Remote Desktop Services, select Next.

8. For Select role services, select only Remote Desktop Gateway When you’re prompted to add required features, select Add Features. When you’re done, select Next.

9. For Network Policy and Access Services, select Next.

10. For Web Server Role (IIS), select Next.

11. For Select role services, select Next.

12. For Confirm installation selections, select Install. Don’t close the installer while the installation process is happening.

Configure the RD Gateway role

Once the RD Gateway role is installed, you’ll need to configure it.

To configure the RD Gateway role:

1. Open the Server Manager, then select Remote Desktop Services.

2. Go to Servers, right-click the name of your server, then select RD Gateway Manager.

3. In the RD Gateway Manager, right-click the name of your gateway, then select Properties.

4. Open the SSL Certificate tab, select the Import a certificate into the RD Gateway bubble, then select Browse and Import Certificate….

5. Select the name of your PFX file, then select Open.

6. Enter the password for the PFX file when prompted.

7. After you’ve imported the certificate and its private key, the display should show the certificate’s key attributes.

[!NOTE]
Because the RD Gateway role is supposed to be public, we recommend you use a publicly issued certificate. If you use a privately issued certificate, you’ll need to make sure to configure all clients with the certificate’s trust chain beforehand.

Next steps

If you want to add high availability to your RD Gateway role, see Add high availability to the RD Web and Gateway web front.

Опубликовано: 08.07.2020

Используемые термины: Remote Desktop Gateway, Active Directory, Терминальный сервер.

В данном руководстве мы рассмотрим развертывание роли шлюза удаленных рабочих столов (Remote Desktop Gateway или RDG) на отдельном сервере с Windows Server 2019. Действия будут аналогичны для Windows Server 2012 и 2016 (даже, в основных моментах, 2008 R2). Предполагается, что в нашей инфраструктуре уже имеются:

1. Служба каталогов Active Directory — настроено по инструкции Как установить роль контроллера домена на Windows Server.

2. Два терминальных сервера — настроено по инструкции Установка и настройка терминального сервера на Windows Server.

Пошагово, мы выполним следующие действия:

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

Открываем Диспетчер серверов:

Переходим в Управление — Добавить роли и компоненты:

При появлении окна приветствия нажимаем Далее (при желании, можно поставить галочку Пропускать эту страницу по умолчанию):

На страницы выбора типа установки оставляем выбор на Установка ролей или компонентов:

Выбираем целевой сервер — если установка выполняется на сервере локально, то мы должны увидеть один сервер для выбора:

Ставим галочку Службы удаленных рабочих столов:

Дополнительные компоненты нам не нужны:

… просто нажимаем Далее.

На странице служб удаленных рабочих столов идем дальше:

Выбираем конкретные роли — нам нужен Шлюз удаленных рабочих столов. После установки галочки появится предупреждение о необходимости поставить дополнительные пакеты — кликаем по Добавить компоненты: 

Откроется окно для настроек политик:

… нажимаем Далее.

Откроется окно роли IIS:

… также нажимаем Далее.

При выборе служб ролей веб-сервера ничего не меняем:

… и идем дальше.

В последнем окне ставим галочку Автоматический перезапуск конечного сервера, если требуется:

Нажимаем Установить:

Дожидаемся окончания установки роли:

Сервер может уйти в перезагрузку.

Настройка RDG

Для настройки Microsoft Remote Desktop Gateway мы создадим группу компьютеров в Active Directory, настроим политику для RDG и создадим сертификат.

Создание групп для терминальных серверов

Политика ресурсов позволит задать нам конкретные серверы, на которые терминальный шлюз позволит нам подключаться. Для этого мы откроем консоль Active Directory — Users and computers (Пользователи и компьютеры Active Directory) и создаем группу:

* в данном примере мы создаем группу All terminals в организационном юните Servers Group. Это группа безопасности (Security), локальная в домене (Domain local).

Добавим в нашу группу терминальные серверы:

* в данном примере у нас используются два сервера — Terminal-1 и Terminal-2.

Закрываем консоль Active Directory — Users and computers.

Настройка политик

Для предоставления доступа к нашим терминальным серверам, создадим политики для подключений и ресурсов.

В диспетчере сервера переходим в Средства — Remote Desktop Services — Диспетчер шлюза удаленных рабочих столов:

Раскрываем сервер — кликаем правой кнопкой по Политики — выбираем Создание новых политик безопасности:

Устанавливаем переключатель в положении Создать политику авторизации подключений к удаленным рабочим столам и авторизации ресурсов удаленных рабочих столов (рекомендуется):

Даем название политике:

Задаем параметры авторизации:

* мы указали, что пользователи должны подтверждать право вводом пароля, также мы указали, что для применения политики они должны принадлежать группе Domain Users.

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

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

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

В следующем окне мы увидим вне введенные настройки:

Идем далее.

Откроется страница создания политики для авторизации ресурса — задаем для нее название:

Указываем группу пользователей, для которой будет применяться политика:

* как и при создании первой политики, мы добавили группу Domain Users.

Теперь выбираем группу ресурсов, на которую будет разрешен доступ со шлюза терминалов:

* мы выбрали группу, созданную нами ранее в AD.

Указываем разрешенный для подключения порт или диапазон портов:

* в данном примере мы разрешим подключение по порту 3389, который используется по умолчанию для RDP.

Нажимаем Готово:

Политики будут созданы.

Настройка сертификата

Для работы системы нам необходим сертификат, который можно купить или получить бесплатно от Let’s Encrypt. Однако, с некоторыми неудобствами, будет работать и самоподписанный. Мы рассмотрим вариант настройки с ним.

Запускаем «Диспетчер шлюза удаленных рабочих столов» — кликаем правой кнопкой по названию нашего сервера — выбираем Свойства:

Переходим на вкладку Сертификат SSL:

Выбираем вариант Создать сомозаверяющий сертификат и кликаем по Создать и импортировать сертификат:

Задаем или оставляем имя для сертификата — нажимаем OK:

Мы увидим информацию о создании сертификата:

Консоль диспетчера шлюза перестанет показывать ошибки и предупреждения:

Сервер готов к работе.

Подключение к серверу терминалов через шлюз

Выполним первое подключение с использованием шлюза. В качестве клиентской операционной системы могут использоваться Windows, Linux, Mac OS. Рассмотрим пример на Windows 10.

Запускаем «Подключение к удаленному рабочему столу» (приложение можно найти в Пуск или ввести команду mstsc). На вкладке Общие вводим локальное имя конечного сервера, к которому мы хотим подключиться:

* в нашем случае мы будем подключаться к серверу terminal-1.dmosk.local.

Переходим на вкладку Дополнительно и кликаем по Параметры:

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

* важно указать именно имя сервера, а не IP-адрес. В моем примере имя сервера rdp.dmosk.local (данное имя не является правильным внешним, но это только пример).

Кликаем Подключить:

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

Переходим на вкладку Состав и кликаем Копировать в файл:

Указываем путь для выгрузки файла:

Открываем папку, куда сохранили сертификат. Кликаем по сохраненному файлу правой кнопкой и выбираем Установить сертификат:

Выбираем Локальный компьютер — Далее:

В качестве размещения сертификата выбираем Доверенные корневые центры сертификации:

Импортируем сертификат.

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

Система запросит логин и пароль для подключения (возможно, дважды) — вводим данные для учетной записи с правами на подключение (на основе настройки политики RDG).

Настройка Remoteapp через Gateway

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

…
gatewayhostname:s:rdg.dmosk.local
gatewayusagemethod:i:1
…

* где:

• gatewayhostname:s:rdg.dmosk.local — добавленная строка. Настройка говорит, что если при подключении к серверу нужно использовать шлюз, то это должен быт rdg.dmosk.local.
• gatewayusagemethod:i:1 — отредактированная строка. Указывает, что необходимо использовать шлюз.

Пробуем подключиться.

Несколько терминальных серверов и dns round robin

При наличие нескольких серверов терминалов, мы можем создать несколько записей в DNS, чтобы получать по round robin разные серверы:

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

Для решения переходим в настройку шлюза — кликаем правой кнопкой по Политики авторизации ресурсов и выбираем Управление локальными группами компьютеров:

Выбираем нужную группу компьютеров и нажимаем Свойства:

* в моем случае это была единственная группа, созданная по умолчанию.

На вкладке Сетевые ресурсы добавляем имя, созданное в DNS:

Теперь подключение будет выполняться без ошибок.

Возможные ошибки

При подключении мы можем столкнуть со следующими ошибками.

1. Учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов.

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

2. Возможно, удаленный компьютер указан в формате NetBIOS (например, computer1), но шлюз удаленных рабочих столов ожидает полное доменное имя или IP-адрес (например, computer1.fabrikam.com или 157.60.0.1).

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

3. Сертификат шлюза удаленных рабочих столов просрочен или отозван.

В данном случае нужно проверить, какой сертификат привязан к RDG. Также нужно убедиться, что привязанный сертификат, на самом деле, не просрочен или отозван. В крайнем случае, можно заново создать сертификат.

Для того чтобы повысить уровень безопасности 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

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

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

Сначала познакомимся с ролью Remore Gateway, затем перейдем к Web Client. Увидим как будет выглядеть подключение со стороны клиента с разных ОС. Также подведем некоторые итоги по проведенной работе.

Remote Desktop Gateway

Описание функционала

Компонент RD Gateway представляет из себя стандартную (доступную из коробки) роль Windows Server. Суть заключается в том, что на периметре локальной сети разворачивается хост на котором инсталлируется компонент RD Gateway. Как нам подсказывает название, он является шлюзом для удаленных подключений. Само подключение производится через RDP клиент (в ОС отличных от Windows может потребоваться поддержка функционала шлюза подключений).

Принципиальным отличием работы компонента от обычного подключения RDP является тот факт, что соединение RDP устанавливается поверх HTTPS (веб-сервер IIS будет инсталлирован автоматически при установке).

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

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

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

• Windows Server 2008+ в качестве ОС узла установки роли.
• Наличие развернутого домена Active Directory.

Наш тестовый стенд

Чтобы легче было понимать материал, опишу нашу тестовую лабораторию на которой мы будем проводить тесты.

Стенд состоит из 4х узлов:

• lab-dc1.party.hard — контроллер домена.
• lab-rds1.party.hard — сервер, на котором уже создано тестовое развертывание служб удаленных рабочих столов.
• lab-rdgw1.party.hard — сервер шлюза удаленных рабочих столов и компонента web client.
• lab-client1 — узел вне домена, моделирует клиентское подключение.

Установка, конфигурация и проверка роли Remote Desktop Gateway

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

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

Начнем с сервера lab-rds1.party.hard. Для инсталляции роли нам необходимо в Диспетчере серверов, где уже существует развертывание инфраструктуры RDS, добавить сервер lab-rdgw1.party.hard для управления.

Затем, через иконку RD Gateway, добавить роль узлу lab-rdgw1.party.hard.

Следующим этапом мы займемся конфигурацией сертификатов.

В результате выполненных действий, статус изменится на Готово к применению.

Проверяем подключение со стороны клиента

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

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

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

Так выглядит подключение к шлюзу через стандартный RDP клиент Windows.

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

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

Мониторинг удаленных подключений

Для того, чтобы узнать информацию об успешных или неудачных попытках подключения к шлюзу мы можем воспользоваться инструментом Просмотр событий. Нужную нам информацию мы найдем журналах Безопасность и Microsoft-Windows-TerminalServices-Gateway.

Для примера я произведу 2 попытки входа.

Первая — учетные данные некорректны.

Вторая — учетные данные корректны.

Нюансы эксплуатации

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

Необходимость решения вопроса с SSL сертификатом для подключения к шлюзу

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

• Использование самоподписанного сертификата и ручной импорт клиентам в случае если ПК не в домене и автоматизация этого процесса через GPO если ПК в домене.
• Использование бесплатного сертификата Let’s Encrypt (90 дней). О выпуске и установке сертификата вы можете почитать — здесь.
• Покупка сертификата безопасности на год.

Невозможность указать нестандартный порт подключения на старых RDP клиентах Microsoft

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

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

Решение только одно — установка обновления RDP клиента. Начиная с Windows 8 клиент уже обновлен и такой проблемы замечено небыло.

Возможные проблемы при подключении с ОС отличных от Windows

Функционал, необходимый для подключения через шлюз удаленных рабочих столов, интегрирован в стандартный RDP клиент Microsoft. Однако, если необходимо подключаться с других ОС, необходимо предварительно проверить возможность подключения через шлюз.

HTML5 Web client

Описание функционала

Компания Microsoft пошла дальше в вопросах предоставления удаленного доступа пользователям и выпустила специальный Web client компонент, позволяющий подключаться к рабочему столу или RemoteApp приложению через обычный веб-браузер.

Подобный подход имеет большое преимущество перед классическим подключением через шлюз. Теперь мы не зависим от ОС или конфигурации RDP клиента. Нам достаточно иметь на устройстве любой современный браузер для удаленного подключения.

Схема работы примерно та же. Мы организуем хост с установленным компонентом Web Client на периметре сети и публикуем один порт в сеть интернет.

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

Также прошу обратить внимание, что компонент Web client и роль Remote Desktop Web Access не одно и тоже. RD Web Access позволяет нам публиковать сеансы и RemoteApp приложения, которые, по факту, будут подключаться через RDP. Web client позволяет нам устанавливать сессию непосредственно в веб-браузере.

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

• В сети должно быть сконфигурировано развертывание удаленных рабочих столов.
• Версия ОС на узлах с ролями Connection Broker, Web Access, Session Host, Gateway должна быть Windows Server 2016+.
• Лицензии CAL должны выдаваться на пользователя, не на устройство.
• На узле Web client должно быть установлено обновление KB4025334.
• Наличие развернутого домена Active Directory.

Установка, конфигурация и проверка Web client

В этой статье мы развернем компонент Web client, как и Remote Desktop Gateway, на отдельном узле — lab-rdgw1.party.hard. Воспользуемся уже сконфигурированной инфраструктурой, описанной выше.

Т.к мы планируем развернуть компонент на узле lab-rdgw1.party.hard, нам необходимо установить на него роль Web Access, иначе, мы столкнемся с невозможностью установки Web client.

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

Теперь перейдем к установке роли Web Access. Для этого выберем пункт Добавить сервера Web Access в Обзоре развертывания.

Укажем узел для развертывания роли.

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

Теперь переходим непосредственно к установке Web client. На текущий момент установка компонента возможна только через PowerShell. Может быть, со временем, разработчики добавят возможность установки через GUI.

Сперва нам необходимо обновить модуль PowershellGet. Открываем Powershell от имени администратора и вводим:

Install-Module -Name PowerShellGet -Force

Для корректной работы нам нужно закрыть и еще раз открыть Powershell от имени администратора, иначе установленный модуль не будет работать.

После установки PowershellGet устанавливаем модуль RDWebClientManagement. Для этого вводим в Powershell:

Install-Module -Name RDWebClientManagement

Также подтверждаем установку и соглашаемся с условиями в процессе выполнения командлета.

Теперь установим модуль Web client выполнив в Powershell командлет:

Install-RDWebClientPackage

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

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

Только что полученный сертификат переносим на сервер lab-rdgw1.party.hard любым доступным способом и сами возвращаемся на него же. 🙂

Импортируем открытую часть сертификата для развертывания Web client.

Import-RDWebClientBrokerCert "C:usersAdministratorDesktoplab-rds1.party.hard.cer"

И наконец публикуем компонент.

Publish-RDWebClientPackage -Type Production -Latest

Дополнительная литература

Для более подробных инструкций предлагаю посмотреть документацию Microsoft.

https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin

Проверяем подключение со стороны клиента

Итак, проверим как наши пользователи будут удаленно подключаться. Для этого запускаем веб-браузер и вводим внешний fqdn-адрес:
https://ext-lab-rdgw1.party.hard/RDWeb/webclient/

Запустим, единственный в нашем случае, опубликованный ресурс.

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

Для этого точно также запускаем веб-браузер и вводим внешний fqdn-адрес:
https://ext-lab-rdgw1.party.hard/RDWeb/webclient/

Подключение к хостам вне коллекции RDS

У некоторых может возникнуть вопрос:

Возможно ли подключение через веб-браузер к серверам, которые не находятся в коллекции RDS? А к клиентским компьютерам?

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

Ниже я покажу пример публикации удаленного подключения к серверу lab-dc1.party.hard.

Подход имеет свои недостатки. Таким образом мы, фактически, устанавливаем 2 RDP соединения. Сначала с узлом RDSH и отсюда устанавливаем новое соединение с нужным нам хостом.

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

• Сессии
• Приложения RemoteApp

Поэтому, если необходимо сохранить у пользователя как подключение к RDSH узлу, так и к другому серверу или клиентскому компьютеру, необходимо изменить один параметр в реестре.

HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerCentralPublishedResourcesPublishedFarms<collection>RemoteDesktops<collection>ShowInPortal

Значение этого ключа должно быть равно 1.

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

Мониторинг удаленных подключений

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

Для примера я произведу 2 попытки входа.

Первая — учетные данные некорректны.

Вторая — учетные данные корректны.

При использовании инструментов для автоматизации процесса можно получить более удобный мониторинг и интегрировать его в другие сервисы (напр. Zabbix).

Нюансы эксплуатации

Отсутствие возможности копирования файлов

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

Двойное RDP подключение к хостам вне коллекции RDS

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

Некорректная работа с NAT

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

Итоги

Мнение

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

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

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

Также администраторы получают возможность централизовано (через свойства коллекций или Active Directory) управлять доступом и заниматься мониторингом подключений. Это очень удобно с точки зрения интеграции с уже существующей инфраструктурой. У специалистов по эксплуатации отпадает необходимость дружить другое ПО с учетными данными пользователей в Active Directory.

Коллеги! Если у вас есть замечания или дополнения по предмету этой статьи, прошу оставить комментарий. Возможно, они кому-то пригодятся в будущем.