Hogyan állítsuk be az MFA-t az RD Gateway-hez: Architektúra, lépések és legjobb gyakorlatok

Bevezetés

A Remote Desktop Gateway (RD Gateway) az RDP-t HTTPS-en keresztül biztosítja, de a jelszavak önmagukban nem tudják megakadályozni a phishinget, a hitelesítő adatok töltögetését vagy a brute-force támadásokat. A Többtényezős Hitelesítés (MFA) hozzáadása bezárja ezt a rést azáltal, hogy ellenőrzi a felhasználó személyazonosságát, mielőtt a munkamenet létrejön. Ebben az útmutatóban megtudhatja, hogyan integrálódik az MFA az RD Gateway-jel és az NPS-sel, az pontos konfigurációs lépéseket, valamint azokat a működési tippeket, amelyek megbízhatóvá teszik a telepítését nagy léptékben.

Miért van szükség az RD Gateway-re MFA-ra?

RD Gateway központosítja és auditálja távoli hozzáférés , de önmagában nem tudja semlegesíteni a lopott hitelesítő adatokat. A hitelesítő adatok töltögetése és a phishing rendszeresen megkerüli az egyfaktoros védelmet, különösen ott, ahol elavult protokollok és széleskörű kitettség áll fenn. Az MFA érvényesítése az RDG hitelesítési szinten blokkolja a legtöbb általános támadást, és drámaian megemeli a célzott behatolás költségeit.

Az interneten elérhető RDP esetében a legfőbb kockázatok a jelszó újrahasználata, a brute-force kísérletek, a token újrajátszása és a session hijacking a nem megfelelően konfigurált TLS-en keresztül. Az MFA ezeket úgy ellensúlyozza, hogy második tényezőt követel meg, amely ellenáll a hitelesítő adatok újrajátszásának.

Sok keretrendszer—NIST 800-63, ISO/IEC 27001 ellenőrzések és különböző kiberbiztosítási alapok—implicit módon vagy kifejezetten elvárják a MFA-t. távoli hozzáférés Az MFA RDG-n történő megvalósítása mind a kontroll szándékát, mind a auditorok elvárásait kielégíti anélkül, hogy újra kellene tervezni a szállítási struktúráját.

Hogyan illeszkedik az MFA az RD Gateway architektúrába?

A vezérlő sík egyszerű: a felhasználó RDP-t indít RDG-n keresztül; az RDG hitelesítést küld az NPS-nek RADIUS-on keresztül; az NPS kiértékeli a politikát és meghívja az MFA szolgáltatót; siker esetén az NPS visszatér az Access-Accept-tal, és az RDG befejezi a kapcsolatot. A belső eszközökhöz való jogosultságot továbbra is az RD CAP/RD RAP szabályozza, így az identitásigazolás kiegészítő, nem pedig zavaró.

• Hitelesítési folyamat és döntési pontok
• UX szempontok távoli felhasználók számára

Hitelesítési folyamat és döntési pontok

A kulcsfontosságú döntési pontok közé tartozik, hogy hol fut a MFA logika (NPS az Entra MFA kiterjesztéssel vagy egy harmadik fél RADIUS proxy), mely tényezők engedélyezettek, és hogyan kezelik a hibákat. A döntések központosítása az NPS-en egyszerűsíti a auditálást és a változáskezelést. Nagy ingatlanok esetén érdemes egy dedikált NPS párt fontolóra venni, hogy elválassza a házirend értékelését az RDG kapacitásától, és egyszerűsítse a karbantartási időszakokat.

UX szempontok távoli felhasználók számára

A push- és alkalmazásalapú értesítések nyújtják a legmegbízhatóbb élményt a RDP hitelesítési folyamat. Az SMS és a hanghívás akkor hibásodhat meg, ha nincs másodlagos felhasználói felület. Oktassa a felhasználókat a várt felugró ablakokról, időkorlátokról és elutasítási okokról, hogy csökkentse a támogatási jegyeket. Magas késleltetésű területeken mérsékelten hosszabbítsa meg a kihívási időkorlátokat, hogy elkerülje a hamis hibákat anélkül, hogy elfedné a valódi visszaéléseket.

Mi a követelmények ellenőrzőlistája?

