Jak nastavit MFA pro RD Gateway: Architektura, kroky a nejlepší postupy

Úvod

Remote Desktop Gateway (RD Gateway) zabezpečuje RDP přes HTTPS, ale samotná hesla nemohou zastavit phishing, naplnění pověření nebo útoky hrubou silou. Přidání vícefaktorové autentizace (MFA) tuto mezeru uzavírá tím, že ověřuje identitu uživatele před zahájením relace. V této příručce se naučíte, jak se MFA integruje s RD Gateway a NPS, přesné kroky konfigurace a provozní tipy, které udržují vaši implementaci spolehlivou v měřítku.

Proč RD Gateway potřebuje MFA?

RD Gateway centralizuje a provádí audity vzdálený přístup , ale sama o sobě nemůže neutralizovat ukradené přihlašovací údaje. Útoky pomocí plnění přihlašovacích údajů a phishing pravidelně obcházejí jednofaktorové obrany, zejména tam, kde existují zastaralé protokoly a široká expozice. Prosazení MFA na úrovni autentizace RDG blokuje většinu běžných útoků a dramaticky zvyšuje náklady na cílenou infiltraci.

Pro RDP vystavené na internetu jsou dominantními riziky opakované používání hesel, pokusy o hrubou sílu, opakování tokenů a únos relací prostřednictvím nesprávně nakonfigurovaného TLS. MFA těmto rizikům čelí tím, že vyžaduje druhý faktor odolný vůči opakování přihlašovacích údajů.

Mnoho rámců—NIST 800-63, kontroly ISO/IEC 27001 a různé základní úrovně kybernetického pojištění—implicitně nebo explicitně očekává MFA na vzdálený přístup cesty. Implementace MFA na RDG splňuje jak záměr kontroly, tak očekávání auditorů, aniž by bylo nutné přepracovávat vaši dodací strukturu.

Jak MFA zapadá do architektury RD Gateway?

Ovládací rovina je jednoduchá: uživatel spouští RDP přes RDG; RDG posílá autentizaci na NPS přes RADIUS; NPS vyhodnocuje politiku a vyvolává poskytovatele MFA; při úspěchu NPS vrací Access-Accept a RDG dokončuje připojení. Autorizace k interním prostředkům je stále řízena RD CAP/RD RAP, takže ověřování identity je doplňkové spíše než rušivé.

• Toky autentizace a rozhodovací body
• UX Úvahy pro vzdálené uživatele

Toky autentizace a rozhodovací body

Klíčové rozhodovací body zahrnují, kde běží logika MFA (NPS s rozšířením Entra MFA nebo proxy RADIUS třetí strany), které faktory jsou povoleny a jak se zachází s neúspěchy. Centralizace rozhodnutí na NPS zjednodušuje auditování a kontrolu změn. Pro velké majetky zvažte dedikovaný pár NPS, aby se oddělilo hodnocení politiky od kapacity RDG a zjednodušily se údržbové okna.

UX Úvahy pro vzdálené uživatele

Push a aplikace založené na výzvách poskytují nejspolehlivější zkušenost v RDP tok přihlašovacích údajů. SMS a hlasové výzvy mohou selhat, pokud neexistuje sekundární uživatelské rozhraní pro výzvy. Vzdělávejte uživatele o očekávaných výzvách, časových limitech a důvodech odmítnutí, abyste snížili počet podpůrných tiketů. V oblastech s vysokou latencí mírně prodlužte časové limity výzev, abyste se vyhnuli falešným selháním, aniž byste zakrývali skutečné zneužívání.

Jaký je kontrolní seznam požadavků?

Čistá konfigurace začíná ověřenými rolemi platformy a hygienou identity. Zajistěte, aby byl RDG stabilní na podporovaném Windows Serveru a naplánujte cestu zpět. Potvrďte adresářové skupiny pro určení přístupu uživatelů a ověřte, že administrátoři mohou rozlišit změny politiky od problémů s certifikáty nebo sítí.

• Role, porty a certifikáty
• Připravenost adresáře a identity

Role, porty a certifikáty

Nasadit roli NPS na server s spolehlivou konektivitou AD. Standardizovat na RADIUS UDP 1812/1813 a zdokumentujte jakékoli použití 1645/1646. Na RDG nainstalujte veřejně důvěryhodný TLS certifikát pro HTTPS posluchač a odstraňte slabé protokoly a šifry. Uložte sdílená tajemství do trezoru, nikoli do tiketu nebo poznámky na ploše.

Připravenost adresáře a identity

