Acces VPN fără drepturi de desktop la distanță: patru porți separate

Un utilizator se conectează la VPN, deschide o partajare de fișiere și o aplicație internă, iar apoi o încercare RDP returnează „contul de utilizator nu este autorizat pentru autentificare la distanță”. În acel mesaj nu este nimic greșit cu tunelul. Patru porți independente stau între un cont VPN și un desktop interactiv, iar doar ultima l-a produs. Oamenii răspund de obicei adăugând contul la Administrators, ceea ce acordă mult mai mult decât desktopul și nu repară poarta dacă Politica de grup o refuză. Iată ce face de fapt fiecare poartă și cum se schimbă doar cea care refuză.

Patru porți într-o ordine fixă

Gateway-ul decide mai întâi dacă identitatea poate stabili un tunel: o politică RADIUS, o condiție de grup, o verificare de certificat, o permisiune Access Server. Apoi rutarea și firewall-urile decid dacă pachetul din pool-ul tunelului ajunge la ascultătorul TCP 3389 al destinației. Apoi handshake-ul NLA al clientului autentifică contul față de destinație. Abia după aceste trei, autoritatea de securitate locală verifică dacă contul deține dreptul de autentificare cerut de o sesiune la distanță interactivă.

Deoarece ordinea este fixă, fiecare poartă le ascunde pe cele din spate. Un tunel eșuat nu spune nimic despre rutare; un port blocat nu spune nimic despre dreptul de autentificare; un test de port reușit nu spune nimic despre admitere. De aceea „VPN-ul funcționează, dar RDP nu” nu este o singură problemă, ci o graniță între două dintre aceste porți, și de aceea textul erorii este cel mai rapid mod de a afla pe care ai dat.

Dreptul care refuză de fapt sesiunea

Autentificarea pe desktopul la distanță necesită dreptul de utilizator Permite autentificarea prin Serviciile de desktop la distanță, SeRemoteInteractiveLogonRight. Este verificat la autentificare, nu la configurarea tunelului, motiv pentru care un cont poate naviga ore întregi în rețea și totuși i se refuză un desktop. Dialogul care îl afișează se află în Politici locale, Atribuirea drepturilor de utilizator, iar echivalentul de domeniu este într-un GPO.

Calitatea de membru implicită depinde de rolul mașinii: stațiile de lucru și serverele membre îl acordă grupurilor Administrators și Remote Desktop Users, în timp ce un controler de domeniu îl acordă doar grupului Administrators. Acest singur fapt explică cea mai mare parte a confuziei, deoarece același cont reușește pe un server de fișiere și eșuează pe un DC. Un drept de refuz învinge dreptul de permitere corespunzător indiferent de apartenența la grup, așa că un cont căruia i se permite și i se refuză simultan este refuzat. Un grup de refuz larg poate prinde un administrator adăugat din complezență.

Citiți politica efectivă, nu dialogul local

Politica locală este suprascrisă de orice GPO de domeniu care definește același drept, așa că snap-in-ul local poate afișa o listă care pare corectă în timp ce starea efectivă este diferită. Exportați ce aplică de fapt mașina, apoi căutați dreptul și citiți SID-urile în locul numelor afișate:

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

În acea ieșire, *S-1-5-32-544 este Administrators, iar *S-1-5-32-555 este Remote Desktop Users.

Dacă niciunul nu apare, nimeni în afară de un deținător de politică nu poate deschide un desktop, orice ar sugera dialogul local Utilizatori și grupuri. Atunci gpresult numește GPO-ul care a câștigat, și acesta este obiectul pe care trebuie să îl editați; schimbarea politicii locale pe o mașină în domeniu este un test, nu o remediere.

Acordați cel mai îngust drept potrivit

Răspunsul obișnuit este grupul Remote Desktop Users pe destinație. Acesta poartă dreptul implicit, este mult mai mic decât Administrators și separă „poate deschide un desktop” de „poate administra serverul”. Acolo unde politica a reatribuit dreptul în mod explicit, adăugați grupul sau contul la acea politică în loc să adăugați un grup pe care nimeni nu l-a gândit ca control de acces.

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

Verificați lista de refuzuri înainte de a adăuga ceva. Dacă un drept de refuz numește un grup care conține utilizatorul, schimbarea corectă este eliminarea contului din acel grup sau restrângerea refuzului, nu adăugarea unei a doua permisiuni în altă parte. Notați ce drept ați schimbat și unde, deoarece o actualizare ulterioară a GPO va restabili silențios starea anterioară și tichetul se va redeschide cu același mesaj.

Păstrați calea de rețea ca decizie separată

Grupul VPN nu trebuie să ajungă la fiecare port. Când un grup are nevoie de o aplicație și nu de un desktop, o regulă de firewall limitată la pool-ul tunelului și la portul aplicației dă efect acelei politici, în timp ce dreptul de autentificare rămâne neatins.

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

Configurația per client a OpenVPN și permisiunile de grup ale Access Server pot restricționa prefixele destinației în același spirit; niciuna nu acordă un drept de autentificare Windows, iar un drept de autentificare nu poate deschide un port. Păstrați-le în ferestre de modificare separate, deoarece o regulă de port și un drept sunt aprobate de persoane diferite.

Verificați în aceeași ordine în care se aplică porțile: poate contul stabili tunelul, ajunge sesiunea la ascultător, se autentifică clientul și deține contul dreptul. Un ping care eșuează în timp ce testul de port reușește este un firewall care răspunde diferit la ICMP, nu o dovadă că RDP este blocat. Referința Microsoft privind dreptul de autentificare enumeră valorile implicite pe rol de mașină și regula că refuzul învinge permisiunea.