A tiszta beállítás a hitelesített platform szerepkörökkel és identitás-higiéniával kezdődik. Biztosítsa, hogy az RDG stabil legyen egy támogatott Windows Serveren, és tervezzen visszaállítási utat. Erősítse meg a könyvtári csoportokat a felhasználói hozzáférés korlátozásához, és ellenőrizze, hogy az adminisztrátorok meg tudják különböztetni a házirendváltozásokat a tanúsítvány- vagy hálózati problémáktól.

• Szerepek, Portok és Tanúsítványok
• Könyvtár és Identitás Készség

Szerepek, Portok és Tanúsítványok

Telepítse az NPS szerepkört egy megbízható AD kapcsolattal rendelkező szerverre. Standardizáljon RADIUS UDP 1812/1813 és dokumentálja a 1645/1646 örökségi használatot. Az RDG-n telepítsen egy nyilvánosan megbízható TLS tanúsítványt a HTTPS hallgatóhoz, és távolítsa el a gyenge protokollokat és titkosítókat. A megosztott titkokat egy trezorban rögzítse, ne jegyben vagy asztali megjegyzésben.

Könyvtár és Identitás Készség

Hozzon létre dedikált AD csoportokat az RDG által engedélyezett felhasználók és rendszergazdák számára; kerülje a "Domain Users" hatókört. Ellenőrizze, hogy a felhasználók be vannak-e jegyezve az MFA-ba, ha az Entra ID-t használja. Harmadik fél szolgáltatók esetén szinkronizálja az identitásokat, és teszteljen egy pilóta felhasználót végig, mielőtt széleskörű beiratkozásra kerülne sor. Igazítsa a felhasználónevek formátumát (UPN vs sAMAccountName) az RDG, NPS és az MFA platform között, hogy elkerülje a csendes eltéréseket.

Mi a lépésről lépésre történő konfigurálása az MFA-nak az RD Gateway-hez?

• NPS telepítése és regisztrálása
• Add RD Gateway-t RADIUS kliensként.
• NPS irányelvek létrehozása (CRP & NP)
• Telepítse az MFA kiterjesztést vagy a harmadik fél ügynökét
• Irányítsa a RD Gateway-t a Központi NPS-re (RD CAP Áruház)
• Teszt MFA Végponttól Végpontig

1. lépés — Telepítés és regisztráció NPS

Telepítse a Hálózati Szabályzat és Hozzáférési Szolgáltatások szerepkört, nyissa meg nps.msc és regisztrálja az NPS-t az Active Directory-ban, hogy olvashassa a felhasználói attribútumokat. Ellenőrizze a Hálózati Szabályzat Szerver (Az IAS) szolgáltatás fut, és a szerver képes elérni egy tartományvezérlőt alacsony késleltetéssel. Jegyezze fel az NPS FQDN/IP-t a naplókhoz és a szabályzatokhoz.

Opcionális parancsok:

Install-WindowsFeature NPAS -IncludeManagementTools nps.msc

Futtatás netsh nps add registeredserver

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

2. lépés — RD Gateway hozzáadása RADIUS kliensként

A RADIUS Kliensekben adja hozzá RD Gateway-jét IP/FQDN alapján, állítson be egy barátságos nevet (pl. RDG01 ), és használjon egy titkos, hosszú megosztott kulcsot. Nyissa meg az UDP 1812/1813 portot az NPS szerveren, és erősítse meg az elérhetőséget. Ha több RDG-t futtat, adja hozzá mindegyiket kifejezetten (a hálózati tartományok meghatározása lehetséges, de könnyebb tévesen beállítani).

Opcionális parancsok

Ügyfél hozzáadása: netsh nps add client name="RDG01" address=10.0.10.20 sharedsecret="VeryLongVaultedSecret" vendor=standard enable=IGEN

netsh advfirewall tűzfal szabály hozzáadása név="RADIUS Auth (UDP 1812)" irány=bemenet akció=engedélyezés protokoll=UDP helyiport=1812
netsh advfirewall tűzfal szabály hozzáadása név="RADIUS Acct (UDP 1813)" irány=bemenet akció=engedélyezés protokoll=UDP helyiport=1813

3. lépés — NPS irányelvek létrehozása (CRP és NP)

