Hvordan sette opp MFA for RD Gateway: Arkitektur, trinn og beste praksiser

Introduksjon

Remote Desktop Gateway (RD Gateway) sikrer RDP over HTTPS, men passord alene kan ikke stoppe phishing, credential stuffing eller brute-force angrep. Å legge til Multi-Factor Authentication (MFA) lukker dette gapet ved å verifisere brukerens identitet før en økt opprettes. I denne guiden vil du lære hvordan MFA integreres med RD Gateway og NPS, de nøyaktige konfigurasjonstrinnene, og de operative tipsene som holder distribusjonen din pålitelig i stor skala.

Hvorfor RD Gateway trenger MFA?

RD Gateway sentraliserer og reviderer fjernaksess , men det kan ikke nøytralisere stjålne legitimasjoner av seg selv. Credential stuffing og phishing omgår rutinemessig en-faktor-forsvar, spesielt der eldre protokoller og bred eksponering eksisterer. Håndheving av MFA på RDG-autentiseringstrinnet blokkerer de fleste vanlige angrep og øker dramatisk kostnadene for målrettet inntrenging.

For internettvendt RDP er de dominerende risikoene gjenbruk av passord, brute-force-forsøk, token-replay og sesjonskapring via feilkonfigurert TLS. MFA motvirker disse ved å kreve en andre faktor som er motstandsdyktig mot gjenbruk av legitimasjon.

Mange rammeverk—NIST 800-63, ISO/IEC 27001-kontroller og ulike cybersikringsstandarder—forventer implisitt eller eksplisitt MFA på fjernaksess Implementering av MFA på RDG tilfredsstiller både kontrollintensjon og revisorforventninger uten å omstrukturere leveringsstakken din.

Hvordan MFA passer inn i RD Gateway-arkitekturen?

Kontrollplanet er enkelt: brukeren starter RDP gjennom RDG; RDG sender autentisering til NPS over RADIUS; NPS vurderer policy og aktiverer MFA-leverandøren; ved suksess returnerer NPS Access-Accept og RDG fullfører tilkoblingen. Autorisasjon til interne ressurser styres fortsatt av RD CAP/RD RAP, så identitetsbekreftelse er tillegg fremfor forstyrrende.

• Autentiseringsflyt og beslutningspunkter
• UX-hensyn for eksterne brukere

Autentiseringsflyt og beslutningspunkter

Nøkkelbeslutningspunkter inkluderer hvor MFA-logikken kjører (NPS med Entra MFA-utvidelsen eller en tredjeparts RADIUS-proxy), hvilke faktorer som er tillatt, og hvordan feil håndteres. Å sentralisere beslutninger om NPS forenkler revisjon og endringskontroll. For store eiendommer, vurder et dedikert NPS-par for å skille policyvurdering fra RDG-kapasitet og for å forenkle vedlikeholdsvinduer.

UX-hensyn for eksterne brukere

Push- og app-baserte varsler gir den mest pålitelige opplevelsen i den RDP credential flow. SMS og tale kan feile der det ikke finnes noen sekundær prompt UI. Utdann brukerne om forventede prompt, tidsavbrudd og avvisningsgrunner for å redusere supportbilletter. I høy-latens regioner, forleng utfordringens tidsavbrudd moderat for å unngå falske feil uten å skjule ekte misbruk.

Hva er sjekklisten for forutsetninger?

En ren oppsett begynner med verifiserte plattformroller og identitetshygiene. Sørg for at RDG er stabil på en støttet Windows Server og planlegg en tilbakestillingsbane. Bekreft kataloggrupper for å avgrense brukeradgang og valider at administratorer kan skille mellom policyendringer og sertifikat- eller nettverksproblemer.

• Roller, porter og sertifikater
• Katalog- og identitetsberedskap

Roller, porter og sertifikater

Distribuer NPS-rollen på en server med pålitelig AD-tilkobling. Standardiser på RADIUS UDP 1812/1813 og dokumentere eventuell bruk av 1645/1646. På RDG, installer et offentlig betrodd TLS-sertifikat for HTTPS-lytteren og fjern svake protokoller og krypteringsmetoder. Registrer delte hemmeligheter i et hvelv, ikke i en billett eller skrivebordsnotat.

Katalog- og identitetsberedskap