Vytvořte specializované AD skupiny pro uživatele a administrátory povolené RDG; vyhněte se rozsahu „Doménoví uživatelé“. Ověřte, že uživatelé jsou zaregistrováni v MFA, pokud používáte Entra ID. U třetích stran synchronizujte identity a otestujte pilotního uživatele od začátku do konce před širokým zaregistrováním. Upravte formáty uživatelských jmen (UPN vs sAMAccountName) mezi RDG, NPS a platformou MFA, abyste se vyhnuli tichým nesouladům.

Jaké je krok za krokem nastavení MFA pro RD Gateway?

• Nainstalovat a zaregistrovat NPS
• Přidat RD Gateway jako RADIUS klienta
• Vytvořit politiky NPS (CRP a NP)
• Nainstalujte rozšíření MFA nebo agenta třetí strany
• Nasměrujte RD Gateway na centrální NPS (RD CAP Store)
• Test MFA End-to-End

Krok 1 — Nainstalujte a zaregistrujte NPS

Nainstalujte roli Služby politiky sítě a přístupu, otevřete nps.msc a zaregistrujte NPS v Active Directory, aby mohl číst uživatelské atributy. Ověřte Server politiky sítě Služba (IAS) běží a server může dosáhnout řadiče domény s nízkou latencí. Poznamenejte si NPS FQDN/IP pro protokoly a politiky.

Volitelné příkazy:

Install-WindowsFeature NPAS -IncludeManagementTools nps.msc

Spustit netsh nps přidat registrovaný server

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

Krok 2 — Přidat RD Gateway jako RADIUS klienta

V RADIUS klientech přidejte svůj RD Gateway podle IP/FQDN, nastavte přátelské jméno (např., RDG01 ), a použijte vaultovaný, dlouhý sdílený tajný klíč. Otevřete UDP 1812/1813 na serveru NPS a potvrďte dosažitelnost. Pokud provozujete více RDG, přidejte každý explicitně (definice podsítí jsou možné, ale snadněji se mohou špatně nastavit).

Volitelné příkazy

Přidat klienta: netsh nps add client name="RDG01" address=10.0.10.20 sharedsecret="VeryLongVaultedSecret" vendor=standard enable=ANO

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

Krok 3 — Vytvoření politik NPS (CRP a NP)

Vytvořte politiku žádosti o připojení zaměřenou na vaši IPv4 adresu RDG klienta. Zvolte Ověřit na tomto serveru (pro Microsoft Entra MFA prostřednictvím rozšíření NPS) nebo Přesměrovat na vzdálený RADIUS (pro proxy třetí strany MFA). Poté vytvořte síťovou politiku, která zahrnuje vaši skupinu AD (např., GRP_RDG_Uživatelé ) s přístupem povoleným. Zajistěte, aby obě politiky byly nad obecným pravidly.

Volitelné příkazy

# Ověřte, zda je uživatel ve povolené skupině
Get-ADUser user1 -Properties memberOf |
  Select-Object -ExpandProperty memberOf |
  Where-Object { $_ -like "*GRP_RDG_Users*" }

Exportní politika pro referenci: reg export "HKLM\SYSTEM\CurrentControlSet\Services\IAS\Policy" C:\NPS-Policy.reg /y

Krok 4 — Nainstalujte rozšíření MFA nebo agenta třetí strany

Pro Microsoft Entra MFA nainstalujte rozšíření NPS, spusťte skript pro vazbu tenantů a restartujte NPS. Potvrďte, že uživatelé jsou zaregistrováni pro MFA a preferují metody push/aplikace. Pro MFA třetích stran nainstalujte RADIUS proxy/agent dodavatele, nakonfigurujte koncové body/podílená tajemství a nasměrujte svůj CRP na tuto vzdálenou skupinu.

Volitelné příkazy

# Entra MFA NPS Extension bind
Set-Location "C:\Program Files\Microsoft\AzureMfa\"
.\AzureMfaNpsExtnConfigSetup.ps1
Restart-Service IAS

# Užitečné nastavení protokolování (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

Nakonfigurujte vzdálenou skupinu RADIUS a server: netsh nps add remoteradiusservergroup name="MFA-VENDOR"
netsh nps add remoteradiusserver name="MFA-VENDOR" address=10.0.20.50 authport=1812 sharedsecret="AnotherVaultedSecret"

Krok 5 — Nasměrujte RD Gateway na centrální NPS (RD CAP Store)

Na serveru RD Gateway nastavte RD CAP Store na centrální server s běžícím NPS, přidejte hostitele NPS + sdílené tajemství a ověřte konektivitu. Upravte RD CAP podle vašich povolených uživatelských skupin a RD RAP podle konkrétních počítačů/kolekcí. Pokud MFA uspěje, ale přístup selže, nejprve zkontrolujte rozsah RAP.

Krok 6 — Otestujte MFA od začátku do konce