Hozzon létre egy kapcsolatkérelmi politikát, amely az RDG kliens IPv4 címére van korlátozva. Válassza az Azonosítás ezen a szerveren (Microsoft Entra MFA az NPS kiterjesztésen keresztül) vagy Továbbítás távoli RADIUS-ra (harmadik fél MFA proxy számára). Ezután hozzon létre egy hálózati politikát, amely tartalmazza az AD csoportját (pl. GRP_RDG_Felhasználók ) Hozzáférés engedélyezve. Biztosítsa, hogy mindkét irányelv a generikus szabályok felett helyezkedjen el.

Opcionális parancsok

# Ellenőrizze, hogy a felhasználó az engedélyezett csoportban van-e
Get-ADUser user1 -Properties memberOf |
  Select-Object -ExpandProperty memberOf |
  Where-Object { $_ -like "*GRP_RDG_Users*" }

Exportálási politika pillanatkép hivatkozásként: reg export "HKLM\SYSTEM\CurrentControlSet\Services\IAS\Policy" C:\NPS-Policy.reg /y

4. lépés — MFA kiterjesztés vagy harmadik fél ügynök telepítése

A Microsoft Entra MFA-hoz telepítse a NPS kiterjesztést, futtassa a bérlői kötési szkriptet, és indítsa újra az NPS-t. Ellenőrizze, hogy a felhasználók MFA-regisztráltak-e, és preferálják a push/app módszereket. Harmadik fél MFA esetén telepítse a szolgáltató RADIUS proxyját ügynökét, konfigurálja a végpontokat/megosztott titkokat, és irányítsa a CRP-t arra a távoli csoportra.

Opcionális parancsok

# Entra MFA NPS kiterjesztés kötés
Helyszín beállítása "C:\Program Files\Microsoft\AzureMfa\"
.\AzureMfaNpsExtnConfigSetup.ps1
Szolgáltatás újraindítása IAS

# Hasznos naplózási szabályzó (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

Konfiguráljon egy távoli RADIUS csoportot és szervert: netsh nps add remoteradiusservergroup name="MFA-VENDOR"
netsh nps add remoteradiusserver name="MFA-VENDOR" address=10.0.20.50 authport=1812 sharedsecret="AnotherVaultedSecret"

5. lépés — Az RD Gateway központi NPS-re (RD CAP Store) irányítása

A RD Gateway szerveren állítsa be az RD CAP Store-t a központi NPS-t futtató szerverre, adja hozzá az NPS hosztot + a megosztott titkot, és ellenőrizze a kapcsolódást. Igazítsa az RD CAP-t az engedélyezett felhasználói csoport(ok)hoz, és az RD RAP-t a konkrét számítógépek/kollekciókhoz. Ha az MFA sikeres, de a hozzáférés nem, először ellenőrizze a RAP hatókörét.

6. lépés — MFA végponttól végpontig tesztelése

Külső kliensből csatlakozzon RDG-n keresztül egy ismert gazdagéphez, és erősítse meg egy MFA értesítést, NPS 6272 (Hozzáférés engedélyezve), valamint egy sikeres munkamenetet. Tesztelje a negatív utakat is (nem a csoportban, nem beiratkozott, hibás tényező, lejárt token) az hibák világosságának és a támogatás készenlétének érvényesítése érdekében.

Mi az MFA hibaelhárító kézikönyve az RD Gateway-hez?

A hibaelhárítás a leggyorsabb, ha elkülöníted a hálózati, a politikai és az identitási rétegeket. Kezdj a RADIUS elérhetőségének és a portellenőrzéseknek a vizsgálatával, majd érvényesítsd a politikai egyezést, végül nézd át az MFA regisztrációt és a tényezőtípusokat. Tarts fenn egy tesztfiókot ellenőrzött körülmények között, hogy következetesen reprodukálni tudd az eredményeket a változási időszakok alatt.

• Nincs kérés, ciklusok vagy időkorlátok
• Politikai egyeztetés és csoportkör
• Használható naplózás és telemetria
• Biztonsági megerősítés és üzemeltetési legjobb gyakorlatok
• Perem, TLS és Legkisebb Jogosultság
• Monitoring, Értesítés és Változáskezelés
• Rugalmasság és helyreállítás

Nincs kérés, ciklusok vagy időkorlátok

