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 в рабочей группе
При размещении отдельностоящего 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.
Спасибо за подробное описание!
Делюсь своим скриптом для получения логов подключений пользователей на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
Спасибо за скрипт!
Жаль что в списке не выкидывает адрес откуда подключался пользователь.
прошу прощения, все есть 🙂 просто через реверспрокси когда подключение, скрывает внешний ip 🙁
А в чём смысл делить пользователей на 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 по 443 порту, а дальше от RDGW к нужному серверу уже по 3389?
И из этого вытекает вопрос: клиент сидит за 100500 файрволов. Ему какие порты разрешать, чтоб он смог подключиться к серверу через RDGW?
1)
достукивается до RDGW по 443 порту
Да ( для лучшего качества RDP связи стоит открыть еще UDP 3391)2) клиент не ходит напрямую на целевой RDS по 3389. Все эти функции выполняет RDGW, а фактически клиент не использует никакие другие порты кроме 443 TCP до шлюза (+ опциональный UDP 3391)
У 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 подключения
Если несколько RD Web и Gateway как пробросить в интернет
Несколько белых IP или развернуть перед ними реверс прокси
А есть способ запретить ios\apple клиентов?
Объясните мне, откуда на скрине настройки политики RD CAP взялась группа \rdgwAllowExternalAuth??
Пользователям этой группы разрешена аутентфикация через RDGW. Действительно, не описал это в статье
А кто-нибудь сталкивался с тем, что при работе через rdg не работает буфер обмена, хотя в настройках rdp ярлыка и в Device Redirection стоят галки прокидывать буфер обмена и диски?
А есть возможность для определённой группы пользователей сделать ограничение на доступ с каких айпи можно авторизоваться?
Грубо говоря что бы определённая групаа имеющая доступ через шлюз к ферме могла подключаться только с айпи 195,248,191,70/24. Или каждому пользователю прописать с каких внешних айпи он может подключиться на шлюз?
Сам шлюз надо просто на маршрутизаторе открыть только с этой подсети. Это не на стороне самого rdg делается
Вопрос. У меня от клиентов до rdp хоста пинг нестабильный. В среднем 120, бывает и больше. Сильно удаленные скажем так. Если я поближе к ним поставлю шлюз — это сможет немного помочь?
Понятное дело пинг я не уменьшу. Речь о обрывах. То есть маленьком таймауте
Если задержка от GW до RDP хоста не изменится, то перенос шлюза ближе к пользователю ничего не даст.
Почему у некоторых подключения в мониторинге видны два коннекта? По HTTP и по UDP.
А как ведёт себя TLSv1.3 относительно RDG сервера при доступе с Windows 11?
Если через IISCrypto для Schannel оставить только TLSv1.3 на клиентской машине с Windows 11 через mstsc.exe, то подключение не срабатывает. Складывается впечатление, что mstsc.exe на Windows 11 не поддерживает TLSv1.3 для RDG шлюза.
Прослушал трафик, выделил два момента
А: при единственно разрешённом TLSv1.3 соединении (настроено через IISCrypto) mstsc.exe создаёт TCP соединение, где пробрасывает одиночный TLSv1.3 запрос с HTTP заголовком
GET / HTTP/1.1
Connection: Keep-Alive
User-Agent: TSG connection
а уже после ответа TCP соединение безуспешно закрывается.
Б: если же разрешить только TLSv1.3 и TLSv1.2 через IISCrypto (на том же Windows 11 с mstsc.exe),
то сначала к шлюзу создаётся TLSv1.3 соединение, тут же следом создаётся TLSv1.2 соединение, потом посылаются данные запроса для RDG Gateway (в заголовке методы уже не HTTPшные ) через вышеуказанное TLSv1.2 соединение, а изначальное TLSv1.3 соединение тут же закрывается без передачи каких либо данных, сразу же после TLS рукопожатия. При этом если продолжить далее, то уже после успешной проверки учётных данных через TLSv1.2 соединение шлюза к самому RDP серверу уже последует запрос с TLSv1.3 соединением для NLA аутентификации.
Для тех, кто не в теме, при использовании шлюза и последующего запроса NLA для RDP аутентификации данные ВСЕГДА инкапсулируются в уже второе TLS соединение, что по суди создаёт избыточную безопасность, увеличивая трафик, процессорную нагрузку итп., то есть через уже установленный туннель TLS до шлюза при использовании NLA ещё раз создаётся вторичный TLS туннель в TLS туннеле, через который пробрасывается уже RDP трафик. В принципе, как минимум от mstsc.exe до RDGateway сервера два TLS туннеля, а уже после RDGateway один туннель до конечного RDP сервера. Указал лишь для общей информации, что получается через TLSv1.2 до шлюза инкапсулируется уже TLSv1.3 соединение до RDP сервера.
Вот и думаю, у меня только так на Windows 11 клиенте с mstsc.exe или ни у кого не получается до шлюза TLSv1.3 соединение создать?
Судя по таблице TLS 1.3, поддерживается только в Win 11 и WS2022. У вас на стороне RDGW — 2022 версия?
_https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl—schannel-ssp-
Там версия поддерживающая TLS1.3, то есть RDP NLA протокол через TLS1.3 пробрасывается уже локально, но вот до RDG инстанции TLS1.2 именно со стороны КЛИЕНТА.
Эта таблица от Microsoft лишь сообщает об общей поддержке TLSv1.3, но не о поддержке RDG модулем mstsc.exe клиента нужного TLSv1.3 протокола.
Чем мусолить вопросы, сделайте пожалуйста лучше следующее: на своей Windows 11 машине сохраните следующие строки реестра в файл *чтоугодно*.reg и добавьте их тем самым в свой реестр. После чего запустите mstsc.exe с указанием своего WS2022 сервера с RDGW, и сообщите пожалуйста свой результат, если не затруднит! Со стороны RDGW ничего делать не нужно. Через Schannel по клиентским запросам отныне должны проходить только TLSv1.3 запросы, но…
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\Multi-Protocol Unified Hello\Client]
«DisabledByDefault»=dword:00000001
«Enabled»=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
«DisabledByDefault»=dword:00000001
«Enabled»=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
«DisabledByDefault»=dword:00000001
«Enabled»=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
«DisabledByDefault»=dword:00000001
«Enabled»=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client]
«DisabledByDefault»=dword:00000000
«Enabled»=dword:ffffffff
И ещё, чтобы наверняка, выключить клиентские запросы SSL2, SSL3 итд.
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Client]
«Enabled»=dword:00000000
«DisabledByDefault»=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
«Enabled»=dword:00000000
«DisabledByDefault»=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
«Enabled»=dword:00000000
«DisabledByDefault»=dword:00000001
PS: после проверки можно удалить содержимое ветки, чтобы вернуть, как было.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\
Кстати, на Windows 10 ни при каком раскладе не используется TLSv1.3 mstsc.exe RDG модулем даже при наличии форсированного использования в Schannel
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client]
«DisabledByDefault»=dword:00000000
«Enabled»=dword:ffffffff
Хотя если делать вызов на Windows 10 через WinHttpOpen с последующим использованием флажка WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_3 = 0x00002000, то такой TLSv1.3 запрос отлично проходит даже на Windows10 клиенте, не говоря уже о Windows 11, но это никак не влияет на продолжающуюся безуспешность подключения по TLSv1.3 самим mstsc.exe по RDG модулю, возникает ощущение, что на RDG модуле в mstsc.exe пока максимально возможный протокол TLSv1.2.
Но хотелось бы перепроверить у других, прежде чем со 100% уверенностью заявлять об этом.
Всё работало отлично.
Но сегодня после перезагрузки сервера RDG не запускается служба TSGateway.
В диспетчере серверов такая информация: «Служба шлюза удаленных рабочих столов завершает работу. Возможно, служба была перезапущена администратором либо на основе параметров конфигурации из-за изменения сертификата сервера шлюза удаленных рабочих столов. Если завершение работы службы шлюза удаленных рабочих столов не было запланировано, проверьте, запущены ли следующие службы: (1) сервер политики сети; (2) служба удаленного вызова процедур (RPC); (3) служба балансировки нагрузки RPC/HTTP; (4) служба веб-публикаций. Кроме того, о проблемах с сервером политики сети или IIS могут сообщать соответствующие события в средстве просмотра событий.»
Если через «Службы» попытаться запустить вручную, то «Служба «Шлюз удалённых рабочих столов» на «Локальный компьютер» была запущена а затем остановлена. Некоторые службы автоматически останавливаются, если они не используются другими службами или программами».
Пробовал восстанавливать виртуальную машину из резервной копии месячной давности — то же самое.
Если удалить КрипроПро и поставить его заново, то служба автоматически запускается, но при попытке подключиться ошибка «При подключении к удалённому ресурсу возникла проблема» и больше ничего.
В момент подключения по RDP к компьютеру через RDG создаётся запись в журнале (раздел «Система»):
Источник: HttpEvent
Код события: 15021
Сообщение: Произошла ошибка при использовании SSL-конфигурации для конечной точки 0.0.0.0:*****. Код состояния ошибки содержится в возвращенных данных.
А на компьютере с которого пытаюсь подключиться: «При подключении к удалённому ресурсу возникла проблема».
Тоже сталкивался с проблемой RDGW после установки КрипроПро. Насколькоя помню проблема была при использовании самопдписанного сертификата для RDGW. После перехода на доверенный сертификат Lets Encrypt (есть ссылка в статье), все заработало.
Добрый день. Не нашёл как посмотреть неудачные попытки авторизации. Сам пробовал просто с разными аккаунтами входить с неправильными паролями. Но моих попыток нет ни в одном журнале. Может так и должно быть.
Здравствуйте, подскажите решение такой проблемы, всё работает, но если заходить не сервер с телефона через приложение RDPClient/Windows App Mobile то авторизация проходит без сертификата, то бишь можно подключиться в легкую без сертификата не установленного на телефон, зная просто логин и пароль, получается уязвимость, как решить данную проблему?
Какой сертификат на RDGW: самоподписанный или доверенный lets encrypt? Подозреваю что первый вариант.
Как работают клиенты на телефонах — это вопрос к разработчику этих приложений. Возможно они просто игнорируют недоверенные сертификаты, это не запрещено.
наличие сертификата не означает, что вы ограничиваете по нему доступ — это средство проверки подлинности и шифрования.
Подскажите, пожалуйста, по настройке шлюза RD Gateway в рабочей группе.
Суть проблемы: пользователь, которому не импортируется сертификат, при подключении видит сообщение, что «компьютеру не удалось проверить удостоврение шлюза удаленных рабочих столов», но имеется кнопка «просмотреть сертификат», после чего его можно скачать и установить. А можно ли как-то сделать, чтобы при отсутствии сертификата пользователь просто отбрасывался? Иначе теряется смысл в самом сертификате. А параллельно вопрос, при пробросе портов (RDG находится в локальной сети) остается открытым порт и даже приветствует стартовая страничка IIS. Как защититься в этом случае от злоумышленников?
1) Сертификаты в данном случае это не средство аутентфикации, а средство удостоверения личности хоста и средство для шифрования трафика.
Клиенты должны видеть сертификат при подключении. А доверять ему или нет — решает сам клиент.
В данном случае для дальнейшей аутентфикации вы будете использовать пароль пользователя.
2) 80 порт можно отключить в настройках сайта IIS, или закрыть на файерволе.
Либо просто отключить default page в настройках Default Web Site -> “Default Document”. Отключите все страницы.