Hvordan man opsætter MFA til RD Gateway: Arkitektur, trin og bedste praksis

Introduktion

Remote Desktop Gateway (RD Gateway) sikrer RDP over HTTPS, men adgangskoder alene kan ikke stoppe phishing, credential stuffing eller brute-force angreb. At tilføje Multi-Factor Authentication (MFA) lukker det hul ved at verificere brugerens identitet, før en session oprettes. I denne guide vil du lære, hvordan MFA integreres med RD Gateway og NPS, de præcise konfigurationstrin og de operationelle tips, der holder din implementering pålidelig i stor skala.

Hvorfor RD Gateway har brug for MFA?

RD Gateway centraliserer og reviderer fjernadgang , men det kan ikke neutralisere stjålne legitimationsoplysninger af sig selv. Credential stuffing og phishing omgår rutinemæssigt enkeltfaktorbeskyttelse, især hvor ældre protokoller og bred eksponering findes. Håndhævelse af MFA på RDG-godkendelsesniveauet blokerer de fleste almindelige angreb og hæver dramatisk omkostningerne ved målrettet indtrængen.

For internet-facing RDP er de dominerende risici genbrug af adgangskoder, brute-force forsøg, token replay og session hijacking via forkert konfigureret TLS. MFA modvirker disse ved at kræve en anden faktor, der er modstandsdygtig over for credential replay.

Mange rammer—NIST 800-63, ISO/IEC 27001 kontroller og forskellige cybersikringsgrundlag—forventer implicit eller eksplicit MFA på fjernadgang Implementering af MFA på RDG opfylder både kontrolintentionen og revisorernes forventninger uden at omstrukturere din leveringsstak.

Hvordan MFA passer ind i RD Gateway-arkitekturen?

Kontrolplanet er enkelt: brugeren starter RDP gennem RDG; RDG sender godkendelse til NPS over RADIUS; NPS evaluerer politik og aktiverer MFA-udbyderen; ved succes returnerer NPS Access-Accept, og RDG fuldfører forbindelsen. Autorisation til interne aktiver styres stadig af RD CAP/RD RAP, så identitetsbevis er tillæggende snarere end forstyrrende.

• Godkendelsesflow og beslutningspunkter
• UX Overvejelser for Fjernbrugere

Godkendelsesflow og beslutningspunkter

Nøglebeslutningspunkter inkluderer, hvor MFA-logikken kører (NPS med Entra MFA-udvidelsen eller en tredjeparts RADIUS-proxy), hvilke faktorer der er tilladt, og hvordan fejl håndteres. Centralisering af beslutninger om NPS forenkler revision og ændringskontrol. For store ejendomme bør man overveje et dedikeret NPS-par for at adskille politikvurdering fra RDG-kapacitet og for at forenkle vedligeholdelsesvinduer.

UX Overvejelser for Fjernbrugere

Push- og app-baserede meddelelser giver den mest pålidelige oplevelse i den RDP credential flow. SMS og stemme kan fejle, hvor der ikke findes nogen sekundær prompt UI. Uddan brugerne om forventede prompts, tidsgrænser og afvisningsårsager for at reducere supportbilletter. I høj-latens regioner, forlæng udfordringens tidsgrænser moderat for at undgå falske fejl uden at skjule ægte misbrug.

Hvad er tjeklisten for forudsætninger?

En ren opsætning starter med verificerede platformroller og identitetshygiejne. Sørg for, at RDG er stabil på en understøttet Windows Server, og planlæg en tilbageføringsvej. Bekræft kataloggrupper for at afgrænse brugeradgang, og bekræft, at administratorer kan skelne mellem politikændringer og certifikat- eller netværksproblemer.

• Roller, porte og certifikater
• Katalog- og identitetsparathed

Roller, porte og certifikater

Implementer NPS-rollen på en server med pålidelig AD-forbindelse. Standardiser på RADIUS UDP 1812/1813 og dokumenter enhver brug af 1645/1646. På RDG, installer et offentligt betroet TLS-certifikat til HTTPS-lytteren og fjern svage protokoller og krypteringsmetoder. Optag delte hemmeligheder i et pengeskab, ikke en billet eller skrivebordsnote.

Katalog- og identitetsparathed

Opret dedikerede AD-grupper for RDG-godkendte brugere og administratorer; undgå "Domain Users" omfang. Bekræft, at brugerne er tilmeldt MFA, hvis der anvendes Entra ID. For tredjepartsudbydere, synkroniser identiteter og test en pilotbruger fra ende til ende, før bred tilmelding. Juster brugernavnsformater (UPN vs sAMAccountName) mellem RDG, NPS og MFA-platformen for at undgå stille uoverensstemmelser.

