Qasje VPN pa të drejta desktopi në distancë: katër porta të veçanta

Një përdorues lidhet me VPN, hap një ndarje skedarësh dhe një aplikacion të brendshëm, dhe më pas një përpjekje RDP kthen «llogaria e përdoruesit nuk është e autorizuar për hyrje në distancë». Në atë mesazh nuk ka asgjë të gabuar me tunelin. Katër porta të pavarura qëndrojnë midis një llogarie VPN dhe një desktopi interaktiv, dhe vetëm e fundit e prodhoi atë. Njerëzit zakonisht përgjigjen duke shtuar llogarinë te Administrators, gjë që jep shumë më tepër se desktopi dhe nuk e rregullon portën nëse politika e grupit e refuzon. Ja çfarë bën në të vërtetë secila portë dhe si të ndryshohet vetëm ajo që refuzon.

Katër porta në një rend fiks

Porta së pari vendos nëse identiteti mund të krijojë fare një tunel: një politikë RADIUS, një kusht grupi, një kontroll certifikate, një leje Access Server. Më pas rrugëtimi dhe firewall-et vendosin nëse paketa nga pishina e tunelit arrin dëgjuesin TCP 3389 të destinacionit. Më pas shtrëngimi i duarve NLA i klientit vërteton llogarinë ndaj destinacionit. Vetëm pas këtyre tre, autoriteti lokal i sigurisë kontrollon nëse llogaria ka të drejtën e hyrjes që kërkon një sesion interaktiv në distancë.

Meqenëse rendi është fiks, secila portë fsheh ato pas saj. Një tunel i dështuar nuk thotë asgjë për rrugëtimin; një portë e bllokuar nuk thotë asgjë për të drejtën e hyrjes; një test porte i suksesshëm nuk thotë asgjë për pranimin. Kjo është arsyeja pse «VPN-ja funksionon, por RDP-ja jo» nuk është një problem i vetëm, por një kufi midis dy prej këtyre portave, dhe pse teksti i gabimit është mënyra më e shpejtë për të kuptuar në cilën u përplasët.

E drejta që e refuzon sesionin në të vërtetë

Hyrja në desktopin në distancë kërkon të drejtën e përdoruesit Lejo hyrjen përmes Shërbimeve të Desktopit në Distancë, SeRemoteInteractiveLogonRight. Ajo kontrollohet në hyrje, jo gjatë ngritjes së tunelit, prandaj një llogari mund të shfletojë rrjetin për orë të tëra dhe gjithsesi t'i refuzohet një desktop. Dialogu që e shfaq ndodhet te Politikat lokale, Caktimi i të drejtave të përdoruesit, dhe ekuivalenti i domenit ndodhet në një GPO.

Anëtarësia e paracaktuar varet nga roli i makinës: stacionet e punës dhe serverët anëtarë e japin atë te Administrators dhe Remote Desktop Users, ndërsa një kontrollues domeni e jep vetëm te Administrators. Ky fakt i vetëm shpjegon pjesën më të madhe të konfuzionit, sepse e njëjta llogari ka sukses në një server skedarësh dhe dështon në një DC. E drejta e mohimit e mund të drejtën e lejimit përkatës pavarësisht anëtarësisë në grup, kështu që një llogari që ka njëkohësisht leje dhe mohim mohohet. Një grup i gjerë mohimi mund të kapë një administrator të shtuar si nder.

Lexoni politikën efektive, jo dialogun lokal

Politika lokale zëvendësohet nga çdo GPO domeni që përcakton të njëjtën të drejtë, kështu që snap-in-i lokal mund të shfaqë një listë që duket e saktë ndërsa gjendja efektive është e ndryshme. Eksportoni atë që makina zbaton në të vërtetë, më pas kërkoni të drejtën dhe lexoni SID-të në vend të emrave të shfaqur:

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

Në atë dalje, *S-1-5-32-544 është Administrators dhe *S-1-5-32-555 është Remote Desktop Users.

Nëse nuk shfaqet asnjëra, askush përveç mbajtësit të politikës nuk mund të hapë një desktop, çfarëdo që sugjeron dialogu lokal i Përdoruesve dhe Grupeve. Atëherë gpresult emërton GPO-në që fitoi, dhe ai është objekti që duhet të redaktoni; ndryshimi i politikës lokale në një makinë të bashkuar me domenin është test, jo rregullim.

Jepni të drejtën më të ngushtë që përshtatet

Përgjigja e zakonshme është grupi Remote Desktop Users në destinacion. Ai e mban të drejtën si parazgjedhje, është shumë më i vogël se Administrators dhe ndan «mund të hapë një desktop» nga «mund të administrojë serverin». Aty ku politika e ka ricaktuar të drejtën në mënyrë eksplicite, shtoni grupin ose llogarinë në atë politikë në vend që të shtoni një grup që askush nuk e kishte menduar si kontroll aksesi.

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

Kontrolloni listën e mohimeve përpara se të shtoni ndonjë gjë. Nëse një e drejtë mohimi emërton një grup që përmban përdoruesin, ndryshimi i saktë është heqja e llogarisë nga ai grup ose ngushtimi i mohimit, jo shtimi i një lejeje të dytë diku tjetër. Shënoni cilën të drejtë dhe ku e ndryshuat, sepse një përditësim i mëvonshëm i GPO-së do të rivendosë në heshtje gjendjen e mëparshme dhe tiketa do të rihapet me të njëjtin mesazh.

Mbani shtegun e rrjetit si vendim të veçantë

Grupi VPN nuk duhet të arrijë çdo portë. Kur një grup ka nevojë për një aplikacion dhe jo për një desktop, një rregull firewall i kufizuar në pishinën e tunelit dhe portën e aplikacionit i jep efekt asaj politike, ndërsa e drejta e hyrjes mbetet e paprekur.

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

Konfigurimi për klient i OpenVPN dhe lejet e grupit të Access Server mund të kufizojnë prefikset e destinacionit në të njëjtën frymë; asnjëra nuk jep një të drejtë hyrjeje Windows, dhe një e drejtë hyrjeje nuk mund të hapë një portë. Mbani në dritare ndryshimi të veçanta, sepse një rregull porte dhe një e drejtë miratohen nga njerëz të ndryshëm.

Verifikoni në të njëjtin rend në të cilin zbatohen portat: a mundet llogaria të krijojë tunelin, a arrin sesioni dëgjuesin, a vërtetohet klienti dhe a e ka llogaria të drejtën. Një ping që dështon ndërsa testi i portës ka sukses është një firewall që përgjigjet ndryshe ndaj ICMP, jo provë që RDP-ja është e bllokuar. Referenca e Microsoft për të drejtën e hyrjes liston parazgjedhjet sipas rolit të makinës dhe rregullin që mohimi mund lejimin.