Hur man ställer in MFA för RD Gateway: Arkitektur, steg och bästa metoder

Introduktion

Remote Desktop Gateway (RD Gateway) säkrar RDP över HTTPS, men lösenord ensamma kan inte stoppa phishing, credential stuffing eller bruteforce-attacker. Att lägga till tvåfaktorsautentisering (MFA) stänger den luckan genom att verifiera användarens identitet innan en session etableras. I den här guiden kommer du att lära dig hur MFA integreras med RD Gateway och NPS, de exakta konfigurationsstegen och de operativa tipsen som håller din distribution pålitlig i stor skala.

Varför behöver RD Gateway MFA?

RD Gateway centraliserar och granskar fjärråtkomst , men det kan inte neutralisera stulna referenser av sig själv. Credential stuffing och phishing kringgår rutinmässigt enskilda faktorer, särskilt där äldre protokoll och bred exponering finns. Att genomdriva MFA på RDG-autentiseringstjänsten blockerar de flesta vanliga attacker och höjer dramatiskt kostnaden för riktade intrång.

För internetansluten RDP är de dominerande riskerna lösenordsåteranvändning, bruteforce-försök, tokenåterspelning och sessionkapning via felkonfigurerad TLS. MFA motverkar dessa genom att kräva en andra faktor som är motståndskraftig mot credentialåterspelning.

Många ramverk—NIST 800-63, ISO/IEC 27001-kontroller och olika cybersäkerhetsförsäkringsstandarder—förväntar sig implicit eller explicit MFA på fjärråtkomst vägar. Att implementera MFA på RDG uppfyller både kontrollintention och revisorers förväntningar utan att omstrukturera din leveransstack.

Hur MFA passar in i RD Gateway-arkitekturen?

Kontrollplanet är enkelt: användaren startar RDP via RDG; RDG skickar autentisering till NPS över RADIUS; NPS utvärderar policyn och anropar MFA-leverantören; vid framgång returnerar NPS Access-Accept och RDG slutför anslutningen. Auktorisering till interna tillgångar styrs fortfarande av RD CAP/RD RAP, så identitetsverifiering är tilläggande snarare än störande.

• Autentisering Flöde och Beslutspunkter
• UX-överväganden för fjärranvändare

Autentisering Flöde och Beslutspunkter

Nyckelbeslutsfattande punkter inkluderar var MFA-logiken körs (NPS med Entra MFA-tillägget eller en tredjeparts RADIUS-proxy), vilka faktorer som är tillåtna och hur misslyckanden hanteras. Att centralisera beslut om NPS förenklar granskning och förändringskontroll. För stora miljöer, överväg ett dedikerat NPS-par för att separera policyutvärdering från RDG-kapacitet och för att förenkla underhållsfönster.

UX-överväganden för fjärranvändare

Push- och appbaserade meddelanden ger den mest pålitliga upplevelsen i den RDP credential flow. SMS och röst kan misslyckas där ingen sekundär prompt UI finns. Utbilda användare om förväntade uppmaningar, tidsgränser och avvisningsorsaker för att minska supportärenden. I områden med hög latens, förläng utmaningens tidsgränser måttligt för att undvika falska misslyckanden utan att dölja verkligt missbruk.

Vad är checklistan för förutsättningar?

En ren installation börjar med verifierade plattformsroller och identitetshygien. Se till att RDG är stabilt på en stödd Windows Server och planera en återställningsväg. Bekräfta kataloggrupper för att avgränsa användartillgång och validera att administratörer kan särskilja policyändringar från certifikat- eller nätverksproblem.

• Roller, portar och certifikat
• Katalog- och identitetsberedskap

Roller, portar och certifikat

Distribuera NPS-rollen på en server med pålitlig AD-anslutning. Standardisera på RADIUS UDP 1812/1813 och dokumentera eventuell användning av 1645/1646. På RDG, installera ett offentligt betrott TLS-certifikat för HTTPS-lyssnaren och ta bort svaga protokoll och chiffer. Registrera delade hemligheter i ett valv, inte en biljett eller skrivbordsanteckning.

Katalog- och identitetsberedskap

Skapa dedikerade AD-grupper för RDG-tillåtna användare och administratörer; undvik "Domänanvändare" omfattning. Verifiera att användare är registrerade i MFA om Entra ID används. För tredjepartsleverantörer, synkronisera identiteter och testa en pilotanvändare från början till slut innan bred registrering. Justera användarnamnformat (UPN vs sAMAccountName) mellan RDG, NPS och MFA-plattformen för att undvika tysta mismatchar.

