Как настроить MFA для RD Gateway: архитектура, шаги и лучшие практики

Введение

Удаленный рабочий стол Gateway (RD Gateway) защищает RDP через HTTPS, но одних только паролей недостаточно, чтобы остановить фишинг, атаки с использованием учетных данных или атаки методом перебора. Добавление многофакторной аутентификации (MFA) закрывает этот пробел, проверяя личность пользователя перед установлением сеанса. В этом руководстве вы узнаете, как MFA интегрируется с RD Gateway и NPS, точные шаги конфигурации и операционные советы, которые обеспечивают надежность вашей развертки в больших масштабах.

Почему RD Gateway нуждается в MFA?

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

Для RDP, доступного через интернет, основными рисками являются повторное использование паролей, попытки подбора, повторное использование токенов и перехват сеансов через неправильно настроенный TLS. MFA противодействует этим рискам, требуя второго фактора, устойчивого к повторному использованию учетных данных.

Многие рамки — NIST 800-63, ISO/IEC 27001 и различные базовые уровни киберстрахования — подразумевают или явно ожидают MFA на удаленный доступ Реализация MFA на RDG удовлетворяет как намерениям контроля, так и ожиданиям аудиторов, не требуя переработки вашей системы доставки.

Как MFA вписывается в архитектуру RD Gateway?

Управляющая плоскость проста: пользователь запускает RDP через RDG; RDG отправляет аутентификацию в NPS через RADIUS; NPS оценивает политику и вызывает поставщика MFA; в случае успеха NPS возвращает Access-Accept, и RDG завершает соединение. Авторизация к внутренним активам по-прежнему регулируется RD CAP/RD RAP, поэтому подтверждение личности является дополнительным, а не разрушительным.

• Поток аутентификации и точки принятия решений
• UX-аспекты для удаленных пользователей

Поток аутентификации и точки принятия решений

Ключевые моменты принятия решений включают, где работает логика MFA (NPS с расширением Entra MFA или сторонний прокси RADIUS), какие факторы разрешены и как обрабатываются сбои. Централизация решений по NPS упрощает аудит и контроль изменений. Для крупных объектов рассмотрите возможность использования выделенной пары NPS, чтобы отделить оценку политики от емкости RDG и упростить окна обслуживания.

UX-аспекты для удаленных пользователей

Подсказки на основе приложений и уведомления обеспечивают наиболее надежный опыт в RDP поток учетных данных. SMS и голос могут не сработать, если отсутствует вторичный интерфейс запроса. Обучите пользователей ожидаемым запросам, тайм-аутам и причинам отказа, чтобы сократить количество обращений в службу поддержки. В регионах с высокой задержкой умеренно увеличьте время ожидания вызова, чтобы избежать ложных сбоев, не скрывая при этом реальные злоупотребления.

Что такое контрольный список предварительных требований?

Чистая настройка начинается с проверенных ролей платформы и гигиены идентичности. Убедитесь, что RDG стабилен на поддерживаемом Windows Server и спланируйте путь отката. Подтвердите группы каталогов для определения доступа пользователей и проверьте, что администраторы могут различать изменения политики от проблем с сертификатами или сетью.

• Роли, Порты и Сертификаты
• Готовность к директории и идентичности

Роли, Порты и Сертификаты

Разверните роль NPS на сервере с надежным подключением к AD. Стандартизируйте на RADIUS UDP 1812/1813 и задокументируйте любое использование 1645/1646. На RDG установите общедоступный доверенный TLS-сертификат для HTTPS-слушателя и удалите слабые протоколы и шифры. Записывайте общие секреты в хранилище, а не в тикет или заметку на рабочем столе.

Готовность к директории и идентичности

Создайте выделенные группы AD для пользователей и администраторов, разрешенных для RDG; избегайте области "Пользователи домена". Убедитесь, что пользователи зарегистрированы в MFA, если используется Entra ID. Для сторонних поставщиков синхронизируйте идентичности и протестируйте пилотного пользователя от начала до конца перед массовой регистрацией. Согласуйте форматы имен пользователей (UPN против sAMAccountName) между RDG, NPS и платформой MFA, чтобы избежать тихих несоответствий.

Какова пошаговая настройка MFA для RD Gateway?