Hvad er den trin-for-trin konfiguration af MFA til RD Gateway?

• Installer og registrer NPS
• Tilføj RD Gateway som en RADIUS-klient
• Opret NPS-politikker (CRP & NP)
• Installer MFA-udvidelse eller tredjepartsagent
• Peg RD Gateway til Central NPS (RD CAP Store)
• Test MFA End-to-End

Trin 1 — Installer & Registrer NPS

Installer rollen for netværkspolitik og adgangstjenester, åbn nps.msc , og registrer NPS i Active Directory, så det kan læse brugerattributter. Bekræft den Netværkspolitikserver (IAS) tjenesten kører, og at serveren kan nå en domænecontroller med lav latenstid. Bemærk NPS FQDN/IP til logs og politikker.

Valgfri kommandoer:

Install-WindowsFeature NPAS -IncludeManagementTools nps.msc

Kør netsh nps tilføj registreret server

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

Trin 2 — Tilføj RD Gateway som en RADIUS-klient

I RADIUS-klienter skal du tilføje din RD Gateway ved IP/FQDN, angive et venligt navn (f.eks., RDG01 ), og brug en hævet, lang delt hemmelighed. Åbn UDP 1812/1813 på NPS-serveren og bekræft tilgængelighed. Hvis du kører flere RDG'er, skal du tilføje hver enkelt eksplicit (subnetdefinitioner er mulige, men lettere at misforstå).

Valgfri kommandoer

Tilføj 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

Trin 3 — Opret NPS-politikker (CRP & NP)

Opret en forbindelseanmodningspolitik, der er afgrænset til din RDG-klient IPv4-adresse. Vælg Godkend på denne server (til Microsoft Entra MFA via NPS-udvidelsen) eller Videre til fjern RADIUS (til en tredjeparts MFA-proxy). Opret derefter en netværkspolitik, der inkluderer din AD-gruppe(r) (f.eks., GRP_RDG_Users ) med adgang givet. Sørg for, at begge politikker ligger over generelle regler.

Valgfri kommandoer

# Bekræft, at en bruger er i den tilladte gruppe
Get-ADUser user1 -Properties memberOf |
  Select-Object -ExpandProperty memberOf |
  Where-Object { $_ -like "*GRP_RDG_Users*" }

Eksportpolitiksnapshot til reference: reg export "HKLM\SYSTEM\CurrentControlSet\Services\IAS\Policy" C:\NPS-Policy.reg /y

Trin 4 — Installer MFA-udvidelse eller tredjepartsagent

For Microsoft Entra MFA, installer NPS-udvidelsen, kør tenant-binding-scriptet, og genstart NPS. Bekræft, at brugerne er MFA-tilmeldt og foretrækker push/app-metoder. For tredjeparts MFA, installer leverandørens RADIUS-proxy/agent, konfigurer slutpunkter/delte hemmeligheder, og peg din CRP til den fjerne gruppe.

Valgfri kommandoer

# Entra MFA NPS Extension bind  
Skift placering til "C:\Program Files\Microsoft\AzureMfa\"  
.\AzureMfaNpsExtnConfigSetup.ps1  
Genstart-tjeneste IAS

# Nytte logging knap (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

Konfigurer en fjern RADIUS-gruppe og server: netsh nps add remoteradiusservergroup name="MFA-VENDOR"
netsh nps add remoteradiusserver name="MFA-VENDOR" address=10.0.20.50 authport=1812 sharedsecret="AnotherVaultedSecret"

Trin 5 — Peg RD Gateway til Central NPS (RD CAP Store)

På RD Gateway-serveren skal du indstille RD CAP Store til Central server, der kører NPS, tilføje NPS-vært + delt hemmelighed og verificere forbindelsen. Juster RD CAP til dine tilladte brugergruppe(r) og RD RAP til de specifikke computere/kollektioner. Hvis MFA lykkes, men adgangen fejler, skal du først kontrollere RAP-omfanget.

Trin 6 — Test MFA End-to-End

Fra en ekstern klient, forbind gennem RDG til en kendt vært og bekræft en MFA-prompt, NPS 6272 (Adgang givet), og en vellykket session. Test også negative stier (ikke i gruppe, ikke tilmeldt, forkert faktor, udløbet token) for at validere fejlklarhed og supportberedskab.