Z externího klienta se připojte přes RDG k známému hostiteli a potvrďte jeden výzvu MFA, NPS 6272 (Přístup povolen) a úspěšnou relaci. Také otestujte negativní cesty (není ve skupině, není zapsán, špatný faktor, vypršený token), abyste ověřili jasnost chyb a připravenost podpory.

Co je Troubleshooting Playbook MFA pro RD Gateway?

Odstraňování problémů je nejrychlejší, když oddělíte síťové, politické a identitní vrstvy. Začněte kontrolou dostupnosti RADIUS a portů, poté ověřte shodu politiky, a nakonec zkontrolujte registraci MFA a typy faktorů. Mějte testovací účet s kontrolovanými podmínkami, abyste mohli výsledky konzistentně reprodukovat během změnových oken.

• Žádné výzvy, smyčky ani časové limity
• Shoda politiky a rozsah skupiny
• Logging a telemetrie, které skutečně využijete
• Zabezpečení a nejlepší postupy pro provoz
• Perimetr, TLS a Nejmenší privilegium
• Monitoring, upozorňování a řízení změn
• Odolnost a obnova

Žádné výzvy, smyčky ani časové limity

Žádný prompt často naznačuje mezery v objednávce politiky nebo registraci MFA. Smyčky naznačují nesoulad sdíleného tajemství nebo rekurzi přesměrování mezi NPS a proxy. Časové limity obvykle ukazují na blokované UDP 1812/1813, asymetrické směrování nebo příliš agresivní inspekci IDS/IPS. Dočasně zvyšte podrobnost protokolování, abyste potvrdili, který skok selhává.

Shoda politiky a rozsah skupiny

Potvrďte, že politika žádosti o připojení cílí na klienta RDG a zasahuje před jakoukoli pravidlem pro všechny. V síťové politice ověřte přesnou skupinu AD a chování vnoření skupin; některá prostředí vyžadují zmírnění nadměrného zatížení tokenů nebo přímé členství. Sledujte problémy s kanonizací uživatelských jmen mezi názvy UPN a NT.

Logging a telemetrie, které skutečně využijete

Použijte NPS Accounting pro korelaci a udržujte povolené provozní protokoly RDG. Z vaší platformy MFA zkontrolujte výzvy, zamítnutí a geo/IP vzory na úrovni uživatelů. Vytvořte lehký panel: objem autentizace, míra selhání, hlavní důvody selhání a průměrný čas výzvy. Tyto metriky řídí jak kapacitu, tak bezpečnost ladění.

Zabezpečení a nejlepší postupy pro provoz

MFA je nezbytná, ale nestačí. Kombinujte ji s segmentací sítě, moderním TLS, minimálními oprávněními a silným monitorováním. Udržujte krátký, vynucený základ—zpevnění funguje pouze tehdy, pokud je aplikováno konzistentně a ověřeno po opravách a aktualizacích.

Perimetr, TLS a Nejmenší privilegium

Umístěte RDG do zpevněného segmentu DMZ s pouze požadovanými toky do LAN. Použijte důvěryhodný veřejný certifikát na RDG a deaktivujte zastaralé. TLS a slabé šifry. Omezte přístup RDG prostřednictvím specializovaných skupin AD; vyhněte se širokým oprávněním a zajistěte, aby RD RAPs mapovaly pouze systémy a porty, které uživatelé skutečně potřebují.

Monitoring, upozorňování a řízení změn

Upozornění na výkyvy v neúspěšných autentizacích, neobvyklé geografické oblasti nebo opakované výzvy na uživatele. Zaznamenávejte změny konfigurace na NPS, RDG a platformě MFA s trasou schválení. Zacházejte s politikami jako s kódem: sledujte změny v řízení zdrojů nebo alespoň v registru změn a testujte v testovacím prostředí před přechodem do produkce.

Odolnost a obnova

Spusťte NPS redundantně a nakonfigurujte RDG tak, aby odkazoval na více serverů RADIUS. Dokumentujte chování fail-open vs fail-closed pro každou komponentu; ve výchozím nastavení použijte fail-closed pro externí přístup. Zálohujte konfiguraci NPS, politiky RDG a nastavení MFA; procvičte obnovu, včetně výměny certifikátu a znovu registrace rozšíření nebo agenta MFA po rekonstrukci.

Závěr

Přidání MFA k RD Gateway uzavírá největší mezeru v RDP směřujícím na internet: zneužití přihlašovacích údajů. Centralizací politiky na NPS a integrací Entra MFA nebo poskytovatele RADIUS třetí strany vynucujete silné ověřování identity, aniž byste narušili modely RD CAP/RD RAP. Ověřujte cílenými testy, monitorujte nepřetržitě a kombinujte MFA s posíleným TLS, minimálními oprávněními a odolným designem NPS/RDG.