Настройка remote desktop gateway windows server 2019

Опубликовано: 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. Также нужно убедиться, что привязанный сертификат, на самом деле, не просрочен или отозван. В крайнем случае, можно заново создать сертификат.

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.

Установка службы удаленных рабочих столов (RDS) на Windows Server 2019 состоит из многих шагов, но в действительности это очень просто. Из статьи вы узнаете о том, как установить эту службу в доменной среде, которая требует наличия двух серверов.

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

Перед началом установки RDS необходимо убедиться, что выполняются два требования,  а именно:

• все серверы подключены к домену;
• есть по крайней мере два доступных сервера.

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

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

Для начала мы добавим к основному RDS-серверу следующие роли:

• RD Connection Broker (Посредник подключений к удаленному рабочему столу);
• RD Web Access (Веб-доступ к удаленным рабочим столам);
• RD Session Host (Узел сеансов удаленных рабочих столов).

Пошаговая установка

1. В диспетчере сервера на основном RDS-сервере, на котором выполняется установка, откройте Add Roles and Features Wizard (мастер добавления ролей и компонентов) и выберите Remote Desktop Services installation(установку службы удаленных рабочих столов).

2. Для этой инструкции мы используем опцию Quick Start (Быстрый старт), но если вам требуется больше контроля над процессом установки, вы можете выбрать Standard Deployment (Стандартную установку), которая позволяет редактировать большее количество настроек.

3. Далее мы выбираем Session-based desktop deployment (Установка рабочих столов на основе сеансов), так как это стандартная модель подключения к удаленным приложениям и удаленным рабочим столам, используемая в большинстве установок RDS.

4. В разделе Server Selection (Выбор сервера), выберите сервер, на который мы устанавливаем RDS.

5. Чтобы начать установку, выберите Restart the destination server automatically if required (Автоматический перезапуск конечного сервера в случае необходимости) и кликните на Deploy (Установить).

6. Проверьте, что все роли успешно установлены перед тем, как переходить к следующим шагам.

Добавление дополнительного сервера

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

1. Чтобы добавить дополнительный сервер, кликните правой кнопкой мыши на All Servers (Все серверы), выберите Add Servers (Добавление серверов), а затем выберите нужный сервер в Active Directory.

• 
• 

2. Перейдите на экран Remote Desktop Services (Службы удаленных рабочих столов) и кликните на зеленом плюсе над RD Licensing (Лицензирование удаленных рабочих столов).

3. Откроется окно Add RD Licensing Servers (Добавление серверов лицензирования удаленных рабочих столов), в котором вы сможете выбрать дополнительный сервер для роли RD Licensing.

4. Кликните на Add (Добавление), чтобы установить роль на дополнительный сервер.

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

Добавление роли RD Gateway Role

Теперь нам нужно добавить RD Gateway Role (роль службы шлюза удаленных рабочих столов) к основному RDS-серверу.

1. На экране Remote Desktop Services (Службы удаленных рабочих столов) кликните на зеленом плюсе над RD Gateway (Шлюз удаленных рабочих столов).
2. Выберите основной RDS-сервер для установки этой роли.

3. Присвойте самоподписанному SSL-сертификату полное доменное имя.

4. Кликните Next и потом Add, чтобы установить роль на основной RDS-сервер.

Настройка параметров установки

Теперь, когда все роли установлены, можно перейти к настройке параметров установки.

1. Откройте экран Remote Desktop Services и в выпадающем списке Tasks (Задания) кликните на Edit Deployment Properties (Редактирование параметров установки).

2. На экране RD Gateway оставьте настройки по умолчанию и кликните на пункте меню RD Licensing.

3. Выберите Per User (По количеству пользователей) на экране RD Licensing. Вы можете выбрать любую из двух опций, но в целях обучения мы выбираем Per User.

4. Обратите внимание на URL на экране RD Web Access (Веб-доступ к удаленным рабочим столам). Позже мы будем его использовать для доступа к установленным приложениям.

5. В целях тестирования можно оставить сертификаты как Not Configured (Не сконфигурированные) и нажать OK, чтобы сохранить параметры установки. 

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

Верификация службы удаленных рабочих столов

По умолчанию после установки создается QuickSessionCollection, куда входят Calculator, WordPad и Paint в качестве удаленных приложений. Мы можем использовать это для тестирования установки RDP.

1. Для тестирования IIS перейдите по ссылке, представленной на экране RD Web Access, или используйте https://localhost/rdweb/, если вы находитесь на RDP-сервере.

2. Подключитесь к сеансу IIS RDS с помощью доменной учетной записи.

3. Запустите удаленное соединение: то, которое вы сконфигурировали, или удаленное приложение по умолчанию.

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

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