Vad är steg-för-steg-konfigurationen av MFA för RD Gateway?

• Installera och registrera NPS
• Lägg till RD Gateway som en RADIUS-klient
• Skapa NPS-policyer (CRP & NP)
• Installera MFA-tillägg eller tredjepartsagent
• Peka RD Gateway mot Central NPS (RD CAP Store)
• Testa MFA End-to-End

Steg 1 — Installera och registrera NPS

Installera rollen för nätverkspolicy och åtkomsttjänster, öppna nps.msc och registrera NPS i Active Directory så att det kan läsa användarattribut. Verifiera den Nätverkspolicytjänst (IAS) tjänsten körs och att servern kan nå en domänkontrollant med låg latens. Notera NPS FQDN/IP för loggar och policys.

Valfria kommandon:

Install-WindowsFeature NPAS -IncludeManagementTools nps.msc

Kör netsh nps lägg till registrerad server

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

Steg 2 — Lägg till RD Gateway som en RADIUS-klient

I RADIUS-klienter, lägg till din RD Gateway med IP/FQDN, ange ett vänligt namn (t.ex., RDG01 ), och använd en valvformad, lång delad hemlighet. Öppna UDP 1812/1813 på NPS-servern och bekräfta nåbarhet. Om du kör flera RDG:er, lägg till varje uttryckligen (subnätdefinitioner är möjliga men lättare att felaktigt avgränsa).

Valfria kommandon

Lägg till en klient: netsh nps add client name="RDG01" address=10.0.10.20 sharedsecret="VeryLongVaultedSecret" vendor=standard enable=JA

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

Steg 3 — Skapa NPS-policyer (CRP & NP)

Skapa en anslutningsbegäranpolicy som omfattar din RDG-klient IPv4-adress. Välj Autentisera på den här servern (för Microsoft Entra MFA via NPS-tillägget) eller Vidarebefordra till fjärr-RADIUS (för en tredjeparts MFA-proxy). Skapa sedan en nätverkspolicy som inkluderar din AD-grupp(er) (t.ex., GRP_RDG_Användare ) med åtkomst beviljad. Se till att båda policys ligger över generella regler.

Valfria kommandon

# Verifiera att en användare är i den tillåtna gruppen
Get-ADUser user1 -Properties memberOf |
  Select-Object -ExpandProperty memberOf |
  Where-Object { $_ -like "*GRP_RDG_Users*" }

Exportpolicy översikt för referens: reg export "HKLM\SYSTEM\CurrentControlSet\Services\IAS\Policy" C:\NPS-Policy.reg /y

Steg 4 — Installera MFA-tillägg eller tredjepartsagent

För Microsoft Entra MFA, installera NPS-tillägget, kör skriptet för hyresgästsbindning och starta om NPS. Bekräfta att användare är MFA-registrerade och föredrar push/app-metoder. För tredjeparts MFA, installera leverantörens RADIUS-proxy/agent, konfigurera slutpunkter/delade hemligheter och peka din CRP till den fjärrgruppen.

Valfria kommandon

# Entra MFA NPS-tillägg bind
Ställ in plats "C:\Program Files\Microsoft\AzureMfa\"
.\AzureMfaNpsExtnConfigSetup.ps1
Starta om tjänsten IAS

# Användbar loggnivå (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

Konfigurera en fjärr-RADIUS-grupp och server: netsh nps add remoteradiusservergroup name="MFA-VENDOR"
netsh nps add remoteradiusserver name="MFA-VENDOR" address=10.0.20.50 authport=1812 sharedsecret="AnotherVaultedSecret"

Steg 5 — Pek RD Gateway till Central NPS (RD CAP Store)

På RD Gateway-servern, ställ in RD CAP Store till Central server som kör NPS, lägg till NPS-värden + delad hemlighet och verifiera anslutningen. Justera RD CAP till dina tillåtna användargrupp(er) och RD RAP till de specifika datorerna/kollektionerna. Om MFA lyckas men åtkomst misslyckas, kontrollera först RAP-omfånget.

Steg 6 — Testa MFA End-to-End

Från en extern klient, anslut genom RDG till en känd värd och bekräfta en MFA-prompt, NPS 6272 (Åtkomst beviljad), och en framgångsrik session. Testa även negativa vägar (inte i grupp, inte registrerad, fel faktor, utgånget token) för att validera felklarhet och supportberedskap.

