Nu cu mult timp implementam o soluție pe un server Windows. Așa cum se obișnuiește, am plasat scurtcircuite pe desktop-urile angajaților pentru a se conecta, și le-am spus — lucrați. Dar utilizatorii s-au arătat temători în ceea ce privește securitatea cibernetică. La conectarea la server, văzând mesaje de genul: „Dăruiești acestui server? Sigur, sigur?” se speriau și se întrebau dacă totul este în regulă, dacă pot apăsa pe OK? Atunci s-a decis să facem totul frumos, pentru a nu mai avea întrebări și panică.
Dacă utilizatorii tăi încă vin la tine cu astfel de temeri și ți s-a săturat să bifezi „Nu mai întrebați” — bun venit sub articol.
Pas zero. Pregătirea și întrebările de încredere
Așadar, utilizatorul nostru dă clic pe fișierul salvat cu extensia .rdp și primește o astfel de solicitare:
Conexiune „rău intenționată”.
Pentru a scăpa de această fereastră se folosește o utilitară specială numită RDPSign.exe. Documentația completă este disponibilă, ca de obicei, pe , iar noi vom analiza un exemplu de utilizare.
Pentru început, trebuie să luăm un certificat pentru semnarea fișierului. Acesta poate fi:
- Public.
- Eliberat de un serviciu intern de Certificate Authority.
- Sau complet auto-semnat.
Cel mai important este ca certificatul să aibă capacitatea de a semna (da, poate fi obținut
de la contabilitatea semnăturii electronice), iar PC-urile clienților să-i acorde încredere. Aici voi folosi un certificat auto-semnat.
Amintesc că încrederea în certificatul auto-semnat poate fi organizată prin politici de grup. Mai multe detalii — sub spoiler.
Cum să faci certificat de încredere prin magia GPO
Pentru început, trebuie să luăm certificatul existent fără cheia privată în format .cer (asta se poate face, exportând certificatul din consola „Certificate”) și să-l plasăm într-un folder de rețea disponibil utilizatorilor pentru citire. După aceasta, se poate configura politica de grup.
Importul certificatului se configurează în secțiunea: Configurarea computerului — Politici — Configurarea Windows — Setările de securitate — Politicile cheilor publice — Centrele de certificare rădăcină de încredere. Apoi, click dreapta pentru a importa certificatul.
Politica configurată.
Acum, PC-urile clienților vor avea încredere în certificatul auto-semnat.
Dacă problemele cu încrederea sunt rezolvate, trecem direct la problema semnării.
Pasul întâi. Semnăm cu multă încredere fișierul
Certificatul este aici, acum trebuie să aflăm amprenta acestuia. Pur și simplu îl deschidem în instrumentul „Certificatul” și copiem de pe tab-ul „Conținut” de acolo.
Amprenta de care avem nevoie.
Mai bine să o aducem imediat într-o formă adecvată — doar litere mari și fără spații, dacă există. Acest lucru se poate face ușor în consola PowerShell cu comanda:
("6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA").ToUpper().Replace(" ","")
Odată ce amprenta este în formatul dorit, putem semna cu încredere fișierul rdp:
rdpsign.exe /sha256 6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA .contoso.rdp
Unde .contoso.rdp este calea absolută sau relativă către fișierul nostru.
După ce fișierul este semnat, nu se vor putea modifica o parte din parametrii printr-o interfață grafică, cum ar fi numele serverului (de fapt, altfel care ar fi sensul semnării?). Iar dacă modificați setările cu un editor de text, semnătura va fi invalidată.
Acum, la dublu click pe shortcut, mesajul va fi diferit:
Mesaj nou. Culoarea este mai puțin periculoasă, există deja progres.
Să ne debarasăm și de el.
Pasul doi. Din nou, întrebări de încredere
Pentru a scăpa de acest mesaj, avem din nou nevoie de politica de grup. De data aceasta, ne îndreptăm către secțiunea Configurarea computerului — Politici — Șabloane administrative — Componente Windows — Servicii Desktop Remote — Client pentru Serviciul Desktop Remote — A indica amprentele SHA1 ale certificatelor care reprezintă editori de încredere RDP.
Politica de care avem nevoie.
În politică, este suficient să adăugăm deja cunoscuta noastră amprentă de la pasul anterior.
Este de remarcat că această politică suprascrie politica „Permite RDP file de la editori acceptați și parametrii de utilizator RDP specificați implicit”.
Politica configurată.
Iată, acum nu mai există întrebări ciudate — doar o solicitare de utilizator-parolă. Hmm...
Pasul trei. Acces transparent la server
Adevărat, dacă ne-am autentificat deja la intrarea în computerul pe domeniu, de ce să introducem din nou același utilizator și parolă? Să transmitem datele de autentificare pe server „transparent”. În cazul RDP simplu (fără utilizarea RDS Gateway), avem nevoie de… Corect, politica de grup.
Ne îndreptăm către secțiunea: Configurarea computerului — Politici — Șabloane administrative — Sistem — Transmiterea datelor de autentificare — Permite transmiterea datelor de autentificare stabilite implicit.
Aici, în listă, poți adăuga serverele necesare sau folosi wildcard. Acesta va arăta astfel: TERMSRV/trm.contoso.com sau TERMSRV/*.contoso.com.
Politica configurată.
Acum, dacă ne uităm la scurtătura noastră, aceasta va arăta aproximativ așa:
Numele utilizatorului nu poate fi schimbat.
În cazul în care se folosește RDS Gateway, va fi necesar să se permită și transmiterea datelor pe acesta. Pentru a face asta, în managerul IIS, trebuie să dezactivezi verificarea anonimă în "Metodele de autentificare" și să activezi autentificarea Windows.
IIS configurat.
Nu uita să repornești serviciile web folosind comanda:
iisreset /noforce
Acum totul este în regulă, fără întrebări sau solicitări.
Numai utilizatorii înregistrați pot participa la sondaj. , vă rugăm.
Spune-mi, îți semnezi scurtăturile RDP utilizatorilor tăi?
43%Nu, ei sunt obișnuiți să apese pe „OK” în mesajele fără a citi, unii chiar își bifează singuri opțiunea „Nu mai întrebați”.28
29.2%Eu, de obicei, așez manual scurtătura și fac primul acces pe server împreună cu fiecare utilizator.19
6.1%Desigur, îmi place să am ordine în toate.4
21.5%Nu folosesc servere terminale.14
Au votat 65 de utilizatori. 14 utilizatori s-au abținut.
Sursa: habr.com
