VPN-hozzáférés távoliasztal-jogosultság nélkül: négy külön kapu

Egy felhasználó csatlakozik a VPN-hez, megnyit egy fájlmegosztást és egy belső alkalmazást, majd egy RDP-próbálkozás azt adja vissza: „a felhasználói fiók nem jogosult a távoli bejelentkezésre”. Ebben az üzenetben semmi sem hibás az alagúttal kapcsolatban. Négy független kapu áll egy VPN-fiók és egy interaktív asztal között, és csak az utolsó produkálta. Az emberek általában úgy reagálnak, hogy hozzáadják a fiókot az Administrators csoporthoz, ami sokkal többet ad az asztalnál, és nem javítja a kaput, ha a csoportházirend megtagadja. Íme, mit tesz valójában az egyes kapuk, és hogyan módosítható csak az, amelyik elutasít.

Négy kapu rögzített sorrendben

Az átjáró először eldönti, hogy az identitás egyáltalán létrehozhat-e alagutat: RADIUS-szabályzat, csoportfeltétel, tanúsítvány-ellenőrzés, Access Server-engedély. Utána az útválasztás és a tűzfalak döntik el, hogy az alagútmedencéből érkező csomag eléri-e a cél TCP 3389-es figyelőjét. Utána az ügyfél NLA-kézfogása hitelesíti a fiókot a céllal szemben. Csak e három után ellenőrzi a helyi biztonsági hatóság, hogy a fiók rendelkezik-e azzal a bejelentkezési joggal, amelyet egy interaktív távoli munkamenet megkövetel.

Mivel a sorrend rögzített, minden kapu elrejti a mögötte lévőket. Egy sikertelen alagút semmit sem mond az útválasztásról; egy blokkolt port semmit sem mond a bejelentkezési jogról; egy sikeres portteszt semmit sem mond a beengedésről. Ezért a „a VPN működik, de az RDP nem” nem egyetlen probléma, hanem határvonal e kapuk közül kettő között, és ezért a hibaüzenet a leggyorsabb módja annak megállapítására, melyikbe ütközött.

A jog, amely valóban elutasítja a munkamenetet

A távoliasztal-bejelentkezéshez a Távoli asztali szolgáltatásokon keresztüli bejelentkezés engedélyezése felhasználói jog, azaz SeRemoteInteractiveLogonRight szükséges. Ezt bejelentkezéskor ellenőrzik, nem az alagút létrehozásakor, ezért egy fiók órákig böngészhet a hálózaton, és mégis megtagadhatják tőle az asztalt. A párbeszédablak, amely megjeleníti, a Helyi házirendek, Felhasználói jogok hozzárendelése alatt található, a tartományi megfelelője pedig egy GPO-ban.

Az alapértelmezett tagság a gép szerepétől függ: a munkaállomások és a tagkiszolgálók az Administrators és a Remote Desktop Users csoportnak adják meg, míg a tartományvezérlő csak az Administrators csoportnak. Ez az egyetlen tény magyarázza a zavar nagy részét, mert ugyanaz a fiók sikerül egy fájlkiszolgálón, és meghiúsul egy DC-n. A megtagadási jog a csoporttagságtól függetlenül felülmúlja a megfelelő engedélyezési jogot, így az a fiók, amelynek egyszerre engedélyezett és megtagadott, meg lesz tagadva. Egy széles megtagadási csoport elkaphat egy szívességből hozzáadott rendszergazdát.

A tényleges szabályzatot olvassa, ne a helyi párbeszédablakot

A helyi házirendet felülírja minden olyan tartományi GPO, amely ugyanazt a jogot definiálja, ezért a helyi snap-in helyesnek tűnő listát mutathat, miközben a tényleges állapot más. Exportálja, amit a gép valóban alkalmaz, majd keresse meg a jogot, és a megjelenített nevek helyett az SID-eket olvassa:

secedit /export /cfg C:\temp\secpol.cfg
Select-String -Path C:\temp\secpol.cfg -Pattern SeRemoteInteractiveLogonRight
gpresult /scope computer /v

Ebben a kimenetben a *S-1-5-32-544 az Administrators, a *S-1-5-32-555 pedig a Remote Desktop Users.

Ha egyik sem jelenik meg, senki sem nyithat asztalt a szabályzat tulajdonosán kívül, bármit is sugall a helyi Felhasználók és csoportok párbeszédablak. Ekkor a gpresult megnevezi a nyertes GPO-t, és azt az objektumot kell szerkesztenie; a helyi házirend módosítása tartományhoz csatlakoztatott gépen teszt, nem javítás.

A legszűkebb megfelelő jogot adja meg

A szokásos válasz a cél Remote Desktop Users csoportja. Alapértelmezés szerint ez hordozza a jogot, sokkal kisebb az Administrators csoportnál, és elválasztja a „megnyithat asztalt” a „kezelheti a kiszolgálót” lehetőségtől. Ahol a szabályzat kifejezetten újraosztotta a jogot, adja hozzá a csoportot vagy a fiókot ahhoz a szabályzathoz, ahelyett hogy olyan csoportot adna hozzá, amelyet senki sem szánt hozzáférés-vezérlésnek.

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "CORP\a.user"

A hozzáadás előtt ellenőrizze a megtagadási listát. Ha egy megtagadási jog olyan csoportot nevez meg, amely tartalmazza a felhasználót, a helyes módosítás a fiók eltávolítása abból a csoportból vagy a megtagadás szűkítése, nem pedig egy második engedély hozzáadása máshol. Jegyezze fel, melyik jogot és hol módosította, mert egy későbbi GPO-frissítés csendben visszaállítja az előző állapotot, és a jegy ugyanazzal az üzenettel nyílik újra.

A hálózati útvonal külön döntés maradjon

A VPN-csoportnak nem kell minden portot elérnie. Amikor egy csoportnak alkalmazásra van szüksége, nem asztalra, az alagútmedencére és az alkalmazás portjára korlátozott tűzfalszabály érvényt ad annak a szabályzatnak, miközben a bejelentkezési jog érintetlen marad.

Get-NetFirewallRule -DisplayGroup "Remote Desktop"
Test-NetConnection -ComputerName 10.20.0.50 -Port 3389

Az OpenVPN saját ügyfélenkénti konfigurációja és az Access Server csoportengedélyei ugyanabban a szellemben korlátozhatják a cél-előtagokat; egyik sem ad Windows-bejelentkezési jogot, és egy bejelentkezési jog nem nyithat portot. Tartsa őket külön módosítási ablakokban, mert a portszabályt és a jogot különböző emberek hagyják jóvá.

Ugyanabban a sorrendben ellenőrizze, ahogy a kapuk érvényesülnek: létrehozhatja-e a fiók az alagutat, eléri-e a munkamenet a figyelőt, hitelesít-e az ügyfél, és rendelkezik-e a fiók a joggal. Az a ping, amely sikertelen, miközben a portteszt sikeres, egy ICMP-re másként válaszoló tűzfal, nem annak bizonyítéka, hogy az RDP blokkolva van. A Microsoft bejelentkezési jogról szóló referenciája felsorolja a gépszerepenkénti alapértékeket és azt a szabályt, hogy a megtagadás felülírja az engedélyezést.