Из этой статьи вы узнаете, как с помощью роли шлюза удаленных рабочих столов развертывать серверы шлюза удаленных рабочих столов в среде Виртуального рабочего стола Azure или удаленного рабочего стола. Роли сервера можно установить на физические компьютеры или виртуальные машины, в зависимости от того, какую среду вы создаете: локальную, облачную или гибридную.

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

Войдите на целевой сервер с учетными данными администратора.

В диспетчере сервера выберите элемент Управление, а затем — команду Добавить роли и компоненты. Откроется установщик для добавления ролей и компонентов.

В Перед началом выберите Далее.

На странице Выбор типа установки выберите элемент Установка ролей или компонентов. Затем нажмите кнопку Далее.

На странице Выбор целевого сервера щелкните элемент Выберите сервер из пула серверов. В поле Пул серверов выберите имя локального компьютера. Затем щелкните Далее.

В окне Выбор ролей сервера > Роли выберите элемент Службы удаленных рабочих столов. Затем щелкните Далее.

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

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

На странице Службы политики сети и доступа нажмите кнопку Далее.

На странице Роль веб-сервера (IIS) нажмите кнопку Далее.

На странице Выбор служб ролей нажмите кнопку Далее.

На странице Подтверждение выбранных элементов для установки выберите элемент Установить. Не закрывайте установщик во время установки.

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

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

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

Откройте диспетчер сервера и выберите элемент Службы удаленных рабочих столов.

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

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

Откройте вкладку SSL-сертификат, выберите всплывающий элемент Import a certificate into the RD Gateway (Импорт сертификата в шлюз удаленных рабочих столов), а затем выберите элемент Найти и импортировать сертификат.

Выберите имя PFX-файла и щелкните элемент Открыть.

При появлении запроса введите пароль для PFX-файла.

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

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

Дальнейшие действия

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

Источник

Как настроить Remote Desktop Gateway

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

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

Виртуальный сервер на базе Windows

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

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

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

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

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

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

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

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

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

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

В открывшемся окне выберите 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 способа импорта сертификатов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

P. S. Другие инструкции:

Ознакомиться с другими инструкциями вы можете на нашем сайте. А чтобы попробовать услугу — кликните на кнопку ниже.

Источник

Реализация высокой доступности в веб-интерфейсе шлюза и веб-доступа к удаленным рабочим столам

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

Можно развернуть ферму с веб-доступом к удаленным рабочим столам и шлюзом удаленных рабочих столов, чтобы повысить доступность и масштаб развертывания служб удаленных рабочих столов (RDS) под управлением Windows Server.

Следуя инструкциям ниже, добавьте сервер веб-доступа к удаленным рабочим столам и сервер шлюза в существующее базовое развертывание RDS.

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

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

Шаг 1. Настройка нового сервера для добавления в среду RDS

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

Шаг 2. Настройка свойств веб-доступа к удаленным рабочим столам и шлюза удаленных рабочих столов на новом сервере

Шаг 3. Настройка балансировки нагрузки для сервера веб-доступа к удаленным рабочим столам и сервера шлюза удаленных рабочих столов

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

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

Источник

Установка и использование Remote Desktop Gateway

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка RDG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Расскажем подробно, как настроить сервис Remote Desktop Gateway (RDG) на домене на платформах под управлением Windows Server.

Что такое RDG

Компания Microsoft предлагает использовать удаленный доступ к рабочим столам по протоколу RDP (Remote Desktop Protocol). Для создания защищенного соединения используется сервис RDG (Remote Desktop Gateway). Его особенность в том, что он использует подключение по протоколу HTTPS. При этом создается надежный канал связи, который гарантирует пользователю должный уровень защиты. Соответственно, нет нужды использовать сторонние сервисы по созданию VPN-туннеля.

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

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

Запускаем «Диспетчер серверов», переходим на правой стороне во вкладку «Добавить роль»:

Для примера используем первый пункт:

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

После нажатия кнопки «Next» на экране отобразится информация о выбранной роли. Соглашаемся и переходим к следующему шагу. Теперь в разделе Role Server появилась добавленная функция. Заходим в нее и отмечаем опции, которые необходимы администратору. Для примера, активируем RDG:

Мастер настройки проверяет выбранную роль и совместимость с серверной ОС. Если необходима установка дополнительных компонентов, то автоматически откроется рабочая область с отмеченными компонентами. Чтобы RDG работал, в операционной системы должны быть установлены сервисы web-администрирования с полным набором программных инструментов:

Рекомендуется оставить по умолчанию выбранные сервисы. Нажимаем «Next», подтверждаем установку.

Доступ к ресурсам

После установки выбранной роли переходим в главное окно «Диспетчера серверов». Выбираем раздел «Инструменты» и переходим к настройке RDG. Откроется новое рабочее окно (RD Gateway Manager). В нем переходим во вкладку с именем сервера, далее выбираем «Политики» и сконфигурируем авторизированные подключения. Нажимаем кнопку «Wizard», чтобы открыть мастер настройки:

Установщик предложит на выбор 3 пункта. Оставляем активным первую опцию:

Задаем имя новому шаблону, нажимаем «Next». Следующий этап — выбор метода аутентификации и списка пользователей, которые получат доступ к политике. Авторизация разрешена при помощи пароля либо смарт-карты, либо оба варианта. Оставляем только по паролю. Далее нажимаем кнопку «Добавить группу» и добавляем данные в поле:

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

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

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

Теперь выбираем группу ресурсов:

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

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

Чтобы доступ через RDG был активен, также необходимо создать сертификат. В рабочем окне RDG Manager переходим к разделу «Имя сервера». Через контекстное меню открываем пункт «Просмотреть или изменить свойства сертификата». В открывшемся окне переключаемся на вкладку SSL. Доступно 3 варианта создания. Выбираем пункт, отмеченный красным на скриншоте:

Теперь прописываем имя сертификата и путь, по которому он будет храниться:

Нажимаем «ОК» для генерации. В итоге рабочая область менеджера выглядит следующим образом:

Для повышения уровня безопасности рекомендуется сменить порт по умолчанию для подключения через Remote Desktop Protocol. Открываем в RDG Manager раздел «Действия», пункт «Свойства». Переходим во вкладку «Свойства транспортировки». В поле, отмеченным красным, меняем значение:

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

Как подключиться

Теперь необходимо настроить подключение через RDP. Нажимаем сочетание клавиш Win+R, вводим команду mstsc.exe. В открывшемся окне нажимаем «Параметры»:

В поле, отмеченном красным, прописываем адрес сервера, а через двоеточие в конце отмечаем номер порта. Нажимаем «ОК».

Теперь переходим во вкладку «Общие». Прописываем имя домена и пользователя:

Мастер настройки попросит указать пароль для учетного имени. Вводим его. Конфигурирование завершено.

Аverage rating : 3.7

Оценок: 3

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

+375 (173) 88-72-49

700
300

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

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

+375 (173) 88-72-49

700
300

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

700
300

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

Сначала познакомимся с ролью 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.

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

Remote Desktop Gateway is one of the Remote Desktop Services role services in Windows Server for providing secure access from the Internet to desktop services and RemoteApp-published applications via an HTTPS gateway. A server with the RD Gateway role acts as an intermediary between external clients and internally deployed RDS services. With RDGW, users do not need to set up a VPN to connect to RDS on their corporate network. The standard Remote Desktop Connection client (mstsc.exe) is used to connect. In this article, we will walk through the process of deploying Remote Desktop Gateway on Windows Server 2019 (the instruction is applicable for Windows Server 2022/2016 and 2012 R2).

Installing the RDS-Gateway Role in Windows Server.

The Remote Desktop Gateway service is not a required component of an RDS farm, so it must be installed separately. In most cases, it is recommended to use a separate server to deploy RDGW, or you can combine it with RDWeb.

It is assumed that you already have an Active Directory directory service and an RDS server farm deployed on your network.

You can install the Remote Desktop Gateway role through Server Manager (Add roles & Features -> Server Role -> Remote Desktop Services) or using PowerShell.

Installing the RDGW service also installs the IIS web server and the NPS (Network Policy Server) role.

Make sure the RDS-Gateway role is installed:

Get-WindowsFeature RDS*

Or install the role on Windows Server using the Install-WindowsFeature command:

Install-WindowsFeature RDS-Gateway -IncludeAllSubFeature –IncludeManagementTools

Create access groups in Active Directory using the ADUC console or using PowerShell :

rdgwExtUsers – a group of users who are allowed to authenticate on the RDGW;
rdgwExternalAdmins – group for access to terminal servers via RDGW;
msk-rds-farm – Should include all RDSH and RD Conneciton Broker hosts that you want to allow to connect to through the Remote Desktop Gateway.

Configuring RDS Gateway Access Policies.

The RD Gateway Manager console (tsgateway.msc) is used to manage policies and access rules on the RDGW. Here you need to configure two types of policies:

• Connection Authorization Policies (RD CAP) — determine who is allowed to log in to the RDS gateway;
• Resource Authorization Policies (RD RAP) — determine who and what resources (computers) of the internal network are allowed to connect through RDGW.

Create an RD CAP policy first:

• Expand Policies -> Connection Authorization Policies and select the menu item Create New Policy -> Wizard;
• Specify the policy name (rdgwExtUsers);
• Select the type of authentication (by password and/or by smart card), specify the group of users who are allowed to authenticate on the RDGW;

• In the Enable or Disable Device Redirection window, you can specify which devices are allowed to pass into the RDP session (clipboard, printers, local drives, etc.);