Hvad er fejlfindingens playbook for MFA til RD Gateway?

Fejlfinding er hurtigst, når du adskiller netværks-, politik- og identitetslag. Start med RADIUS-tilgængelighed og portkontroller, derefter valider politikoverensstemmelse, og gennemgå derefter MFA-tilmelding og faktortyper. Hold en testkonto med kontrollerede forhold, så du kan reproducere resultater konsekvent under ændringsvinduer.

• Ingen prompt, loops eller timeouts
• Politikmatchning og gruppeomfang
• Logging og Telemetri, du faktisk vil bruge
• Sikkerhedshærdning og drifts bedste praksis
• Perimeter, TLS og Mindste privilegium
• Overvågning, Alarmering og Ændringskontrol
• Modstandsdygtighed og genopretning

Ingen prompt, loops eller timeouts

Ingen prompt indikerer ofte politikrækkefølge eller MFA-tilmeldingshuller. Løkker antyder en mismatch af delt hemmelighed eller videresendingsrekursion mellem NPS og en proxy. Timeout peger normalt på blokeret UDP 1812/1813, asymmetrisk routing eller alt for aggressiv IDS/IPS-inspektion. Øg logningsdetaljer midlertidigt for at bekræfte, hvilken hop der fejler.

Politikmatchning og gruppeomfang

Bekræft, at politikken for anmodning om forbindelse retter sig mod RDG-klienten og rammer før nogen catch-all regel. I netværkspolitikken skal du bekræfte den nøjagtige AD-gruppe og gruppenestingadfærd; nogle miljøer kræver afhjælpning af tokenbloat eller direkte medlemskab. Vær opmærksom på problemer med kanonalisering af brugernavne mellem UPN og NT-stil navne.

Logging og Telemetri, du faktisk vil bruge

Brug NPS Accounting til korrelation og hold RDG operationelle logfiler aktiveret. Gennemgå pr. bruger prompts, afvisninger og geo/IP mønstre fra din MFA-platform. Etabler et letvægts dashboard: autentificeringsvolumen, fejlrater, de vigtigste årsager til fejl og gennemsnitlig udfordringstid. Disse målinger guider både kapacitet og sikkerhed justering.

Sikkerhedshærdning og drifts bedste praksis

MFA er nødvendigt, men ikke tilstrækkeligt. Kombiner det med netværkssegmentering, moderne TLS, mindst privilegium og stærk overvågning. Hold en kort, håndhævet baseline - hårdning fungerer kun, hvis det anvendes konsekvent og verificeres efter opdateringer og opgraderinger.

Perimeter, TLS og Mindste privilegium

Placer RDG i et hærdet DMZ-segment med kun nødvendige flows ind i LAN. Brug et betroet offentligt certifikat på RDG og deaktiver legacy. TLS og svage krypteringer. Begræns RDG-adgang via dedikerede AD-grupper; undgå brede rettigheder og sørg for, at RD RAP'er kun kortlægger de systemer og porte, som brugerne faktisk har brug for.

Overvågning, Alarmering og Ændringskontrol

Advarsel om spidser i mislykkede godkendelser, usædvanlige geografier eller gentagne anmodninger pr. bruger. Log konfigurationsændringer på NPS, RDG og MFA-platformen med en godkendelsessporing. Behandl politikker som kode: spor ændringer i kildekontrol eller i det mindste i et ændringsregister, og test i et staging-miljø før produktionsovergang.

Modstandsdygtighed og genopretning

Kør NPS redundantly og konfigurer RDG til at referere til flere RADIUS-servere. Dokumenter fail-open vs fail-closed adfærd for hver komponent; standard til fail-closed for ekstern adgang. Tag backup af NPS-konfiguration, RDG-politikker og MFA-indstillinger; øv genopretning, herunder certifikatudskiftning og genregistrering af MFA-udvidelsen eller agenten efter en genopbygning.

Konklusion

At tilføje MFA til RD Gateway lukker det største hul i internet-facing RDP: misbrug af legitimationsoplysninger. Ved at centralisere politikken på NPS og integrere Entra MFA eller en tredjeparts RADIUS-udbyder, håndhæver du stærk identitetsbekræftelse uden at forstyrre RD CAP/RD RAP-modeller. Valider med målrettede tests, overvåg kontinuerligt, og kombiner MFA med hårdfør TLS, mindst privilegium og modstandsdygtigt NPS/RDG-design.