Cum să configurați MFA pentru RD Gateway: Arhitectură, pași și cele mai bune practici

Introducere

Gateway-ul Remote Desktop (RD Gateway) securizează RDP prin HTTPS, dar parolele singure nu pot opri phishing-ul, umplerea de acreditive sau atacurile de forță brută. Adăugarea Autentificării Multi-Factor (MFA) închide această lacună prin verificarea identității utilizatorului înainte de stabilirea unei sesiuni. În acest ghid, veți învăța cum se integrează MFA cu RD Gateway și NPS, pașii exacți de configurare și sfaturile operaționale care mențin desfășurarea dvs. fiabilă la scară.

De ce RD Gateway are nevoie de MFA?

RD Gateway centralizează și auditează acces la distanță , dar nu poate neutraliza singură acreditivele furate. Umplerea acreditivelor și phishingul ocolesc în mod obișnuit apărările cu un singur factor, mai ales acolo unde există protocoale vechi și expunere largă. Aplicarea MFA la nivelul de autentificare RDG blochează cele mai multe atacuri comune și crește dramatic costul intruziunii țintite.

Pentru RDP expus pe internet, riscurile dominante sunt reutilizarea parolelor, încercările de forță brută, redarea token-urilor și preluarea sesiunilor prin TLS configurat greșit. MFA contracarează aceste riscuri prin cerința unui al doilea factor rezistent la redarea acreditivelor.

Multe cadre—NIST 800-63, controalele ISO/IEC 27001 și diverse baze de referință pentru asigurarea cibernetică—se așteaptă implicit sau explicit la MFA pe acces la distanță Implementarea MFA pe RDG satisface atât intenția de control, cât și așteptările auditorilor, fără a re-arhitectura stiva de livrare.

Cum se integrează MFA în arhitectura RD Gateway?

Planul de control este simplu: utilizatorul lansează RDP prin RDG; RDG trimite autentificarea către NPS prin RADIUS; NPS evaluează politica și invocă furnizorul MFA; la succes, NPS returnează Access-Accept și RDG finalizează conexiunea. Autorizația pentru activele interne este în continuare guvernată de RD CAP/RD RAP, astfel că dovedirea identității este aditivă mai degrabă decât disruptivă.

• Flux de autentificare și puncte de decizie
• Considerații UX pentru utilizatorii la distanță

Flux de autentificare și puncte de decizie

Punctele cheie de decizie includ locul în care rulează logica MFA (NPS cu extensia Entra MFA sau un proxy RADIUS de terță parte), ce factori sunt permisi și cum sunt gestionate eșecurile. Centralizarea deciziilor pe NPS simplifică auditul și controlul modificărilor. Pentru proprietăți mari, luați în considerare un set dedicat de NPS pentru a decupla evaluarea politicii de capacitatea RDG și pentru a simplifica feronizarea întreținere.

Considerații UX pentru utilizatorii la distanță

Notificările bazate pe aplicații oferă cea mai fiabilă experiență în cadrul RDP flux de acreditive. SMS și vocea pot eșua acolo unde nu există o interfață de utilizare secundară pentru solicitări. Educați utilizatorii cu privire la solicitările așteptate, timpii de expirare și motivele de refuz pentru a reduce tichetele de suport. În regiunile cu latență mare, extindeți modest timpii de expirare pentru provocări pentru a evita eșecurile false fără a masca abuzurile reale.

Ce este lista de verificare a cerințelor preliminare?

O configurare curată începe cu roluri de platformă verificate și igienă a identității. Asigurați-vă că RDG este stabil pe un Windows Server suportat și planificați o cale de revenire. Confirmați grupurile de director pentru a delimita accesul utilizatorilor și validați că administratorii pot distinge modificările de politică de problemele de certificat sau rețea.

• Roluri, Porturi și Certificate
• Pregătirea pentru Director și Identitate

Roluri, Porturi și Certificate

Implementați rolul NPS pe un server cu conectivitate AD fiabilă. Standardizați pe RADIUS UDP 1812/1813 și documentați orice utilizare moștenită 1645/1646. Pe RDG, instalați un certificat TLS de încredere public pentru ascultătorul HTTPS și eliminați protocoalele și cifrurile slabe. Înregistrați secretele partajate într-un seif, nu într-un bilet sau notă pe desktop.

Pregătirea pentru Director și Identitate

