publicat pentru prima dată pe TECHNET pe Jan 24, 2014
Bună dimineața AskPerf! Kiran aici cu o întrebare pentru tine: de ce avem nevoie de certificate? Ei bine, certificatele sunt folosite pentru a semna comunicarea între două mașini. Când un client se conectează la un server, identitatea serverului care primește conexiunea și, la rândul său, informații de la client, este validată folosind certificate.
acest lucru este făcut pentru a preveni posibilele atacuri ale omului în mijloc. Când un canal de comunicare este configurat între client și server, autoritatea care emite/generează certificatul garantează că serverul este autentic.
deci, atâta timp cât clientul are încredere în serverul cu care comunică, datele trimise către și de pe server sunt considerate sigure. Acest lucru mă aduce la următoarea întrebare:
ce tip de certificat este necesar pentru RDS?
următorul blog conține informații privind tipul de certificate și modul în care le puteți crea folosind CA-ul intern al domeniului.
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
cerințe de bază pentru certificatele Desktop la distanță:
- certificatul este instalat în magazinul de certificate „Personal” al computerului.
- certificatul are o cheie privată corespunzătoare.
- extensia „Enhanced Key Usage” are valoarea „Server Authentication” sau „Remote Desktop Authentication” (1.3.6.1).4.1.311.54.1.2). Certificatele cu nici o extensie” Enhanced Key Usage ” poate fi folosit, de asemenea.
după cum sugerează funcția pe care o efectuează, avem nevoie de un certificat de autentificare a serverului. Acest certificat poate fi generat folosind șablonul ‘autentificare stație de lucru’ (dacă este necesar).
iată procesul exact:
- deschideți CERTSRV.MSC și configurați certificatele.
- Autoritatea De Certificare Deschisă.
- în panoul Detalii, extindeți Numele computerului instructor.
- faceți clic dreapta pe șabloane certificat și selectați Gestionare. Faceți clic dreapta pe Autentificare stație de lucru și faceți clic pe Duplicate Template.
- în fila General, schimbați numele afișat al șablonului în autentificare Client-Server și verificați publicare certificat în Active Directory.
- în fila Extensii, faceți clic pe politici aplicație, apoi pe Editare. Faceți clic pe Adăugare, apoi selectați autentificare Server. Faceți clic pe OK până când reveniți la proprietățile dialogului șablon nou.
- Faceți clic pe fila Securitate. Pentru computerele de domeniu, faceți clic pe caseta de selectare pentru a ‘permite Autoenroll’. Faceți clic pe OK. Închideți consola șabloane certificat.
- în snap-in certsrv, faceți clic dreapta pe șabloane certificat și selectați Nou, apoi șablon certificat de EMIS.
- selectați autentificare Client-Server și apoi faceți clic pe OK.
acest lucru va fi vizibil la vizualizarea certificatului în modulul de completare MMC ‘certificate’, după cum urmează:
când deschideți certificatul, fila ‘General’ va conține, de asemenea, scopul acestui certificat de a fi ‘autentificare Server’, după cum se vede mai jos:
un alt mod de a valida acest lucru, ar fi să mergeți la secțiunea ‘detalii’ a certificatului și uita-te la proprietatea ‘Enhanced Key Usage’ :
cel mai simplu mod de a obține un certificat, dacă controlați mașinile client care se vor conecta, este să utilizați Active Directory Certificate Services. Puteți solicita și implementa propriile certificate și acestea vor fi de încredere de către fiecare mașină în domeniu.
dacă veți permite utilizatorilor să se conecteze extern și nu vor face parte din domeniul dvs., va trebui să implementați certificate de la un CA public. Exemple care includ, dar fără a se limita la: GoDaddy, Verisign, Entrust, Thawte, DigiCert
acum, că știți ce tip de certificat aveți nevoie, să vorbim despre conținutul certificatului.
în Windows 2008/2008 R2, vă conectați la numele fermei, care, conform DNS round robin, este direcționat mai întâi către redirector, lângă brokerul de conexiune și, în final, către serverul care vă va găzdui sesiunea.
în Windows 2012, vă conectați la brokerul de conexiuni și vă direcționează către colecție utilizând numele colecției.
certificatele pe care le implementați trebuie să aibă un nume de subiect sau un nume alternativ de subiect care se potrivește cu numele serverului la care se conectează utilizatorul. De exemplu, pentru publicare, certificatul trebuie să conțină numele tuturor serverelor RDSH din colecție. Certificatul pentru RDWeb trebuie să conțină FQDN al adresei URL, pe baza numelui la care se conectează utilizatorii. Dacă aveți utilizatori care se conectează extern, acesta trebuie să fie un nume extern (trebuie să se potrivească cu ceea ce se conectează). Dacă aveți utilizatori care se conectează intern la RDweb, numele trebuie să se potrivească cu numele intern. Pentru conectare unică, din nou numele subiectului trebuie să se potrivească cu serverele din colecție.
pentru exemplul nostru, să luăm în considerare implementarea mea RDS să conțină următoarele mașini:
RDSH1.RENDER.COM gazdă de sesiune cu aplicații la distanță configurate
RDSH2.RENDER.COM gazdă sesiune cu aplicații la distanță configurate
RDVH1.RENDER.Gazdă de virtualizare COM cu VMs VDI configurat
RDVH2.RENDER.COM virtualizare gazdă cu VMs VDI configurat
RDCB.RENDER.COM Broker de conectare
RDWEB.RENDER.COM RDWeb și Gateway server
când clientul meu se conectează intern, va intra în FQDN-ul serverului care găzduiește pagina web, adică: RDWEB.RENDER.COM.
numele certificatului trebuie să fie acest nume, al adresei URL la care utilizatorul va iniția conexiunea. Dar trebuie să ne amintim că conexiunea nu se termină doar aici. Conexiunea curge apoi de la serverul web către una dintre gazdele de sesiune sau gazdele de virtualizare și, de asemenea, brokerul de conexiune.
certificatul poate fi comun pe toate aceste servere. Acesta este motivul pentru care recomandăm ca numele alternativ al certificatului să conțină numele tuturor celorlalte servere care fac parte din implementare.
pe scurt, certificatul pentru mediul meu ar fi după cum urmează:
Tip: autentificare Server
nume: RDWEB.RENDER.COM
SAN: RDSH1.RENDER.COM; RDSH2.RENDER.COM; RDVH1.RENDER.COM; RDVH2.RENDER.COM; RDCB.RENDER.COM
acesta este tot ce aveți nevoie atâta timp cât aveți 5 sau mai puține servere în implementare. Dar avem o problemă atunci când avem mai multe servere în implementare. Acest lucru se datorează faptului că, prin proiectare, SAN (nume alternativ subiect) pe un certificat, poate conține doar 5 nume de server. Dacă aveți mai multe dintre ele, va trebui să obțineți un certificat wildcard emis pentru a acoperi toate serverele din implementare. AICI certificatul meu se modifică după cum urmează:
Tip: autentificare Server
nume: RDWEB.RENDER.COM
SAN: *.RENDER.COM
încă ne confruntăm cu unele provocări atunci când vine vorba de următorul scenariu. Rețineți că acest lucru este valabil numai atunci când aveți utilizatori externi care accesează implementarea.
nume extern: RDWEB.RENDER.com
nume intern: RDWEB.RENDER.local
aici, Dacă primiți un certificat cu RDWEB.RENDER.COM în nume, erorile de certificat încă apar. Acest lucru se datorează faptului că certificatul ar trebui să valideze un server cu FQDN:’ RDWEB.RENDER.COM’. cu toate acestea, serverul dvs. este ‘ RDWEB.RENDER.LOCAL’ și ‘.com’ la ‘.local ‘ magic se întâmplă numai la firewall-ul public / router folosind port forwarding (cel mai frecvent scenariu).
în astfel de scenarii, am recomandat anterior ca numele de pe certificat să conțină numele ‘.com’ și SAN să conțină ‘.numele local.
recent, toți furnizorii de certificate publice se opresc eliberarea certificatelor cu’.Locale în ele. Începând cu Windows 8 și Windows Server 2012, nu mai avem nevoie ca numele externe și interne să fie conținute în certificat.
în scenarii în care aveți clienți externi care se conectează și aveți un sufix de domeniu intern privat (domeniu.LOCAL), puteți obține un certificat de la un CA Public cu extern (RDWEB.DOMAIN.COM) denumiți-l și legați-l de rolurile RD Web Access și RD Gateway, deoarece acestea sunt singurele roluri care sunt expuse internetului. Pentru RD Connection Broker-Publishing și RD Connection Broker-activați Single Sign On, puteți utiliza un certificat intern cu domeniul.Numele LOCAL pe ea. Cu toate acestea, așa cum am menționat mai devreme, va funcționa numai cu clienții care se conectează prin RDC 8.0 sau mai sus.
RD Gateway și Remote Desktop Client versiunea 8.0 (și mai sus) oferă utilizatorilor externi cu o conexiune Securizată la implementarea. Odată conectat la implementare, certificatul intern cu’.numele local va avea grijă de semnarea (publicarea) aplicației la distanță și de conectarea unică.
acum, să ne uităm unde configurăm certificatul pe care îl avem:
Deschideți Server Manager pe serverul Connection Broker și faceți clic pe servicii Desktop la distanță în panoul din stânga.
odată ajuns aici, veți vedea implementarea afișată ca în ilustrația de mai jos. Faceți clic pe sarcini și selectați „Editați proprietățile de implementare”
aceasta va afișa foaia de proprietăți a implementării. Selectați opțiunea certificate din panoul din stânga:
acum, așa cum am discutat mai devreme, puteți selecta certificatul care a fost creat folosind butonul ‘Selectați certificatul existent’ din partea de jos a ecranului.
doar punctul de la ‘.pfx și permiteți-i să importe certificatul pentru ROL.
puteți utiliza un singur certificat pentru toate rolurile, dacă clienții dvs. sunt interni numai domeniului, generând un certificat wildcard simplu (*.RENDER.LOCAL) și legându-l la toate rolurile.
rețineți că, chiar dacă aveți mai multe servere care fac parte din această implementare, managerul de Server va importa certificatul pe toate serverele din implementare, le va plasa în rădăcina de încredere a mașinilor și le va lega la rolurile respective.
– Kiran Kadaba