Vad är felsökningshandboken för MFA för RD Gateway?

Felsökning går snabbast när du separerar nätverks-, policy- och identitetslager. Börja med RADIUS-åtkomlighet och portkontroller, validera sedan policyöverensstämmelse, och granska sedan MFA-registrering och faktortyper. Ha ett testkonto med kontrollerade förhållanden så att du kan reproducera resultat konsekvent under förändringsfönster.

• Ingen uppmaning, loopar eller tidsgränser
• Policy Matching & Group Scope
• Loggning och telemetri som du faktiskt kommer att använda
• Säkerhetsförstärkning och driftbästa praxis
• Perimeter, TLS och Minsta Privilegium
• Övervakning, Larm och Ändringskontroll
• Resiliens och återhämtning

Ingen uppmaning, loopar eller tidsgränser

Ingen uppmaning indikerar ofta brister i policyn eller registrering av MFA. Loopar tyder på en mismatch av delad hemlighet eller vidarebefordringsrekursion mellan NPS och en proxy. Tidsgränser pekar vanligtvis på blockerad UDP 1812/1813, asymmetrisk routing eller alltför aggressiv IDS/IPS-inspektion. Öka loggningsverbositeten tillfälligt för att bekräfta vilken hop som misslyckas.

Policy Matching & Group Scope

Bekräfta att anslutningsbegäranens policy riktar sig mot RDG-klienten och träffar innan någon catch-all-regel. I nätverkspolicyn, verifiera den exakta AD-gruppen och gruppnestningsbeteendet; vissa miljöer kräver åtgärder för att minska tokenbloat eller direkt medlemskap. Var uppmärksam på problem med kanonisering av användarnamn mellan UPN och NT-stilnamn.

Loggning och telemetri som du faktiskt kommer att använda

Använd NPS Accounting för korrelation och håll RDG operativa loggar aktiverade. Från din MFA-plattform, granska per-användare uppmaningar, nekanden och geo/IP-mönster. Etablera en lättviktig instrumentpanel: autentiseringens volym, misslyckandegrad, de främsta orsakerna till misslyckande och genomsnittlig utmaningstid. Dessa mätvärden vägleder både kapacitet och säkerhet justering.

Säkerhetsförstärkning och driftbästa praxis

MFA är nödvändigt men inte tillräckligt. Kombinera det med nätverkssegmentering, modern TLS, minimiåtkomst och stark övervakning. Håll en kort, genomdriven baslinje—härdning fungerar endast om den tillämpas konsekvent och verifieras efter patchar och uppgraderingar.

Perimeter, TLS och Minsta Privilegium

Placera RDG i ett härdat DMZ-segment med endast nödvändiga flöden in i LAN. Använd ett betrott offentligt certifikat på RDG och inaktivera äldre versioner. TLS och svaga chiffer. Begränsa RDG-åtkomst via dedikerade AD-grupper; undvik breda rättigheter och se till att RD RAP:er endast kartlägger de system och portar som användarna faktiskt behöver.

Övervakning, Larm och Ändringskontroll

Alert om toppar i misslyckade autentiseringar, ovanliga geografier eller upprepade uppmaningar per användare. Logga konfigurationsändringar på NPS, RDG och MFA-plattformen med en godkännandespårning. Behandla policyer som kod: spåra ändringar i källkontroll eller åtminstone i en ändringsregister, och testa i en staging-miljö innan produktionsövergång.

Resiliens och återhämtning

Kör NPS redundanta och konfigurera RDG för att referera till flera RADIUS-servrar. Dokumentera fail-open vs fail-closed beteende för varje komponent; standardisera till fail-closed för extern åtkomst. Säkerhetskopiera NPS-konfiguration, RDG-policyer och MFA-inställningar; öva återställning, inklusive certifikatbyte och omregistrering av MFA-tillägget eller agenten efter en ombyggnad.

Slutsats

Att lägga till MFA till RD Gateway stänger den största luckan i internetansluten RDP: autentiseringsmissbruk. Genom att centralisera policyn på NPS och integrera Entra MFA eller en tredjeparts RADIUS-leverantör, tvingar du fram stark identitetsverifiering utan att störa RD CAP/RD RAP-modeller. Validera med riktade tester, övervaka kontinuerligt och kombinera MFA med förstärkt TLS, minimiåtkomst och motståndskraftig NPS/RDG-design.