Opprett dedikerte AD-grupper for RDG-godkjente brukere og administratorer; unngå "Domenebrukere" omfang. Bekreft at brukerne er registrert i MFA hvis du bruker Entra ID. For tredjepartsleverandører, synkroniser identiteter og test en pilotbruker fra ende til ende før bred registrering. Juster brukernavnsformater (UPN vs sAMAccountName) mellom RDG, NPS og MFA-plattformen for å unngå stille uoverensstemmelser.

Hva er trinn-for-trinn-konfigurasjonen av MFA for RD Gateway?

• Installer og registrer NPS
• Legg til RD Gateway som en RADIUS-klient
• Opprett NPS-retningslinjer (CRP & NP)
• Installer MFA-utvidelse eller tredjepartsagent
• Pek RD Gateway til Central NPS (RD CAP Store)
• Test MFA End-to-End

Steg 1 — Installer og registrer NPS

Installer rollen for nettverkspolicy og tilgangstjenester, åpne nps.msc , og registrer NPS i Active Directory slik at det kan lese brukerattributter. Bekreft den Nettverkspolicyserver (IAS) tjenesten kjører og at serveren kan nå en domenekontroller med lav latens. Merk NPS FQDN/IP for logger og retningslinjer.

Valgfri kommandoer:

Install-WindowsFeature NPAS -IncludeManagementTools nps.msc

Kjør netsh nps legg til registrert server

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

Trinn 2 — Legg til RD Gateway som en RADIUS-klient

I RADIUS-klienter, legg til RD Gateway-en din med IP/FQDN, sett et vennlig navn (f.eks., RDG01 ), og bruk en hvelvet, lang delt hemmelighet. Åpne UDP 1812/1813 på NPS-serveren og bekreft tilgjengelighet. Hvis du kjører flere RDG-er, legg til hver enkelt eksplisitt (subnettd definisjoner er mulig, men lettere å feiltolke).

Valgfri kommandoer

Legg til en klient: 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

Steg 3 — Opprett NPS-retningslinjer (CRP & NP)

Opprett en tilkoblingsforespørselspolicy som er avgrenset til din RDG-klient IPv4-adresse. Velg Autentiser på denne serveren (for Microsoft Entra MFA via NPS-utvidelsen) eller Videreformidle til ekstern RADIUS (for en tredjeparts MFA-proxy). Opprett deretter en nettverkspolicy som inkluderer din AD-gruppe(r) (f.eks., GRP_RDG_Users ) med tilgang gitt. Sørg for at begge retningslinjene ligger over generelle regler.

Valgfri kommandoer

# Bekreft at en bruker er i den tillatte gruppen
Get-ADUser user1 -Properties memberOf |
  Select-Object -ExpandProperty memberOf |
  Where-Object { $_ -like "*GRP_RDG_Users*" }

Eksportpolitikk oversikt for referanse: reg export "HKLM\SYSTEM\CurrentControlSet\Services\IAS\Policy" C:\NPS-Policy.reg /y

Steg 4 — Installer MFA-utvidelse eller tredjepartsagent

For Microsoft Entra MFA, installer NPS-utvidelsen, kjør skriptet for leietakerbinding, og start NPS på nytt. Bekreft at brukerne er MFA-registrert og foretrekker push/app-metoder. For tredjeparts MFA, installer leverandørens RADIUS-proxy/agent, konfigurer endepunkter/delte hemmeligheter, og pek CRP-en din mot den eksterne gruppen.

Valgfri kommandoer

# Entra MFA NPS-utvidelse bind  
Sett-sted "C:\Program Files\Microsoft\AzureMfa\"  
.\AzureMfaNpsExtnConfigSetup.ps1  
Start tjeneste IAS

# Nyttig loggingsknott (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 ekstern 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"

Steg 5 — Pek RD Gateway til sentral NPS (RD CAP Store)

På RD Gateway-serveren, sett RD CAP Store til sentralserver som kjører NPS, legg til NPS-vert + delt hemmelighet, og verifiser tilkoblingen. Juster RD CAP til dine tillatte brukergruppe(r) og RD RAP til de spesifikke datamaskinene/samlingene. Hvis MFA lykkes, men tilgang mislykkes, sjekk først RAP-omfanget.

Trinn 6 — Test MFA fra ende til ende

Fra en ekstern klient, koble til gjennom RDG til en kjent vert og bekreft ett MFA-prompt, NPS 6272 (Tilgang gitt), og en vellykket økt. Test også negative stier (ikke i gruppe, ikke registrert, feil faktor, utløpt token) for å validere feilklarhet og støtteberedskap.

