først offentliggjort på TECHNET den Jan 24, 2014
god morgen AskPerf! Kiran her med et spørgsmål til dig: Hvorfor har vi brug for Certifikater? Nå, certifikater bruges til at underskrive kommunikationen mellem to maskiner. Når en klient opretter forbindelse til en server, valideres identiteten på den server, der modtager forbindelsen, og til gengæld oplysninger fra klienten ved hjælp af certifikater.
dette gøres for at forhindre mulige man-in-the-middle angreb. Når en kommunikationskanal er konfigureret mellem klienten og serveren, garanterer den myndighed, der udsteder/genererer certifikatet, at serveren er autentisk.
så længe klienten stoler på den server, den kommunikerer med, betragtes de data, der sendes til og fra serveren, som sikre. Dette bringer mig til det næste spørgsmål:
hvilken type certifikat kræves for RDS?
følgende blog indeholder oplysninger om typen af certifikater, og hvordan du kan oprette dem ved hjælp af domænets interne CA.
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
grundlæggende krav til Fjernskrivebordscertifikater:
- certifikatet er installeret i computerens” personlige ” certifikatbutik.
- certifikatet har en tilsvarende privat nøgle.
- udvidelsen “Enhanced Key Usage” har en værdi af enten “Server Authentication” eller “Remote Desktop Authentication” (1.3.6.1.4.1.311.54.1.2). Certifikater uden udvidelse “Enhanced Key Usage” kan også bruges.
som den funktion, den udfører, antyder, har vi brug for et ‘Servergodkendelsescertifikat’. Dette certifikat kan genereres ved hjælp af skabelonen’ Arbejdsstationsgodkendelse ‘ (hvis nødvendigt).
her er den nøjagtige proces:
- Åbn CERTSRV.MSC og configure certifikater.
- Åben Certificeringsmyndighed.
- Udvid instruktørens computernavn i detaljeruden.
- Højreklik på Certifikatskabeloner, og vælg Administrer. Højreklik på Arbejdsstationsgodkendelse, og klik på Duplicate Template.
- under fanen Generelt skal du ændre Skabelonvisningsnavnet til Klientservergodkendelse og kontrollere Udgiv certifikat i Active Directory.
- på fanen Udvidelser skal du klikke på programpolitikker og derefter redigere. Klik på Tilføj, og vælg derefter servergodkendelse. Klik på OK, indtil du vender tilbage til egenskaberne for dialogboksen Ny skabelon.
- Klik på fanen Sikkerhed. For Domænecomputere skal du klikke på afkrydsningsfeltet for at ‘Tillad Autoenroll’. Klik på OK. Luk konsollen Certifikatskabeloner.
- Højreklik på Certifikatskabeloner i snap-in ‘ en certsrv, og vælg Ny og derefter Certifikatskabelon, der skal udstedes.
- Vælg Klientservergodkendelse, og klik derefter på OK.
dette vil være synligt, når du ser certifikatet i’ Certifikater ‘MMC snap-in, som nedenfor:
når du åbner certifikatet, vil fanen’ Generelt ‘ også indeholde formålet med dette certifikat til at være ‘servergodkendelse’ som vist nedenfor:
en anden måde at validere dette på, ville være at gå til afsnittet’ Detaljer ‘i certifikatet og se på egenskaben ‘forbedret Nøglebrug’ :
den nemmeste måde at få et certifikat på, hvis du styrer de klientmaskiner, der vil forbinde, er at bruge Active Directory Certificate Services. Du kan anmode om og implementere dine egne certifikater, og de vil blive betroet af hver maskine i domænet.
hvis du vil tillade brugere at oprette forbindelse eksternt, og de ikke vil være en del af dit domæne, skal du implementere certifikater fra en offentlig CA. Eksempler herunder, men ikke begrænset til: GoDaddy, Verisign, Entrust, DigiCert
nu hvor du ved, hvilken type certifikat du har brug for, lad os tale om indholdet af certifikatet.
i vinduer 2008/2008 R2, du opretter forbindelse til gården navn, som som pr DNS round robin, bliver først dirigeret til omdirigering, ved siden af forbindelsen mægler og endelig til den server, der vil være vært for din session.
i vinduer 2012 opretter du forbindelse til Forbindelsesmægleren, og den dirigerer dig til samlingen ved hjælp af samlingsnavnet.
de certifikater, du installerer, skal have et emnenavn eller et alternativt emnenavn, der svarer til navnet på den server, som brugeren opretter forbindelse til. Så for eksempel til udgivelse skal certifikatet indeholde navnene på alle RDSH-serverne i samlingen. Certifikatet skal indeholde URL-adressen, baseret på det navn, som brugerne opretter forbindelse til. Hvis du har brugere, der opretter forbindelse eksternt, skal dette være et eksternt navn (skal matche det, de opretter forbindelse til). Hvis du har brugere, der opretter forbindelse internt til Google, skal navnet matche det interne navn. For Single Sign On skal emnenavnet igen matche serverne i samlingen.
lad os for vores eksempel overveje min RDS-implementering til at indeholde følgende maskiner:
RDSH1.RENDER.COM Session vært med eksterne Apps konfigureret
RDSH2.RENDER.COM Session vært med eksterne Apps konfigureret
RDVH1.GØRE.Com virtualisering vært med VDI VM ‘er konfigureret
RDVH2.RENDER.COM virtualisering vært med VDI VM’ er konfigureret
RDCB.RENDER.COM forbindelse mægler
RDWEB.RENDER.COM server
når min klient opretter forbindelse internt, vil han komme ind på den server, der er vært for hjemmesiden, dvs.: RDWEB.RENDER.COM.
navnet på certifikatet skal være dette navn på den URL, som brugeren vil starte forbindelsen til. Men vi skal huske, at forbindelsen ikke bare slutter her. Forbindelsen flyder derefter fra internetserveren til en af sessionshosterne eller virtualiseringsværterne og også forbindelsesmægleren.
certifikatet kan være almindeligt på alle disse servere. Derfor anbefaler vi, at certifikatets alternative navn indeholder navnene på alle de andre servere, der er en del af implementeringen.
kort sagt ville certifikatet for mit miljø være som følger:
Type: servergodkendelse
navn: RDWEB.RENDER.COM
SAN: RDSH1.RENDER.COM; RDSH2.RENDER.COM; RDVH1.RENDER.COM; RDVH2.GØRE.COM; RDCB.RENDER.COM
dette er alt hvad du behøver, så længe du har 5 eller færre servere i implementeringen. Men vi har et problem, når vi har flere servere i implementeringen. Dette skyldes, at SAN (emne alternativt navn) på et certifikat kun kan indeholde 5 servernavne. Hvis du har flere af dem, skal du få et jokertegncertifikat udstedt til at dække alle serverne i implementeringen. Her ændres mit certifikat som følger:
Type: servergodkendelse
navn: RDWEB.RENDER.COM
SAN: *.GØRE.Kom
vi støder stadig på nogle udfordringer, når det kommer til følgende scenarie. Bemærk, at dette kun gælder, når du har eksterne brugere, der har adgang til installationen.
eksternt navn: RDWEB.RENDER.com
internt navn: RDV.GØRE.lokal
her, hvis du får et certifikat med RDWEB.RENDER.COM i navnet vises certifikatfejlene stadig. Dette skyldes, at certifikatet skal validere en server med FKDN: ‘RDWEB.RENDER.COM’. din server er dog’.GØRE.Lokal’ og’. com ’til’.lokal ‘ magi sker kun på din offentlige brandvæg / router ved hjælp af portvideresendelse (mest almindelige scenario).
i sådanne scenarier anbefalede vi tidligere, at navnet på certifikatet indeholder ‘.com’ – navnet, og SAN indeholder ‘.lokalt navn.
for nylig stopper alle offentlige certifikatudbydere med at udstede certifikater med ‘.Lokale ‘ i dem. Fra vinduer 8 og vinduer Server 2012 har vi ikke længere brug for de eksterne og interne Navne, der skal være indeholdt i certifikatet.
i scenarier, hvor du har eksterne klienter, der opretter forbindelse, og du har et privat internt domænesuffiks (domæne.Lokal), kan du få et certifikat fra en offentlig CA med den eksterne (RDWEB.DOMAIN.COM) navngiv og bind det til RD-internetadgangs-og Rd-Portrollerne, fordi disse er de eneste roller, der udsættes for internettet. For RD Connection Broker-Publishing og RD Connection Broker – aktiver Single Sign On, kan du gøre brug af et internt certifikat med ‘domænet.Lokal ‘ navn på det. Dette fungerer dog som tidligere nævnt kun med klienter, der forbinder via RDC 8.0 eller derover.
RD-porten og Remote Desktop Client version 8.0 (og nyere) giver de eksterne brugere en sikker forbindelse til udrulningen. Når den er tilsluttet implementeringen, det interne certifikat med ‘.lokal ‘ navn vil tage sig af Remote App signering (udgivelse) og Single Sign-On.
lad os nu se på, hvor vi konfigurerer det certifikat, vi har:
Åbn Server Manager på Connection Broker server og klik på Remote Desktop Services i venstre rude.
når du er her, vil du se din implementering vist som i illustrationen nedenfor. Klik på opgaver, og vælg “Rediger Implementeringsegenskaber”
dette vil få vist egenskabsarket for implementeringen. Vælg indstillingen certifikater i venstre rude:
nu, som diskuteret tidligere, kan du vælge det certifikat, der blev oprettet ved hjælp af knappen ‘Vælg eksisterende certifikat’ nederst på skærmen.
Bare peg det til ‘.tillade det at importere certifikatet for rollen.
du kan bruge et enkelt certifikat til alle roller, hvis dine klienter kun er interne i domænet, ved at generere et simpelt jokertegncertifikat (*.GØRE.Lokalt) og binder det til alle roller.
Bemærk, at selvom du har flere servere, der er en del af denne implementering, importerer serveradministratoren certifikatet til alle serverne i implementeringen, placerer dem i maskinernes betroede rod og binder dem til de respektive roller.
– Kiran Kadaba