• Установить и зарегистрировать NPS
• Добавить RD Gateway в качестве клиента RADIUS
• Создать политики NPS (CRP и NP)
• Установите расширение MFA или сторонний агент
• Укажите шлюз RD на центральный NPS (магазин RD CAP)
• Тест MFA от начала до конца

Шаг 1 — Установите и зарегистрируйте NPS

Установите роль Службы сетевой политики и доступа, откройте nps.msc и зарегистрируйте NPS в Active Directory, чтобы он мог читать атрибуты пользователей. Проверьте Сервер политик сети Служба (IAS) работает, и сервер может достичь контроллера домена с низкой задержкой. Обратите внимание на FQDN/IP NPS для журналов и политик.

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

Установить-WindowsFeature NPAS -IncludeManagementTools nps.msc

Запуск netsh nps добавить зарегистрированный сервер

Get-Service IAS | Start-Service  
Test-Connection -Count 4 -ComputerName (Get-ADDomainController -Discover).HostName

Шаг 2 — Добавьте RD Gateway в качестве клиента RADIUS

В клиентах RADIUS добавьте ваш RD Gateway по IP/FQDN, установите удобное имя (например, РДГ01 ), и используйте общий секрет с высоким уровнем защиты. Откройте UDP 1812/1813 на сервере NPS и подтвердите доступность. Если у вас несколько RDG, добавьте каждый явно (возможны определения подсетей, но их легче неправильно настроить).

Дополнительные команды

Добавить клиента: netsh nps add client name="RDG01" address=10.0.10.20 sharedsecret="VeryLongVaultedSecret" vendor=standard enable=YES

netsh advfirewall firewall add rule name="RADIUS Auth (UDP 1812)" dir=in action=allow protocol=UDP localport=1812
netsh advfirewall firewall add rule name="RADIUS Acct (UDP 1813)" dir=in action=allow protocol=UDP localport=1813

Шаг 3 — Создание политик NPS (CRP и NP)

Создайте политику запроса подключения, ограниченную вашим IPv4-адресом клиента RDG. Выберите Аутентификация на этом сервере (для Microsoft Entra MFA через расширение NPS) или Переслать на удаленный RADIUS (для прокси MFA третьей стороны). Затем создайте сетевую политику, которая включает вашу группу(ы) AD (например, Группа пользователей ) с доступом предоставленным. Убедитесь, что обе политики находятся выше общих правил.

Дополнительные команды

# Проверьте, что пользователь находится в разрешенной группе
Get-ADUser user1 -Properties memberOf |
  Select-Object -ExpandProperty memberOf |
  Where-Object { $_ -like "*GRP_RDG_Users*" }

Снимок политики экспорта для справки: reg export "HKLM\SYSTEM\CurrentControlSet\Services\IAS\Policy" C:\NPS-Policy.reg /y

Шаг 4 — Установите расширение MFA или сторонний агент

Для Microsoft Entra MFA установите расширение NPS, выполните скрипт привязки арендатора и перезапустите NPS. Подтвердите, что пользователи зарегистрированы в MFA и предпочитают методы push/app. Для стороннего MFA установите RADIUS-прокси/агент поставщика, настройте конечные точки/общие секреты и укажите ваш CRP на эту удаленную группу.

Дополнительные команды

# Entra MFA NPS Extension привязка
Установить-Расположение "C:\Program Files\Microsoft\AzureMfa\"
.\AzureMfaNpsExtnConfigSetup.ps1
Перезапустить-Службу IAS

# Полезный регулятор ведения журнала (0–3)  
New-Item -Path HKLM:\SOFTWARE\Microsoft\AzureMfa -Force | Out-Null  
New-ItemProperty HKLM:\SOFTWARE\Microsoft\AzureMfa -Name LOG_LEVEL -Value 2 -PropertyType DWord -Force | Out-Null

Настройте удаленную группу RADIUS и сервер: netsh nps add remoteradiusservergroup name="MFA-VENDOR"
netsh nps add remoteradiusserver name="MFA-VENDOR" address=10.0.20.50 authport=1812 sharedsecret="AnotherVaultedSecret"

Шаг 5 — Указать RD Gateway на Central NPS (RD CAP Store)

На сервере RD Gateway установите RD CAP Store на центральный сервер с работающим NPS, добавьте хост NPS + общий секрет и проверьте подключение. Соответствуйте RD CAP вашей разрешенной группе пользователей и RD RAP конкретным компьютерам/коллекциям. Если MFA проходит, но доступ не удается, сначала проверьте область RAP.