Hva er feilsøkingshåndboken for MFA for RD Gateway?

Feilsøking går raskest når du skiller mellom nettverk, policy og identitetslag. Start med RADIUS tilgjengelighet og portkontroller, deretter valider policy samsvar, og til slutt gjennomgå MFA registrering og faktortyper. Hold en testkonto med kontrollerte forhold slik at du kan gjenskape resultater konsekvent under endringsvinduer.

• Ingen oppfordring, sløyfer eller tidsavbrudd
• Policy Matching & Group Scope
• Logging og telemetri du faktisk vil bruke
• Sikkerhetsforsterkning og driftsbeste praksis
• Perimeter, TLS og minst privilegium
• Overvåking, varsling og endringskontroll
• Motstandsdyktighet og gjenoppretting

Ingen oppfordring, sløyfer eller tidsavbrudd

Ingen ledetekst indikerer ofte policy-rekkefølge eller MFA-registreringsgap. Løkker antyder at det er en mismatch i delt hemmelighet eller videresending av rekursjon mellom NPS og en proxy. Tidsavbrudd peker vanligvis på blokkert UDP 1812/1813, asymmetrisk ruting, eller altfor aggressiv IDS/IPS-inspeksjon. Øk loggverbet midlertidig for å bekrefte hvilken hopp som feiler.

Policy Matching & Group Scope

Bekreft at tilkoblingsforespørselpolicyen retter seg mot RDG-klienten og treffer før noen fellesregel. I nettverkspolicyen, bekreft den nøyaktige AD-gruppen og gruppenestingoppførselen; noen miljøer krever tiltak mot tokenoppblåsing eller direkte medlemskap. Vær oppmerksom på problemer med kanonalisering av brukernavn mellom UPN og NT-stilnavn.

Logging og telemetri du faktisk vil bruke

Bruk NPS Accounting for korrelasjon og hold RDG operasjonelle logger aktivert. Fra din MFA-plattform, gjennomgå per-bruker varsler, avslag og geo/IP-mønstre. Etabler et lett dashboard: autentiseringsvolum, feilrate, topp årsaker til feil og gjennomsnittlig utfordringstid. Disse målingene veileder både kapasitet og sikkerhet justering.

Sikkerhetsforsterkning og driftsbeste praksis

MFA er nødvendig, men ikke tilstrekkelig. Kombiner det med nettverkssegmentering, moderne TLS, minste privilegium og sterk overvåking. Hold en kort, håndhevet basislinje—herding fungerer bare hvis det brukes konsekvent og verifiseres etter oppdateringer og oppgraderinger.

Perimeter, TLS og minst privilegium

Plasser RDG i et herdet DMZ-segment med kun nødvendige flyt inn i LAN. Bruk et pålitelig offentlig sertifikat på RDG og deaktiver eldre. TLS og svake krypteringer. Begrens RDG-tilgang via dedikerte AD-grupper; unngå brede rettigheter og sørg for at RD RAP-er kun kartlegger de systemene og portene brukerne faktisk trenger.

Overvåking, varsling og endringskontroll

Varsel om topper i mislykkede autentiseringer, uvanlige geografier eller gjentatte forespørsel per bruker. Loggfør konfigurasjonsendringer på NPS, RDG og MFA-plattformen med en godkjenningshistorikk. Behandle retningslinjer som kode: spor endringer i kildekontroll eller i det minste i et endringsregister, og test i et staging-miljø før produksjonsovergang.

Motstandsdyktighet og gjenoppretting

Kjør NPS redundantly og konfigurer RDG til å referere til flere RADIUS-servere. Dokumenter fail-open vs fail-closed oppførsel for hver komponent; standardiser til fail-closed for ekstern tilgang. Ta sikkerhetskopi av NPS-konfigurasjon, RDG-policyer og MFA-innstillinger; øv på gjenoppretting, inkludert sertifikatbytte og re-registrering av MFA-utvidelsen eller agenten etter en ombygging.

Konklusjon

Å legge til MFA til RD Gateway lukker det største gapet i internettvendt RDP: misbruk av legitimasjoner. Ved å sentralisere policyen på NPS og integrere Entra MFA eller en tredjeparts RADIUS-leverandør, håndhever du sterk identitetsbekreftelse uten å forstyrre RD CAP/RD RAP-modeller. Valider med målrettede tester, overvåk kontinuerlig, og kombiner MFA med herdet TLS, minste privilegium og robust NPS/RDG-design.