Creează grupuri AD dedicate pentru utilizatorii și administratorii autorizați RDG; evită domeniul „Utilizatori de domeniu”. Verifică dacă utilizatorii sunt înregistrați în MFA dacă folosești Entra ID. Pentru furnizorii terți, sincronizează identitățile și testează un utilizator pilot de la început până la sfârșit înainte de înrolarea pe scară largă. Aliniază formatele numelui de utilizator (UPN vs sAMAccountName) între RDG, NPS și platforma MFA pentru a evita nepotrivirile silențioase.

Care este configurația pas cu pas a MFA pentru RD Gateway?

• Instalați și înregistrați NPS
• Adăugați RD Gateway ca un client RADIUS
• Creează politici NPS (CRP și NP)
• Instalați extensia MFA sau agentul terț.
• Indicați RD Gateway către NPS Central (RD CAP Store)
• Test MFA End-to-End

Pasul 1 — Instalați și înregistrați NPS

Instalați rolul Serviciilor de Politică de Rețea și Acces, deschideți nps.msc , și înregistrează NPS în Active Directory pentru a putea citi atributele utilizatorului. Verifică Server de Politică de Rețea Serviciul (IAS) este activ și serverul poate accesa un controler de domeniu cu latență scăzută. Rețineți FQDN/IP NPS pentru jurnale și politici.

Comenzi opționale:

Instalați-WindowsFeature NPAS -IncludeManagementTools nps.msc

Rulare netsh nps adaugă server înregistrat

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

Pasul 2 — Adăugați RD Gateway ca un client RADIUS

În clienții RADIUS, adăugați gateway-ul RD prin IP/FQDN, setați un nume prietenos (de exemplu, RDG01 ), și folosiți un secret comun lung și criptat. Deschideți UDP 1812/1813 pe serverul NPS și confirmați accesibilitatea. Dacă rulați mai multe RDG-uri, adăugați fiecare explicit (definițiile de subrețea sunt posibile, dar mai ușor de greșit).

Comenzi opționale

Adăugați un client: netsh nps add client name="RDG01" address=10.0.10.20 sharedsecret="VeryLongVaultedSecret" vendor=standard enable=DA

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

Pasul 3 — Creați politici NPS (CRP și NP)

Creează o politică de solicitare a conexiunii limitată la adresa IPv4 a clientului tău RDG. Alege Autentificare pe acest server (pentru Microsoft Entra MFA prin extensia NPS) sau Redirecționează către RADIUS la distanță (pentru un proxy MFA de la terți). Apoi, creează o politică de rețea care include grupul(t) tău AD (de exemplu, GRP_RDG_Users ) cu acces acordat. Asigurați-vă că ambele politici se află deasupra regulilor generale.

Comenzi opționale

# Verificați dacă un utilizator se află în grupul permis
Get-ADUser user1 -Properties memberOf |
  Select-Object -ExpandProperty memberOf |
  Where-Object { $_ -like "*GRP_RDG_Users*" }

Politica de export pentru referință: reg export "HKLM\SYSTEM\CurrentControlSet\Services\IAS\Policy" C:\NPS-Policy.reg /y

Pasul 4 — Instalați extensia MFA sau agentul terț.

Pentru Microsoft Entra MFA, instalați extensia NPS, rulați scriptul de legare a chiriașului și reporniți NPS. Confirmați că utilizatorii sunt înregistrați pentru MFA și preferă metodele push/aplicație. Pentru MFA de la terți, instalați proxy-ul/agentul RADIUS al furnizorului, configurați punctele finale/secretele partajate și direcționați CRP-ul dvs. către acel grup remote.

Comenzi opționale

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

# Utilizarea utilă a jurnalizării (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

Configurează un grup și un server RADIUS la distanță: netsh nps add remoteradiusservergroup name="MFA-VENDOR"
netsh nps add remoteradiusserver name="MFA-VENDOR" address=10.0.20.50 authport=1812 sharedsecret="AnotherVaultedSecret"

Pasul 5 — Indicați RD Gateway către NPS Central (Magazin RD CAP)

Pe serverul RD Gateway, setați RD CAP Store la serverul central care rulează NPS, adăugați gazda NPS + secretul partajat și verificați conectivitatea. Aliniați RD CAP la grupul de utilizatori permis(e) și RD RAP la computerele/colecțiile specifice. Dacă MFA reușește, dar accesul eșuează, verificați mai întâi domeniul RAP.

Pasul 6 — Testați MFA de la început până la sfârșit

De la un client extern, conectați-vă prin RDG la un gazdă cunoscută și confirmați un prompt MFA, NPS 6272 (Acces acordat) și o sesiune reușită. De asemenea, testați căile negative (nu în grup, nu înscris, factor greșit, token expirat) pentru a valida claritatea erorilor și pregătirea suportului.

