VPN-i juurdepääs ilma kaugtöölaua õigusteta: neli eraldi väravat

Kasutaja ühendub VPN-iga, avab failijagamise ja sisemise rakenduse ning siis tagastab RDP-katse „kasutajakontol ei ole lubatud kaugsisestamine“. Selles teates ei ole tunneliga midagi valesti. VPN-konto ja interaktiivse töölaua vahel on neli sõltumatut väravat ja selle põhjustas ainult viimane. Tavaliselt lisavad inimesed konto gruppi Administrators, mis annab palju enamat kui töölaud ega paranda väravat, kui rühmareegel seda keelab. Siin on, mida iga värav tegelikult teeb, ja kuidas muuta ainult seda, mis keeldub.

Neli väravat kindlas järjekorras

Lüüs otsustab esmalt, kas identiteet tohib üldse tunnelit luua: RADIUS-poliitika, rühmatingimus, sertifikaadikontroll, Access Serveri luba. Seejärel otsustavad marsruutimine ja tulemüürid, kas tunnelipõhjast tulev pakett jõuab sihtkoha TCP 3389 kuulajani. Seejärel autendib kliendi NLA käepigistus konto sihtkoha vastu. Alles pärast neid kolme kontrollib kohalik turbebüroo, kas kontol on sisselogimisõigus, mida interaktiivne kaugseanss nõuab.

Kuna järjekord on kindel, peidab iga värav enda taga olevaid. Ebaõnnestunud tunnel ei ütle midagi marsruutimise kohta; blokeeritud port ei ütle midagi sisselogimisõiguse kohta; edukas porditest ei ütle midagi lubamise kohta. Seetõttu ei ole „VPN töötab, aga RDP mitte“ üks probleem, vaid piir kahe sellise värava vahel, ja seetõttu on veatekst kiireim viis teada saada, millisega kokku puutusite.

Õigus, mis seansi tegelikult tagasi lükkab

Kaugtöölauale sisselogimine nõuab kasutajaõigust Luba sisselogimine kaugtöölauateenuste kaudu, SeRemoteInteractiveLogonRight. Seda kontrollitakse sisselogimisel, mitte tunneli loomisel, mistõttu võib konto tunde võrgus ringi liikuda ja ikkagi töölauale mitte pääseda. Dialoog, mis seda näitab, asub jaotises Kohalikud poliitikad, Kasutajaõiguste määramine, ja domeeni vaste on GPO-s.

Vaikimisi liikmelisus sõltub masina rollist: tööjaamad ja liikmiserverid annavad selle gruppidele Administrators ja Remote Desktop Users, samas kui domeenikontroller annab selle ainult grupile Administrators. See üks asjaolu seletab suurema osa segadusest, sest sama konto õnnestub failiserveris ja ebaõnnestub DC-s. Keelamisõigus võidab vastava lubamisõiguse sõltumata rühmaliikmelisusest, nii et konto, millele on korraga lubatud ja keelatud, keelatakse. Lai keelamisrühm võib tabada administraatorit, kes lisati vastutulekuna.

Lugege kehtivat poliitikat, mitte kohalikku dialoogi

Kohaliku poliitika kirjutab üle iga domeeni GPO, mis määratleb sama õiguse, mistõttu kohalik snap-in võib näidata õiget näivat loendit, samal ajal kui tegelik olek on teistsugune. Eksportige, mida masin tegelikult rakendab, seejärel otsige õigus ja lugege SID-e, mitte kuvatavaid nimesid:

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

Selles väljundis on *S-1-5-32-544 Administrators ja *S-1-5-32-555 Remote Desktop Users.

Kui kumbki ei ilmu, ei saa keegi peale poliitikaomaniku töölauda avada, ükskõik mida kohalik kasutajate ja rühmade dialoog soovitab. Siis nimetab gpresult GPO, mis võitis, ja see on objekt, mida peate redigeerima; kohaliku poliitika muutmine domeeniga liidetud masinas on test, mitte parandus.

Andke kitsaim sobiv õigus

Tavaline vastus on sihtkoha rühm Remote Desktop Users. See kannab õigust vaikimisi, on palju väiksem kui Administrators ja eraldab „tohib töölauda avada“ ja „tohib serverit hallata“. Kui poliitika on õiguse selgesõnaliselt ümber määranud, lisage rühm või konto sellele poliitikale, selle asemel et lisada rühm, mida keegi ei kavatsenud juurdepääsukontrolliks.

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

Enne millegi lisamist kontrollige keelamiste loendit. Kui keelamisõigus nimetab rühma, kuhu kasutaja kuulub, on õige muudatus konto sellest rühmast eemaldamine või keelamise kitsendamine, mitte teise lubamise lisamine mujale. Märkige üles, millist õigust ja kus muutsite, sest hilisem GPO värskendus taastab vaikselt varasema oleku ja pilet avaneb uuesti sama teatega.

Hoidke võrgutee eraldi otsusena

VPN-i rühm ei pea jõudma igasse porti. Kui rühm vajab rakendust, mitte töölauda, annab tunnelipõhja ja rakenduse pordiga piiratud tulemüürireegel sellele poliitikale jõu, samal ajal kui sisselogimisõigus jääb puutumata.

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

OpenVPN-i enda kliendipõhine konfiguratsioon ja Access Serveri rühmaload võivad sihtkoha eesliiteid samas vaimus piirata; kumbki neist ei anna Windowsi sisselogimisõigust ja sisselogimisõigus ei saa porti avada. Hoidke neid eraldi muudatusakendes, sest pordireegli ja õiguse kinnitavad erinevad inimesed.

Kontrollige samas järjekorras, nagu väravad kehtivad: kas konto saab tunneli luua, kas seanss jõuab kuulajani, kas klient autendib ja kas kontol on õigus. Ping, mis ebaõnnestub, kui porditest õnnestub, on tulemüür, mis vastab ICMP-le erinevalt, mitte tõestus, et RDP on blokeeritud. Microsofti sisselogimisõiguse viide loetleb vaikeväärtused masina rolli järgi ja reegli, et keeldumine võidab lubamise.