• Next, you can configure timeouts for RDP sessions;
• Confirm the creation of the policy.

You can also create an RDGW Client Access Policy using PowerShell:

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

Then create an RD RAP policy:

• In the RD Gateway Manager console, select Policies -> Resource Authorization Policies and select the menu item Create New Policy -> Wizard;

• Specify the policy name: rdgwExternalAdmins;
• Specify the name of the group that is allowed to connect to internal RDS resources;

• On the Network Resources tab, you need to specify which RDS servers your external users are allowed to connect to (msk-rds-farm);

• Next, specify the ports allowed for connection. By default, it is recommended to open only the standard RDP port 3389. But you can open additional ports as well;

• The policy is ready.

You can also create a RAP rule using PowerShell:

New-Item -Path RDS:GatewayServerRAP -Name allowextAdminMskRDS -UserGroups rdgwExternalAdmins@site.io -ComputerGroupType 1 -ComputerGroup msk-rds-farm@site.io

Setting up an SSL certificate for Remote Desktop Gateway.

To secure the connection to the RDS gateway, you need to install a certificate on it. It is best to use a commercial certificate issued by an external CA. It is possible to use the free SSL certificate Let’s Encrypt (installing Let’s Encrypt certificate on IIS for Remote Desktop Gateway). You can also use a self-signed Windows SSL certificate, but keep in mind here that external clients must be sure to trust such a certificate. If the client does not trust the certificate on the RDGW server, it will not be able to connect to the gateway (self-signed SSL certificates can be imported to clients manually or via GPO).

The Subject Name (CN) or Subject Alternative Name field of the certificate must contain the DNS name of the RDGW server that will be used for connection by external clients (accessible from the Internet).

• Open the properties of the RDGW server in the RD Gateway console and go to the SSL Certificate tab;
• In this example, we are using a self-signed certificate. Select Create a self-signed certificate -> Create and Import Certificate;

• Specify the name of the certificate (this DNS will be used by your clients to connect to the RDGW) and the directory where you want to save the certificate (this certificate needs to be distributed to clients);

Windows Server 2019 uses the following ports to connect to RDGateway:

• HTTP Port (default) 443/TCP
• UDPPort (default) — 3391/UDP (using the UDP transport protocol is not necessary, but its support can significantly improve tunnel performance and image quality in an RDP session)

Don’t forget to open (forward) these ports to your RDGW host on the network equipment.

Open the RDGW Manager console and make sure that there are no errors in it and all the items are green.

Configuring an RDP client to connect to the RD Gateway.

You can now configure the Remote Desktop Connection client to connect to your internal RDS hosts through the Remote Desktop Gateway.

If you are using a self-signed certificate on the RDGW, you must place it in Trusted Root Certification Authorities on the client.

• Start the client mstsc.exe ;
• On the General tab, specify the name of the RDSH host, RDS farm, or computer to which you want to connect via RDP (you can also specify a username and use the saved credentials for RDP connection);

• Then go to the Advanced tab and click the Settings button under Connect from anywhere (Configure settings to connect through Remote Desktop Gateway when I am working remotely);

• Select the option Use these RD Gateway server settings , specify the external DNS name by which your RDGW server is available (remember that this name must be indicated in the certificate). If you use a non-standard port for RDGW, you must specify it after the server name separated by a colon, for example: gw.site.io:4443;

• To prevent the client from asking for a password twice when connecting, enable the Use my RD Gateway credentials for the remote computer option;
• Click the Connect button and enter the password to connect to the RDGW server in the RD Gateway Server Credentials window;

• The client must establish a connection with an RDS/RDP host on your local network;
• Launch the RD Gateway Manager console, navigate to the Monitoring section and check that your client connection is listed in the list.

If you are using the RDCMan utility for RDP connections, the RD Gateway settings can be set on the GatewaySetting tab. Enable the Use a TS Gateway server option and specify connection parameters.

You can monitor successful and unsuccessful user connections through RDGW using the Applications and Services Logs -> Microsoft -> Microsoft-Windows-TerminalServices-Gateway -> Operational event log.

When analyzing RDP connection logs to servers, these logs allow you to understand who, when and where connected.

If the user successfully connects via RDGW, an event with Event ID 205 from the TerminalServices-Gateway source will appear in the log

The user «sitemy», on client computer «xx.xx.xx.xx», successfully connected to the remote server «msk-rdsman.site.io» using UDP proxy. The authentication method used was: «Cookie».

If you want to run RemoteApp through RD Gateway, you need to add the following lines to the remoteapp *.rdp file:

gatewayhostname:s:gw.site.io
gatewayusagemethod:i:1

In this article, we showed you how to configure the Remote Desktop Gateway role on Windows Server to provide secure remote access to your network using RDP over HTTPS.