Ce este Manualul de depanare MFA pentru RD Gateway?

Depanarea este cea mai rapidă atunci când separi straturile de rețea, politică și identitate. Începe cu verificarea accesibilității RADIUS și a porturilor, apoi validează potrivirea politicii, apoi revizuiește înscrierea MFA și tipurile de factori. Păstrează un cont de test cu condiții controlate pentru a putea reproduce rezultatele în mod constant în timpul ferestrelor de schimbare.

• Fără solicitări, bucle sau expirări de timp
• Potrivirea politicii și domeniul grupului
• Jurnalizare și Telemetrie pe care o vei folosi cu adevărat
• Practici de bază pentru întărirea securității și operațiuni
• Perimetrul, TLS și Cel mai Mic Privilegiu
• Monitorizare, Alertare și Control al Schimbărilor
• Reziliență și Recuperare

Fără solicitări, bucle sau expirări de timp

Lipsa promptului indică adesea lacune în ordinea politicii sau înregistrarea MFA. Buclele sugerează o nepotrivire a secretului partajat sau o recursie de redirecționare între NPS și un proxy. Timpul de așteptare indică de obicei UDP 1812/1813 blocat, rutare asimetrică sau inspecție IDS/IPS prea agresivă. Creșteți temporar verbozitatea jurnalizării pentru a confirma care salt eșuează.

Potrivirea politicii și domeniul grupului

Confirmarea politicii de cerere de conexiune vizează clientul RDG și se aplică înainte de orice regulă generală. În politica de rețea, verificați grupul AD exact și comportamentul de imbricare a grupurilor; unele medii necesită atenuarea umflării token-ului sau apartenența directă. Fiți atenți la problemele de canonizare a numelui de utilizator între UPN și numele de stil NT.

Jurnalizare și Telemetrie pe care o vei folosi cu adevărat

Utilizați NPS Accounting pentru corelare și mențineți jurnalele operaționale RDG activate. Din platforma dvs. MFA, revizuiți solicitările, refuzurile și modelele geo/IP pe utilizator. Stabiliți un tablou de bord ușor: volumul de autentificare, rata de eșec, cele mai frecvente motive de eșec și timpul mediu de provocare. Aceste metrici ghidează atât capacitatea, cât și securitate tuning.

Practici de bază pentru întărirea securității și operațiuni

MFA este necesar, dar nu suficient. Combinați-l cu segmentarea rețelei, TLS modern, privilegiul minim și monitorizarea puternică. Mențineți o bază de referință scurtă, impusă - întărirea funcționează doar dacă este aplicată constant și verificată după actualizări și upgrade-uri.

Perimetrul, TLS și Cel mai Mic Privilegiu

Plasați RDG într-un segment DMZ întărit cu doar fluxurile necesare în LAN. Utilizați un certificat public de încredere pe RDG și dezactivați moștenirea. TLS și cifre slabe. Restricționați accesul RDG prin grupuri AD dedicate; evitați drepturile largi și asigurați-vă că RD RAP-urile mapează doar sistemele și porturile de care au nevoie efectiv utilizatorii.

Monitorizare, Alertare și Control al Schimbărilor

Alertă cu privire la vârfuri în autentificările eșuate, geografii neobișnuite sau solicitări repetate per utilizator. Înregistrați modificările de configurare pe NPS, RDG și platforma MFA cu un traseu de aprobat. Tratați politicile ca pe un cod: urmăriți modificările în controlul sursei sau cel puțin într-un registru de modificări și testați într-un mediu de testare înainte de trecerea în producție.

Reziliență și Recuperare

Rulați NPS redundant și configurați RDG pentru a face referire la mai multe servere RADIUS. Documentați comportamentul fail-open vs fail-closed pentru fiecare componentă; setați implicit fail-closed pentru accesul extern. Faceți backup la configurația NPS, politicile RDG și setările MFA; repetați recuperarea, inclusiv înlocuirea certificatului și reînregistrarea extensiei sau agentului MFA după o reconstrucție.

Concluzie

Adăugarea MFA la RD Gateway închide cea mai mare lacună în RDP-ul expus pe internet: abuzul de acreditive. Prin centralizarea politicii pe NPS și integrarea Entra MFA sau a unui furnizor RADIUS terț, impui o dovadă puternică a identității fără a perturba modelele RD CAP/RD RAP. Validează cu teste țintite, monitorizează continuu și asociază MFA cu TLS întărit, privilegii minime și un design NPS/RDG rezistent.