Шаг 6 — Тестирование MFA от начала до конца

С внешнего клиента подключитесь через RDG к известному хосту и подтвердите один запрос MFA, NPS 6272 (Доступ предоставлен) и успешную сессию. Также протестируйте негативные пути (не в группе, не зарегистрирован, неправильный фактор, истекший токен), чтобы проверить ясность ошибок и готовность поддержки.

Что такое руководство по устранению неполадок MFA для RD Gateway?

Устранение неполадок проходит быстрее, когда вы разделяете сетевые, политические и идентификационные уровни. Начните с проверки доступности RADIUS и портов, затем проверьте соответствие политик, а затем просмотрите регистрацию MFA и типы факторов. Сохраните тестовую учетную запись с контролируемыми условиями, чтобы вы могли последовательно воспроизводить результаты во время окон изменений.

• Нет подсказок, циклов или тайм-аутов
• Сопоставление политик и область группы
• Логирование и телеметрия, которые вы действительно будете использовать
• Улучшение безопасности и лучшие практики операций
• Периметр, TLS и Минимальные привилегии
• Мониторинг, оповещение и контроль изменений
• Устойчивость и восстановление

Нет подсказок, циклов или тайм-аутов

Отсутствие подсказки часто указывает на пробелы в порядке политики или регистрации MFA. Циклы предполагают несоответствие общего секрета или рекурсию пересылки между NPS и прокси. Тайм-ауты обычно указывают на заблокированные UDP 1812/1813, асимметричную маршрутизацию или чрезмерно агрессивную проверку IDS/IPS. Временно увеличьте подробность ведения журналов, чтобы подтвердить, какой переход не удался.

Сопоставление политик и область группы

Подтвердите, что политика запроса подключения нацелена на клиента RDG и применяется до любых универсальных правил. В сетевой политике проверьте точную группу AD и поведение вложенности групп; некоторые среды требуют смягчения раздувания токенов или прямого членства. Обратите внимание на проблемы канонизации имен пользователей между UPN и именами в стиле NT.

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

Используйте NPS Accounting для корреляции и поддерживайте включенные операционные журналы RDG. На вашей платформе MFA просмотрите запросы, отказанные запросы и гео/IP-шаблоны по каждому пользователю. Создайте легкий дашборд: объем аутентификации, уровень отказов, основные причины отказов и среднее время вызова. Эти метрики помогают как в определении мощности, так и в безопасность настройка.

Улучшение безопасности и лучшие практики операций

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

Периметр, TLS и Минимальные привилегии

Поместите RDG в сегмент DMZ с повышенной защитой, с только необходимыми потоками в локальную сеть. Используйте доверенный публичный сертификат на RDG и отключите устаревшие функции. TLS и слабые шифры. Ограничьте доступ RDG через специальные группы AD; избегайте широких прав и убедитесь, что RD RAPs сопоставляют только те системы и порты, которые пользователи действительно нуждаются.

Мониторинг, оповещение и контроль изменений

Оповещение о всплесках неудачных аутентификаций, необычных географиях или повторных запросах от пользователя. Регистрация изменений конфигурации на NPS, RDG и платформе MFA с трассой одобрения. Рассматривайте политики как код: отслеживайте изменения в системе контроля версий или, по крайней мере, в реестре изменений, и тестируйте в тестовой среде перед переходом в продуктив.

Устойчивость и восстановление

Запустите NPS в резервном режиме и настройте RDG для обращения к нескольким серверам RADIUS. Документируйте поведение fail-open и fail-closed для каждого компонента; по умолчанию используйте fail-closed для внешнего доступа. Создайте резервную копию конфигурации NPS, политик RDG и настроек MFA; отрепетируйте восстановление, включая замену сертификата и повторную регистрацию расширения или агента MFA после восстановления.

Заключение

Добавление MFA к RD Gateway закрывает крупнейшую уязвимость в RDP, доступном через интернет: злоупотребление учетными данными. Централизуя политику на NPS и интегрируя Entra MFA или стороннего поставщика RADIUS, вы обеспечиваете надежную проверку личности без нарушения моделей RD CAP/RD RAP. Проверяйте с помощью целевых тестов, непрерывно контролируйте и сочетайте MFA с усиленным TLS, минимальными привилегиями и устойчивым дизайном NPS/RDG.