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 Gateway
- Настройка SSL сертификата для Remote Desktop Gateway
- Настройка RDP клиента для подключения шлюзу RD Gateway
- Настройка шлюза RD Gateway в рабочей группе
Установка роли 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:
- Разверните Policies -> Connection Authorization Policies и выберите пункт меню Create New Policy -> Wizard;
- Укажите имя политики (rdgwExtUsers);
- Выберите тип аутентификации (по паролю и/или по смарт карте), укажите группу пользователей, которым разрешено аутентифицироваться на RDGW;
- В окне Enable or Disable Device Redirection можно указать какие устройства разрешено прокидывать в RDP сессию (буфер обмена, принтера, локальные диски и т.д.);
- Далее можно настроить таймауты для RDP сеансов;
- Подтвердите создание политики.
Также вы можете создать политику клиентского доступа RDGW с помощью PowerShell:
Import-Module -Name RemoteDesktopServices
New-Item -Path 'RDS:\GatewayServer\CAP' -Name 'rdgwAllowAutht-CAP' -UserGroups rdgwExtUsers -AuthMethod '1'
Затем создайте политику RD RAP:
- В консоли RD Gateway Manager выберите Policies -> Resource Authorization Policies и выберите пункт меню Create New Policy -> Wizard;
- Укажите имя политики: rdgwExternalAdmins;
- Укажите имя группу, которой разрешено подключаться к внутренним RDS ресурсам;
- На вкладке Network Resources нужно указать к каким RDS серверам разрешено подключаться вашим внешним пользователям (msk-rds-farm);
- Далее укажите разрешенные для подключения порты. По-умолчанию рекомендуется открыть только стандартный RDP порт 3389. Но вы можете открыть и дополнительные порты;
- Политика готова.
Правило RAP также можно создать с помощью PowerShell:
New-Item -Path RDS:\GatewayServer\RAP -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, которое будет использоваться для подключения внешними клиентами (доступное из интернета).
- Откройте свойства сервера RDGW в консоли RD Gateway и перейдите на вкладку SSL Certificate;
- В этом примере мы используем самоподписанный сертификат. Выберите пункт Create a self-signed certificate -> Create and Import Certificate;
- Укажите имя сертификата (это 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 хостам через шлюз удаленных рабочих столов.
- Запустите клиент
mstsc.exe
; - На вкладке General укажите имя RDSH хоста, RDS фермы, или компьютера к которому вы хотите подключиться по RDP (можно также указать имя пользователя и использовать сохраненные учетные данные для RDP подключения);
- Затем перейдите на вкладку Advanced и щелкните на кнопку Settings в разделе Connect from anywhere (Configure settings to connect through Remote Desktop Gateway when I am working remotely);
- Выберите опцию Use these RD Gateway server settings, укажите внешнее DNS имя по которому доступен ваш RDGW сервер (напоминаю, что это имя должно быть указано в сертификате).Если вы используете нестандартный порт для RDGW, его нужно указать после имени сервера через двоеточие, например: gw.winitpro.ru:4443;
- Чтобы не при подключении клиент не запрашивал пароль два раза, включите опцию Use my RD Gateway credentials for the remote computer;
- Нажмите кнопку Connect и введите пароль для подключения к RDGW серверу в окне RD Gateway Server Credentials;
- Клиент должен установить подключение с RDS/RDP хостом в вашей локальной сети;
- Запустите консоль 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 "winitpro\kbuldogov", 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.
Настройка шлюза RD Gateway в рабочей группе
При размещении отдельностоящего RDSH сервера в интернете, открывать наружу стандартный RDP порт 3389 небезопасно. В журналах безопасности хоста будут постоянно фиксироваться события перебора паролей по RDP. Вы можете безопасно опубликовать RDSH в интернете через RD Gateway и использовать для RDP доступа защищённое SSL/TLS подключение по порту TCP:443.
Вопреки распространённому убеждения, RD Gateway можно развернуть без домена Active Directory (в рабочей группе).
Предполагаем, что вы развернули отдельный RDS хост с Windows Server в рабочей группе.
Установите роль RDGateway с помощью команды:
Install-WindowsFeature RDS-Gateway -IncludeAllSubFeature –IncludeManagementTools
Откройте консоль RD Gateway Manager (
tsgateway.msc
) и создайте политику Connection Authorization Policy (CAP).
- В настройках политики разрешите подключение по паролям для пользователей из локальной группы
BUILTIN\Remote Desktop Users
; - Выберите какие устройства разрешено перенаправлять в RDP сессию клиентам (по умолчанию разрешено перенаправлять все, включая принтеры, локальные диски и буфер обмена в RDP);
- На следующем этапе можете настроить таймауты неактивности для RD сессий.
После этого создайте новую Resource Authorization Policy (RAP).
- Разрешите подключения для группы
BUILTIN\Remote Desktop Users
; - Выберите опцию Allow users to connect to any network resource (computer);
- Разрешите подключение только на RDP порт 3389.
Следующий этап – установить SSL/TLS сертификат для защиты подключений к шлюзу RDS. Можно использовать бесплатный SSL сертификат Let’s Encrypt или самоподписанный SSL сертификат Windows (для простоты мы будем использовать этот вариант).
По умолчанию для RDGW генерируется самоподписанный сертификат со сроком действия полгода. С помощью PowerShell можно создать сертификат с большим сроком. В CN имени сертификата или в Subject Alternative Name (DNS) должно содержаться внешнее DNS имя и/или статический (белый) IP адрес сервера RD Gateway, к которому будут подключаться клиенты. Укажите через запятую все необходимые имена при создании сертификата:
$todaydate = Get-Date
$addyear = $todaydate.AddYears(5)
New-SelfSignedCertificate -dnsname rdgw.winitpro.ru,123.123.123.12,gw.mydomain.ru -notafter $addyear -CertStoreLocation cert:\LocalMachine\My
Откройте свойства сервера RDGW, перейдите на вкладку SSL Certificates -> Select an existing certificate from the RD Gateway Certificates Local/Personal Store -> Import Certificate. Выберите созданный вами сертификат.
Теперь можно настроить подключение на клиенте. В первую очередь надо экспортировать с сервера RDGW сертификат.
- Откройте консоль сертификатов компьютера (
certlm.msc
); - Разверните хранилище Personal -> Certificates;
- Выберите сертификат -> All tasks -> Export;
- Экспортируйте сертификат в файл *.CER (без закрытого ключа);
Этот сертификат нужно установить на клиенте. Если клиент не доверяет сертификату RD Gateway, он не сможет подключиться к шлюзу.
Вы можете установить сертификат вручную или через GPO. Установить сертификат в Trusted Root Certification Authorities.
Теперь откройте клиент
mstsc
и настройте подключение через Remote Desktop Gateway. Укажите имя или IP адрес хоста RDGW в разделе Advanced -> Settings -> Use these RD Gateway settings.
В качестве имени RDP хоста укажите
localhost
и имя пользователя для подключения в формате
rdssrv01\user1
, где rdssrv01- локальное имя компьютера (hostname) Windows Server с ролью RDS.
Если SAN имя в сертификат не соответствует имени RD gateway хоста в подключении, появится ошибка:
Your computer cannot connect to the remote computer because the remote desktop gateway server address requested, and the certificate subject name do not match.
Опубликовано:
Используемые термины: 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.
Пошагово, мы выполним следующие действия:
Установка серверной роли
Настройка шлюза
Создание групп в AD
Создание политик RDG
Привязка сертификата
Настройка клиента для подключения
Remoteapp через Gateway
DNS round robin
Часто встречаемые ошибки
Установка роли
Открываем Диспетчер серверов:
Переходим в Управление — Добавить роли и компоненты:
При появлении окна приветствия нажимаем Далее (при желании, можно поставить галочку Пропускать эту страницу по умолчанию):
На страницы выбора типа установки оставляем выбор на Установка ролей или компонентов:
Выбираем целевой сервер — если установка выполняется на сервере локально, то мы должны увидеть один сервер для выбора:
Ставим галочку Службы удаленных рабочих столов:
Дополнительные компоненты нам не нужны:
… просто нажимаем Далее.
На странице служб удаленных рабочих столов идем дальше:
Выбираем конкретные роли — нам нужен Шлюз удаленных рабочих столов. После установки галочки появится предупреждение о необходимости поставить дополнительные пакеты — кликаем по Добавить компоненты:
Откроется окно для настроек политик:
… нажимаем Далее.
Откроется окно роли 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. Также нужно убедиться, что привязанный сертификат, на самом деле, не просрочен или отозван. В крайнем случае, можно заново создать сертификат.
There is no question, there have been a lot of organizations that have had to shift their focus to remote working over the past few weeks/months. If you are a Windows Server shop and also maintain Windows clients for your end users, one of the easiest ways to extend remote work from home is to setup a Remote desktop gateway server 2016 or 2019 to allow remote workers to access a desktop environment to run their normal business applications. If in a panic or a hurry you simply “poked a hole” in your firewall for RDP services directly to a server, now is the time to revisit that solution and make things more secure. Folding RDP services back in to the internal network and only exposing a remote desktop gateway server 2016 or 2019 to the perimeter is by far the better solution. In this post, we will take a look at remote desktop gateway server 2016 or 2019 configuration and see how you can easily stand up a server in the perimeter with the gateway services running that will proxy RDP traffic inside to your internal RDP resources.
Before we get into the technical details of the solution, let’s look at this question a bit further. Why do you want to go through the trouble to stand up an additional layer in front of your RDP servers? In short, exposing an RDP server directly to the Internet is dangerous. There have been countless RDP flaws that have been revealed over the past few years and these will no doubt continue, especially with the current remote work situation.
Microsoft has a built-in solution in the Remote Desktop Gateway services role that allows proxying these incoming connections over a secure SSL 443 tunnel connection to the Gateway server over which the RDP connection is established to the internal RDP servers that house the actual resources and applications you want your end users to be able to use.
This is way more secure and keeps the highly problematic RDP protocol concealed on the inside underneath a separate layer of security that can be applied with the Remote Desktop Gateway server 2016 or 2019. Let’s take a look at installing a remote desktop gateway server 2016 or 2019 in front of your Remote Desktop Session Host (RDSH) servers internally.
Remote Desktop Gateway Server 2016 or 2019 Configuration
Let’s look at the steps to configure our Remote Desktop Gateway Server (RDGW). The steps for Remote Desktop Gateway Server 2016 or 2019 configuration involve the following:
- Install the Remote Desktop Services role on your 2016 or 2019 server you are going to use for the Remote Desktop Gateway server.
- Configure the Network Policy Server
- Configure an SSL certificate for the Remote Desktop Gateway server
- Configure your client connection to use the Remote Desktop Gateway Server 2016 or 2019 for connecting to internal RDP resources.
Installing the Remote Desktop Services Role in 2016 or 2019
The first thing we need to do is install the role for Remote Desktop Services. You can easily do this in the Server Manager Roles and Features wizard.
The Select role services wizard will ask which specific Remote Desktop Services will be installed.
The Network Policy and Access Services is installed in the installation of Remote Desktop Gateway services.
The Web Server Role (IIS) is installed along with the Remote Desktop Gateway role service.
The Web Server role services that will be installed in the process.
Confirm the installation of the selected services supporting the Remote Desktop Gateway role.
The Remote Desktop Gateway role service is installed along with the NPS role and Web Server IIS role.
After installation, launch the RD Gateway Manager console. You will need to create new policies for:
- Connection Authorization
- Resource Authorization
Create a Connection Authorization Policy
Create a New Policy under the Connection Authorization Policies.
You have the choice to use a wizard or custom creation for the authorization policy.
Below is the custom creation of the connection authorization policy. First, name the policy and make sure it is enabled (it is by default).
Under the requirements tab, add the group that will be allowed to connect. This is a required configuration. You can also add a computer group that is optional which defines the computer group allowed to connect.
There are Device Redirection and Timeouts options that can be configured.
The Connection Authorization Policy is created successfully.
Create a Resource Authorization Policy
Create the Resource Authorization Policy. Click the Create New Policy.
Create the New Policy using the Wizard or the Custom option.
Name the Resource Authorization Policy (RAP) and make sure it is enabled (it is by default).
Add the user groups whose members can connect to the remote computers on the network through the RDGW.
Configure which network resources the users are allowed to connect to. You can select a group that contains the computers that authenticated users are allowed to connect to. Also, you can select to Allow users to connect to any network resource.
Allowed ports allows configuring a different port besides 3389 if desired.
The resource authorization policy is created successfully.
Install an SSL Certificate on the Remote Desktop Gateway Server
Aside from creating the connection authorization policy and the resource authorization policy, the Remote Desktop Gateway Server needs an SSL certificate installed. Click the View or modify certificate properties.
For production systems, you need to install a trusted SSL certificate from a certificate authority. However, the great thing about the RDGW properties under the SSL Certificate tab, there is a means to Create and Import Certifiate which allows creating a self-signed certificate.
The Create Self-Signed Certificate dialog box will automatically create the certificate and export the self-signed certificate out so you can import on client machines that will be connecting to the Remote Desktop Gateway 2016 or 2019 server.
The certificate is successfully installed and exorted.
Now, under the tab, you will see the following certificate is installed on RDGW.
All of the statuses now show green and ready.
Connect to RDSH with Remote Desktop Gateway Server
On a client the mstsc client for Remote Desktop Connection under Advanced > Settings is where you set the Remote Desktop Gateway server.
Enter the Remote Desktop Gateway address under the Use these RD Gateway server settings. You can also set or unset the Bypass RD Gateway server for local addresses as well as the Use my RD Gateway credentials for the remote computer.
If a client does not have the certificate trusted on the client machine, they will see the following message. If you are using a self-signed certificate, the certificate will need to be imported on the client machine.
Once you hit Connect you will be successfully connected to your remote desktop through the proxy of the Remote Desktop Gateway Server 2016 or 2019.
Final Thoughts
Remote Desktop Gateway Server 2016 or 2019 Configuration is a straightforward process involving a few steps. This involves installing the role services needed, setting up the Network Policy Server authorization rules, installing the SSL certificate, and then configuring the end user client including installing the certificate.
For those looking for a secure solution to access remote desktops, the Remote Desktop Gateway server is the secure way to do this. For those that may have direct RDP access enabled, pulling back and installing a Remote Desktop Gateway server 2016 or 2019 in front of your RDSH servers will help to secure your remote RDP access.
Remote Desktop Gateway is a Remote Desktop Services role on Windows Server that is used to provide secure access to remote desktops and published RemoteApps from the Internet via an HTTPS gateway. A server with the RD Gateway role acts as an intermediary between external RDP clients and internal RD services. When using RDGW, users don’t need to configure a VPN to connect to RDS in a corporate network. The standard Remote Desktop Connection client (mstsc.exe) is used to connect. In this article, let’s look at how to deploy Remote Desktop Gateway on Windows Server 2019 (the guide is also applicable for Windows Server 2022/2016 and 2012 R2).
Contents:
- Deploy RDS-Gateway Role on Windows Server
- Configure Remote Desktop Gateway Authorization Policies
- Install SSL Certificate for Remote Desktop Gateway
- Configuring RDP Client to Use an RDS Gateway
- Standalone RD Gateway in a Workgroup (without AD Domain)
Deploy RDS-Gateway Role on Windows Server
The Remote Desktop Gateway service is an optional RDS farm component, so you have to install it separately. In most cases, it is recommended to use a dedicated server to deploy RDGW or combine it with RD Web Access.
It is supposed that Active Directory and RDS farm are already deployed in your network.
You can install the Remote Desktop Gateway role through the Server Manager (Add roles & Features -> Server Role -> Remote Desktop Services) or with PowerShell.
When you install the RDGW service, the IIS web server and NPS (Network Policy Server) role are also installed.
Make sure that 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 (dsa.msc) console or with PowerShell:
- rdgwExtUsers – a group of users allowed to authenticate on the RDGW;
- rdgwExternalAdmins – a group to access internal RDS hosts via the RDGW;
- mun-rdsfarm — must include all RDS hosts and your RD Connection Broker that you want to allow connections to through the Remote Desktop Gateway
Configure Remote Desktop Gateway Authorization Policies
The RD Gateway Manager (tsgateway.msc
) console is used to manage RDGW authorization policies and access rules, Configure two types of policies here:
- Connection Authorization Policies (RD CAP) – sets who is allowed to authenticate on the RDS Gateway;
- Resource Authorization Policies (RD RAP)– specify users and resources (computers) on the internal network that are allowed to connect via RDGW.
Create the RD CAP first:
- Expand Policies -> Connection Authorization Policies and select Create New Policy -> Wizard;
- Enter a policy name (rdgwExtUsers);
- Select an authentication type (a password and/or a smart card) and specify a group of users allowed to authenticate on the RDGW;
- In the Enable or Disable Device Redirection window, you may specify what devices are allowed to be redirected to an RDP session (a clipboard, printers, local drives, etc.);
- Then you can configure timeouts for RDP sessions;
- Confirm the creation of the policy.
You can also create an RDGW connection policy using PowerShell:
Import-Module -Name RemoteDesktopServices
New-Item -Path 'RDS:\GatewayServer\CAP' -Name 'rdgwAllowAutht-CAP' -UserGroups rdgwExtUsers -AuthMethod '1'
After that create the RD RAP policy:
- In the RD Gateway Manager console, click Policies -> Resource Authorization Policies and select Create New Policy -> Wizard;
- Enter a policy name: rdgwExternalAdmins;
- Specify the name of the user group allowed to connect to internal RDS resources;
- On the Network Resources tab, specify what RDS servers your external users are allowed to connect to (mun-rdsfarm);
- Then specify the port numbers you want to allow connection to. By default, it is recommended to open only the default RDP port TCP/3389. But you can open additional ports as well;
- The policy is ready.
You can add this RAP rule using PowerShell:
New-Item -Path RDS:\GatewayServer\RAP -Name allowextAdminMunRDS -UserGroups [email protected] -ComputerGroupType 1 -ComputerGroup [email protected]
Install SSL Certificate for Remote Desktop Gateway
To secure the connection to the RDS gateway, you must install an SSL certificate on it. It is better to use a commercial certificate issued by an external certification authority (CA). You may also use a free Let’s Encrypt SSL certificate (Configure a Let’s Encrypt certificate on IIS for Remote Desktop Gateway) or a self-signed Windows SSL certificate, but note that external clients must trust it. If a client doesn’t trust a certificate on an RDGW server, it won’t be able to connect to the gateway (you can import self-signed SSL certificates to clients manually or using GPO).
A FQDN (DNS) name of your RDGW server must be specified in the Subject Name (CN) or Subject Alternative Name fields of the certificate. It will be used for connection by external clients (available from the Web).
- Open the RDGW server properties 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;
- Enter the certificate name (this name will be used by your clients to connect to RDGW) and select a directory you want to save the certificate to (distribute this certificate to your RD clients).
The following ports are used to connect to RDGateway on Windows Server 2019:
- HTTPPort (default) — 443 TCP
- UDPPort (default) — 3391 UDP (using UDP transport protocol is optional, however, it allows to significantly improve the tunnel performance and image quality in an RDP session).
Remember to open (forward) these ports from your public IP to your RDGW host on the network hardware.
Open the RDGW Manager and make sure that there are no errors and that all items have green icons.
Configuring RDP Client to Use an RDS Gateway
Then you may configure a 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 your RDGW, put it to the Trusted Root Certification Authorities on your client. See an article on how to update root certificates on Windows.
- Run the
mstsc.exe
client; - In the General tab, enter the name of a standalone RDS Host, RDS farm, or a computer you want to connect to via RDP (you may also specify a user name and use saved credentials for the RDP connection);
- Then go to the Advanced tab and click Settings under Connect from anywhere (Configure settings to connect through Remote Desktop Gateway when I am working remotely) section;
- Select Use these RD Gateway server settings and specify an external DNS name of your RDGW server (note that this name must be specified in the certificate). If you are using a different port for RDGW, enter it after the server name separated by a colon, for example,
gw.woshub.com:4443
. - To prevent entering a password twice when connecting, check the option Use my RD Gateway credentials for the remote computer;
- Click Connect and enter user credentials to connect to the RD Gateway server;
- The client will establish a connection with an RDS/RDP host in your local network;
- Open the RD Gateway Manager, go to the Monitoring section, and make sure that the connection of your client is displayed in the list.
If you are using RDCMan for RDP connections, you can set RD Gateway parameters on the Gateway Setting tab. Check Use a TS Gateway server and set the connection options.
You can monitor successful or failed connections to RDGW in the Event Viewer (Applications and Services Logs -> Microsoft -> Microsoft-Windows-TerminalServices-Gateway -> Operational).
If the user has successfully connected to the RDGW, Event ID 205 will appear from the TerminalServices-Gateway source.
The user "woshub\maxadmin", on client computer "xx.xx.xx.xx", successfully connected to the remote server "mun-rdsgw.woshub.com" using UDP proxy. The authentication method used was: "Cookie".
If you want to run RemoteApps through the RD Gateway, add the following lines to the RemoteApp *.rdp
file:
gatewayhostname:s:gw.woshub.com gatewayusagemethod:i:1
In this article, we showed how to configure the Remote Desktop Gateway role on Windows Server to implement secure remote access to your network using RDP over HTTPS.
Standalone RD Gateway in a Workgroup (without AD Domain)
If you are publishing a standalone RDSH server on the Internet, it is not safe to open the default RDP port 3389 to the outside world. In this case, you will constantly see RDP password brute-force attack attempts in the host security logs. You can use the RD Gateway to securely deploy the RDSH over the Internet and use an encrypted SSL/TLS connection on port TCP:443 to connect to the RDP service.
Contrary to popular belief, the RD Gateway can be deployed without an Active Directory domain (in a Workgroup environment). Suppose you have a standalone RDS host running Windows Server in a workgroup.
Install the RDGateway role with the command:
Install-WindowsFeature RDS-Gateway -IncludeAllSubFeature –IncludeManagementTools
Open the RD Gateway Manager snap-in (tsgateway.msc
) and create an Authorization Policy (CAP).
- In the policy settings, allow users from the BUILTIN\Remote Desktop Users local group to connect using password authentication;
- Select which devices can be redirected to the RDP session by clients (by default, all local devices can be redirected to RDP, including printers, local drives, and the clipboard);
- In the next step, you can configure RD session inactivity timeouts.
Now, create a new Resource Authorization Policy (RAP).
- Allow connections to members of the BUILTIN\Remote Desktop Users group;
- Select the option Allow users to connect to any network resource (computer);
- Only permit connections to RDP port 3389.
The next step is to install an SSL/TLS certificate on the RDS gateway. You can use a free Let’s Encrypt SSL Certificate, a commercial certificate, or a Windows self-signed cert (we’ll use this option).
By default, RDGW generates a self-signed certificate that is valid for six months. You can use PowerShell to create a certificate with a long-term validity period. The external DNS name and/or public IP address of the RD Gateway host to which clients will connect must be included in the certificate subject CN or Subject Alternative Name (DNS). When you create a certificate, specify all the names and IPs you need, separated by commas:
$todaydate = Get-Date
$addyear = $todaydate.AddYears(5)
New-SelfSignedCertificate -dnsname gw1.woshub.com,10.11.12.13,rdgw.woshub.com -notafter $addyear -CertStoreLocation cert:\LocalMachine\My
Open the RDGW Properties, go to the SSL Certificate tab -> Select an existing certificate from the RD Gateway Certificates Local/Personal Store -> Import Certificate. Select the certificate you created.
You can now configure the RDP connection on the client. First, you need to export the certificate from the RDGW host:
- Open the Computer Certificates console (
certlm.msc
); - Expand the store Personal -> Certificates;
- Select your RDGW cert -> All tasks -> Export;
- Export the certificate to a *.CER file (without the private key);
This certificate must be installed on the clients. If the client does not trust the certificate of the RD Gateway, it will not be able to establish a connection.
You can install the certificate either manually or by using the GPO. Place the cert in the Trusted Root Certification Authorities store.
Now open the mstsc.exe
client and configure the connection through the Remote Desktop Gateway. Specify the FQDN or IP address of the RDGW host in Advanced -> Settings -> Use these RD Gateway settings.
For the RDP hostname, specify localhost
and the user name for the connection in the format rds01\user1
, where rds01
is the local computer name (hostname) of Windows Server rung the RDS role.
If any of the SAN names in the certificate don’t match the RD Gateway name, an error will be displayed.
Your computer cannot connect to the remote computer because the remote desktop gateway server address requested, and the certificate subject name do not match.
В данной инструкции у нас уже установлена операционная система Windows Server 2019 на виртуальной машине.
Минимальные требования:
- 64-разрядный процессор с тактовой частотой 1,4 ГГц;
- ОЗУ 512 МБ (2 ГБ для варианта установки “Сервер с рабочим столом”);
- диск 32 ГБ;
- доступ к интернету.
Бесплатный сервер 1С для подписчиков нашего telegram-канала !
Для того чтобы подключить сертификат с помощью Let’s Encrypt требуется прямые пробросы портов TCP 443, 80 до машины, а также доменное имя, на которое будет вешаться сертификат.
Активация Windows Server 2019 проходит тоже на этом этапе.
Установка ролей на Windows Server 2019
После подготовки Windows Server 2019, мы приступаем к установке ролей для настройки терминального сервера и шлюза удаленных рабочих столов.
Заходим в Диспетчер серверов – Управление – Добавить роли и компоненты.
Открывается “Мастер добавления ролей и компонентов”:
Рисунок 1 – Мастер добавления ролей и компонентов
Добавление ролей на сервере:
- Тип установки – Установка ролей или компонентов.
- Выбор сервера – Выбираем наш текущий сервер.
- Роли сервера – Службы удаленных рабочих столов.
- Службы ролей – Лицензирование удаленных рабочих столов, шлюз удаленных.
Подтверждаем установку компонентов и проводим установку. После установки всех нужных нам ролей – перезагружаем сервер.
У нас вы можете взять готовый терминальный сервер 1С в аренду.
Настройка сервера лицензирования
Заходим в Диспетчер серверов – Средства – Remote Desktop Services – Диспетчер лицензирования удаленных рабочих столов.
В диспетчере нажимаем ПКМ на наш сервер и выбираем “Активировать сервер”.
Попадаем в “Мастер активации сервера”, вводим свои данные и нажимаем “Далее”.
Рисунок 2 – Мастер активации сервера
В следующем пункте вводим “Сведения об организации” и нажимаем “Далее”.
Завершение работы мастера активации сервера выполняется с поставленной галочкой “Запустить мастер установки лицензий” чтобы попасть в оснастку установки лицензий.
Рисунок 3 – Завершение работы мастера активации сервера
В мастере установки лицензий мы видим параметры сервера лицензирования и нажимаем “Далее”.
В следующем окне мы выбираем лицензию в зависимости от приобретенной вами лицензии.
Имеется несколько типов лицензии:
- Пакет лицензий (в розницу).
- Соглашение “Open License”.
- Соглашение “Select License”.
- Соглашение “Enterprise Agreement”.
- Соглашение “Campus Agreement”.
- Соглашение “School Agreement”.
- Лицензионное соглашение постановщика услуг.
- Другое соглашение.
- Лицензия Select Plus.
В нашем случае мы выбираем “Соглашение “Enterprise Agreement”” и нажимаем “Далее”.
- Версию продукта ставим “Windows Server 2019”.
- Тип лицензии “Клиентская лицензия служб удаленных рабочих столов “на устройство”.
- Количество в зависимости от приобретенной вами. В нашем случае мы активируем на 10 устройств.
Завершаем работу мастера установки лицензий.
Для завершение установки лицензий осталось выполнить пункт по добавление групповых политик, для этого нажимаем ПКМ по меню “Пуск” и выбираем “Выполнить”.
В окне “Выполнить” вводим gpedit.msc и нажимаем “ОК”.
Попадаем в “Редактор локальной групповой политики”
В данной настройке требуется править две записи. Для того чтобы указать сервер лицензирования мы переходим в пункт:
Конфигурация компьютера – Административные шаблоны – Компоненты Windows – Служба удаленных рабочих столов – Узел сеансов удаленных рабочих столов – Лицензирование – Использовать указанные серверы лицензирования удаленных рабочих столов.
Включаем данную политику и вводим требуемый сервер лицензирования. В нашем случае мы будем ссылаться на свой локальный сервер “localhost” и применяем настройку.
Рисунок 4 – Использование серверов лицензирования
Для второго пункта мы переходи по следующему пути:
Конфигурация компьютера – Административные шаблоны – Компоненты Windows – Служба удаленных рабочих столов – Узел сеансов удаленных рабочих столов – Лицензирование – Задать режим лицензирования удаленных рабочих столов.
Включаем политику и указываем режим лицензирования, в нашем случае мы активируем “на устройство” и применяем настройку.
Рисунок 5 – Задаем режим лицензирования
Настройка по установки лицензий прошла успешно, далее мы настраиваем шлюз удаленных рабочих столов.
Настройка шлюза удаленных рабочих столов
Шлюз удаленных рабочих столов является сервисом посредником между клиентами из внешней сети и сеансов внутренней сети, обеспечивает безопасный обмен данными между ними.
Заходим в Диспетчер серверов – Средства – Remote Desktop Services – Диспетчер шлюза удаленных рабочих столов.
Нажимаем ПКМ по папке “Политики” и выбираем “Создание новых политик авторизации”.
Мы попадаем в “Мастер создания новых политик авторизации”.
Рисунок 6 – Создание политик авторизации для шлюза удаленных рабочих столов
По пунктам выбираем следующее:
- Политики авторизации – Создать политику авторизации подключений к удаленным рабочим столам и авторизации ресурсов удаленных рабочих столов.
- Политика авторизации подключений – пишем наименование политики (в нашем случае Users).
- Требования – выбираем членство в группе для пользователей или компьютеров, которые смогут подключаться к серверу (в нашем случае, мы добавили группу пользователей “Пользователи удаленного рабочего стола” и “Администраторы”).
- Перенаправление устройств – выбираем, что требуется перенаправить (мы выбрали “Включить перенаправление устройств для всех клиентских устройств”).
- Время ожидания сеанса – по умолчанию.
- Сводка по политике авторизации подключений к RD – параметры которые будут созданы в данной политике.
- Политика авторизации ресурсов – пишем наименование политики (в нашем случае TS).
- Группы пользователей – выбираем членство в группе для пользователей или компьютеров, которые смогут подключаться к серверу (в нашем случае, мы добавили группу пользователей “Пользователи удаленного рабочего стола” и “Администраторы”).
- Сетевой ресурс – можем настроить группу терминальных серверов, куда можно подключиться, выберем “Разрешить подключение пользователей к любому ресурсу (компьютеру)”.
- Разрешенные порты – если настроен нестандартный порт, то в этом пункте можно это указать, выбираем “Разрешить подключение только к порту 3389”.
- Сводка по политике авторизации ресурсов RD – параметры которые будут созданы в данной политике.
На данном этапе мы завершили настройку шлюза удаленных рабочих столов, за исключением установки сертификата.
Рисунок 7 – Оснастка диспетчера шлюза удаленных рабочих столов без сертификата
Для того, чтобы установить сертификат на шлюз удаленных рабочих столов, мы воспользуемся утилитой win-acme.
Установка сертификата на шлюз удаленных рабочих столов через Let’s Encrypt
Скачиваем программу по ссылке:
https://github.com/win-acme/win-acme/releases/download/v2.1.14.1/win-acme.v2.1.14.996.x64.trimmed.zip
Копируем в папку C:Scriptswin-acme
Создаем 3 bat-файла:
- Файл “C:Scriptswin-acmeRegister.bat”
Файл “C:Scriptswin-acmeRegister.bat”
@echo off rem powershell.exe :: Ввод данных: set /p commonname_Data="Enter Domain name(exampe : v0162.esit.info) : " powershell -ExecutionPolicy Bypass -NoLogo -NoProfile -Command "Get-WebBinding | Remove-WebBinding" powershell -ExecutionPolicy Bypass -NoLogo -NoProfile -Command "New-WebBinding -Name 'Default Web Site' -Port 443 -Protocol https -SslFlags 0 -IPAddress "*" -HostHeader "*" " powershell -ExecutionPolicy Bypass -NoLogo -NoProfile -Command "New-WebBinding -Name 'Default Web Site' -Port 80 -Protocol http -IPAddress "*" -HostHeader "*" " powershell -ExecutionPolicy Bypass -NoLogo -NoProfile -Command "Set-WebBinding -Name 'Default Web Site' -BindingInformation "*:443:*" -PropertyName HostHeader -Value '%commonname_Data%'" powershell -ExecutionPolicy Bypass -NoLogo -NoProfile -Command "Set-WebBinding -Name 'Default Web Site' -BindingInformation "*:80:*" -PropertyName HostHeader -Value '%commonname_Data%'" @echo on "C:Scriptswin-acmewacs.exe" --installation script --target iissite --siteid 1 --commonname %commonname_Data% --emailaddress admin@admin --accepttos --script "./scripts/PSScript.bat" --scriptparameters "./scripts/ImportRDGateway.ps1 {5}"
- Файл “C:Scriptswin-acmeScriptsPSScript.bat”
Листинг:
powershell.exe -ExecutionPolicy RemoteSigned -File %*
- После этого запускаем “C:Scriptswin-acmeRegister.bat”.
- Вводим домен на котором находится наш шлюз удаленных рабочих столов.
- Если всё получилось, то в оснастке шлюза удаленных рабочих столов должен появится созданный сертификат, а в консоли – готовый результат.
- Элемент маркированного списка
Рисунок 8 – Сертификат успешно установлен
Подключение пользователей
Следующем этапом мы создаем пользователей для подключение к удаленному рабочему столу через шлюз удаленных рабочих столов.
- В окне “Выполнить” вводим команду “control userpasswords2”.
- Нажимаем “Дополнительно”.
- Выбираем папку “Пользователи” переходим в “Дополнительные действия” и нажимаем “Новый пользователь”.
- Вводим требуемые поля.
Рисунок 9 – Добавление нового пользователя
Создаем нового пользователя и добавляем его в группу “Пользователи удаленного рабочего стола”, для этого заходим в Панель управления – Система – Настройка удаленного рабочего стола – Выбрать пользователей – Добавить.
Добавляем созданных пользователей, после чего подключаемся к серверу.
Подключение к серверу терминалов
На машине, с которой будем подключаться к серверу, ищем утилиту “Подключение к удаленному рабочему столу” на Windows 10 она находится по следующему расположению: Пуск – Стандартные – Windows – Подключение к удаленному рабочему столу.
В открытом окне вводим имя нашего сервера или локальный ip-адрес. В нашему случае имя сервера “EFSOL-TS”
Пользователя указываем, которого создали (EFSOL-TSefsol_it).
Далее, чтобы указать адрес шлюза удаленных рабочих столов, переходим во вкладку “Дополнительно” нажимаем “Параметры” вводим в окне Имя сервера наше доменное – “gorbach.esit.info”.
Рисунок 10 – Подключение к шлюзу удаленных рабочих столов
Нажимаем “ОК” и “Подключить”.
При подключении к удаленному рабочему столу – может появится сообщение о сертификате, мы на него соглашаемся.
Установка терминального сервера произведена и шлюз удаленных рабочих столов успешно настроен.
Также мы готовы предложить готовый терминальный сервер в аренду. Конфигурации подобраны для комфортной работы в 1С, офисных приложениях и другом ПО.