A gyakori figyelmeztetések a házirend megrendelésére vagy az MFA regisztrációs hiányosságaira utalnak. A hurkok megosztott titkos eltérést vagy továbbítási rekurziót jeleznek az NPS és egy proxy között. Az időtúllépések általában a blokkolt UDP 1812/1813-ra, aszimmetrikus irányításra vagy túlságosan agresszív IDS/IPS ellenőrzésre utalnak. Ideiglenesen növelje a naplózási részletességet, hogy megerősítse, melyik ugrás hibás.

Politikai egyeztetés és csoportkör

A kapcsolatmegerősítő irányelv a RDG kliensre vonatkozik, és a bármilyen általános szabály előtt érvényesül. A hálózati irányelvben ellenőrizze a pontos AD csoportot és a csoportbeágyazási viselkedést; egyes környezetek tokenbővítési mérséklést vagy közvetlen tagságot igényelnek. Figyeljen a felhasználónév kanonizálási problémáira az UPN és az NT-stílusú nevek között.

Használható naplózás és telemetria

Használja az NPS számvitelt a korrelációhoz, és tartsa aktívan az RDG működési naplóit. Az MFA platformján ellenőrizze a felhasználónkénti kéréseket, elutasításokat és geo/IP mintákat. Hozzon létre egy könnyű irányítópultot: azonosítási mennyiség, hibaarány, legfőbb hibaokok és átlagos kihívási idő. Ezek a mutatók irányítják a kapacitást és biztonság hangolás.

Biztonsági megerősítés és üzemeltetési legjobb gyakorlatok

Az MFA szükséges, de nem elegendő. Kombinálja hálózati szegmentációval, modern TLS-sel, legkisebb jogosultsággal és erős megfigyeléssel. Tartson fenn egy rövid, érvényesített alapot - a megerősítés csak akkor működik, ha következetesen alkalmazzák és ellenőrzik a javítások és frissítések után.

Perem, TLS és Legkisebb Jogosultság

Helyezze az RDG-t egy megerősített DMZ szegmensbe, csak a LAN-ba szükséges áramlásokkal. Használjon megbízható nyilvános tanúsítványt az RDG-n, és tiltsa le a régi rendszereket. TLS és gyenge titkosítók. Korlátozza az RDG hozzáférést dedikált AD csoportokon keresztül; kerülje a széleskörű jogosultságokat, és biztosítsa, hogy az RD RAP-ok csak azokat a rendszereket és portokat térképezzék fel, amelyekre a felhasználóknak valóban szükségük van.

Monitoring, Értesítés és Változáskezelés

Értesítés a sikertelen hitelesítések, szokatlan földrajzi helyek vagy a felhasználónkénti ismételt kérések csúcsairól. A NPS, RDG és az MFA platform konfigurációs változásainak naplózása jóváhagyási nyomvonal mellett. A politikákat kódként kezelje: kövesse nyomon a változásokat forráskezelésben, vagy legalább egy változásnyilvántartásban, és tesztelje egy tesztkörnyezetben a termelési átállás előtt.

Rugalmasság és helyreállítás

Futtassa az NPS-t redundánsan, és konfigurálja az RDG-t, hogy több RADIUS szerverre hivatkozzon. Dokumentálja a fail-open és fail-closed viselkedést minden komponens esetében; alapértelmezés szerint legyen fail-closed a külső hozzáféréshez. Készítsen biztonsági másolatot az NPS konfigurációról, az RDG irányelvekről és az MFA beállításokról; gyakorolja a helyreállítást, beleértve a tanúsítvány cseréjét és az MFA kiterjesztés vagy ügynök újraregisztrálását az újratelepítés után.

Következtetés

A MFA hozzáadása az RD Gateway-hez bezárja az interneten elérhető RDP legnagyobb hiányosságát: a hitelesítő adatok visszaélését. A politika központosításával az NPS-en és az Entra MFA vagy egy harmadik fél RADIUS szolgáltató integrálásával erős identitás-ellenőrzést érvényesíthet anélkül, hogy megzavarná az RD CAP/RD RAP modelleket. Érvényesítse célzott tesztekkel, folyamatosan figyelje, és párosítsa az MFA-t a megerősített TLS-sel, a legkisebb jogosultsággal és a rugalmas NPS/RDG tervezéssel.