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

Отслеживать удачные и неудачные подключения пользователей через 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:
$properties = @(
@{n='User';e={$_.Properties[0].Value}},
@{n='Source IP Adress';e={$_.Properties[1].Value}},
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='Target RDP host';e={$_.Properties[3].Value}}
)
Get-WinEvent -FilterHashTable @{LogName='Microsoft-Windows-TerminalServices-Gateway/Operational';ID='302'} | Select-Object $properties
Спасибо за скрипт!
А в чём смысл делить пользователей на rdgwExtUsers в CAP и rdgwExternalAdmins в RAP. Понятно, что они в теории могут быть разными. Но в такой конфигурации получается, что rdgwExtUsers могут лишь авторизоваться, а подключиться смогут лишь rdgwExternalAdmins. Зачем rdgwExtUsers авторизация без подключения и как rdgwExternalAdmins подключатся, если для них не разрешена авторизация?
Здесь вопрос дизайна. В моем случае это вложенные группы. Так проще управлять бизнес логикой через надстройку FIM.
Вы делайете группы доступа как удобно вам.
Добрый день
Вопрос по настройке, но немного в другой конфигурации:
1. домен, центр сертификации, 4 терминальных сервера 2019
2. когда прописываешь на RDP самозаверенные сертификаты и делаешь его экспорт на ПК клиентов — все работает
3. но я же не хочу ставить 4 сертификата — вдруг их количество пополниться до 20… хочу чтобы был один на 4 сервера
4. есть примеры сертификатов, на которых так работало (я использовал их ноне знаю как настраивали) — но не пойму как они создавались но желание воплотить это старую схему в работу сильное
Для начала тебе нужно разобраться с тем что ты подразумеваешь под терминальным сервером. Если для тебя это одиночный сервер, то сколько серверов, столько будет и сертификатов. Если же речь и терминальной ферме, то там всё сложнее. Есть WebAccess c GateWay, а есть Session Host. На Session Host не надо выпускать, вернее надо но только RDP сертификат через GPO на автовыпуск. А WA c GW много не бывает, либо 1 одиночный, либо 2 в конфигурации HA. Делаешь один сертификат с SAN.
Наверное не все так однозначно…
Мозг немного затуманен — целый день провозился и пока не до конца понял что сделал
Но по факту сертификатов
— сертификат раздается политиками на серверы RDP. (формат cer)
— выбор сертификата пришлось делать вручную через диспетчер шлюза и (ручками установленную) tsconfig.
— надо дополнительно понять как сделать сертификат в формате pfx для установки через диспетчер серверов.
— клиентский сертификат создан на имя домена и установлен на недоменном пк.
— в настройках рдп клиента можно указывать как имя так и ip сервера rdp.
— в настройках рдп клиента в качестве шлюза можно указывать имя любого сервера rdp домена
И в сухом остатке клиент подключается без шлюза успешно, с шлюзом тоже
С остальным потом разберусь
Согласен, смотрите в сторону SAN сертфиката c Wildcard (*.contoso.com)
Я правильно понимаю, что на RD Gateway должны быть 2 сетевых интерфейса: один разрешает подключение из интернета, через второй можно попасть во внутреннюю сеть?
Нет, не обязательно делать два интерфейса на RDGW.
В этом примере все построено на сервере с одним интерфейсом. Но здесь нужно правильно настроить правила проброса портов на сетевом оборудовании, ну и вообще корреткно настроить файервол, чтобы ограничить доступ с хостам внутри сети.
День добрый всем, я поменял порт в реестре который по умолчании идёт 3389 на не стандартный. И теперь не могу запустится 😖 с шлюза
Загрузил файл rdp и через блокнот посмотрел сам файл, и не изменён сам порт на который менял
Там по дефолту так и прописан: 3389
Пожалуйста 🙏 помогите решить эту задачу.
Как решить эту проблему ?!
Поменяли порт где? на rdsh хосте, к которому можно подключиться с шлюза rdgw?
Не проще вернуть порт на стандартный? сервер у вас ведь во внутренней сети
в реестре где по дефолту 3389
а в шлюзе другие порты изменил касательно 443 и 3391 кажется не помню )) и отдельно я указал в шлюзе что порт такой та использую не 3389
Все коннектетит и внутри и с наружи, но не открывает приложение. И я загрузил отдельно публикованные приложение, и через блокнот посмотреть без изменение или нет! Оказывается так и стоит без изменение : «3389» на который я менял на не стандартный )
Опубликованные remoteapp приложения и не узнают никак, что вы изменили дефольный порт 3389. Вам нужно руками поправить натсройки в таком файле и раздать его клиентам.
Вот список доступных опция для *.rdp файла:
_https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/rdp-files
Получается у вас нужно провить опции
gatewayhostname:s:value
и
full address:s:SERVERADDRESS:PORTNUMBER
а без раздачи не как не изменить ? то есть изменить внутри где не будь и все ! Просто не хотелось менять, раздавать )) Это понятно всем )
Заранее благодарю !
И вот как мне изменить чтоб работал не на стандартном порту «Подключение»
Заранее спасибо !
Добрый день.
Столкнулся с такой проблемой. Сервер 2019. Настроил Шлюз. Вроде все стандартно, но клиенты на версии Windows 7 подключиться не могут. Все нужные сертификаты на пк импортированы.
Версия RDP обычно 7.1 или 8.1
Может кто сталкивался с таким?
На Win 7 стоят все доступные обновления?
Я бы проверил, что ваши клиенты WIn7 поддерживают TLS 1.1 и TLS 1.2
1) https://support.microsoft.com/en-us/topic/update-to-add-rds-support-for-tls-1-1-and-tls-1-2-in-windows-7-or-windows-server-2008-r2-8aff6954-a80d-411c-c75c-6aeaaab4f570
2) https://winitpro.ru/index.php/2022/04/19/vklyuchit-protokol-tls-1-2-windows/
Доброго дня!
Вы пишете «В поле Subject Name (CN) или Subject Alternative Name сертификата должно обязательно содержаться DNS имя сервера RDGW, которое будет использоваться для подключения внешними клиентами (доступное из интернета)»
Прошу прощения за нубский вопрос, но можно ли вместо DNS-имени использовать статический адрес (белый), присвоенный провайдером, при создании самоподписанного сертификата?
Спасибо
Что ты пропишешь в CN не имеет значение, при наличие SAN он не обрабатывается, можешь написать туда всё что угодно. А вот в SAN пропиши имя по которому будут идти обращения. Никто не запрещает добавить туда и IP, тогда сертификат будет валидным и при обращении по IP.
Спасибо.
«А вот в SAN пропиши имя по которому будут идти обращения» (С)
Вас не затруднит указать, где конкретно надо прописать в SAN мой iP? В статье не нашел упоминания об этом.
SAN — это Subject Alternative Name, это поле сертификата. При выпуске прописываешь туда любые значения, по которым будет работать сертификат.
Ещё раз спасибо и благодарю за терпение.
Я правильно понимаю, что в теле статьи нет скриншота с окном, куда прописывается SAN?
В общем-то да. Здесь упрощённый вариант. Указан только выпуск самоподписанного сертификата, а не с CA или купленного, а шаги выпуска не раскрываются. Это отдельная тема.
Спасибо. Буду рыть дальше, т.к. нарисовалась необходимость развертывания шлюза. До этого пользовались VELIAM’ом, всё было шикарно, но недавно его работу нарушил гадёныш spamhaus, а разработчики не чешутся в плане починки. Пока перешли на TAILSCALE, но у него в бесплатной версии ограничение на количество подключенных клиентов.
Remote Desktop Gateway не поддерживает kerberos auth для версии Remote Desktop Client >= 8.0
Смотри EvenID 312 от Microsoft-Windows-TerminalServices-Gateway/Operational
Для решения проблемы.
1) На сервере RDGW нужно включить ignore missing channel bindings:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\TerminalServerGateway\Config\Core
Type: REG_DWORD
Name: EnforceChannelBinding
Value: 0 (Decimal)
2) На клиенте изменить локальную политику LAN Manager Authentication «Send LM & NTLM — use NTLMv2 session security if negotiated»
Здравствуйте! Спасибо за статью. Шлюз — отличное решение. На серверах где не поднят домен наружу стоит просто нестандартный порт рдп, а на самих серверах программы типа fail2ban для защиты от брутфорс-атак.
Хочу уточнить по поводу защищенности шлюза на сервере где он поднят, в среде домена. Подключения внешние идут на порт 443, так-же нужен сертификат. Нужна ли дополнительная защита или шлюзы не подвергаются атакам перебора пароля?
В логах чисто.
Риск атак и перебора паролей все еще есть . В данном случае RDGW позволяет закрыть от интернета RDP порты и оставить только защищенный 443.
Если есть бизнес необходимость, можно дополнительно накрутить 2FA для RDGW (есть готовые платные сервисы с интеграцией) + application proxy с анализом URL.
У RDGW есть таймауты сессий. В свойствах политики CAP и перейдите на вкладку Timeouts.
Там есть два параметра:
Enable idle timeout
Enable session timeout
Здравствуйте, помогите пожалуйста!
Все настроил по инструкции и все работало. Компьютеры подключаются из дома к серверу в офисе без домена.
Потом на 2 клиентах появилась ошибка «Удаленный ресурс не доступен». Подключения к шлюзу проходит (видно на сервере), а дальше конечный компьютер не видит.
При этом, если на этом же компьютере подключиться к другому интернету (не домашний вайфай, а например с мобилы вайфай) то подключение проходит. В чем может быть дело?
Выполняйте диагностику с клиентов, пинг, резолв dns, доступность порта.
Оказывается RDGW может принимать подключения с помощью NTLMv1, даже если вы отключите его в домене. Чтобы отклонять таких клиентов, нужно создать в реестре параметр:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\TerminalServerGateway\Config\Core
Type: REG_DWORD
Name: EnforceChannelBinding
Value: 0 (Decimal)
И на клиенте нужно включить политику Network security: lan manager authentication level: Send LM & NTLM — use NTLMv2 session security if negotiated.
Upd: значение 1 чтобы заблокировать ntlmv1 подключения