voor het eerst gepubliceerd op TECHNET op Jan 24, 2014
goedemorgen AskPerf! Kiran hier met een vraag voor u: Waarom hebben we certificaten nodig? Nou, certificaten worden gebruikt om de communicatie tussen twee machines te ondertekenen. Wanneer een client verbinding maakt met een server, wordt de identiteit van de server die de verbinding ontvangt en op zijn beurt informatie van de client gevalideerd met behulp van certificaten.
dit wordt gedaan om mogelijke man-in-the-middle aanvallen te voorkomen. Wanneer een communicatiekanaal wordt ingesteld tussen de client en de server, geeft de autoriteit die het certificaat uitgeeft/genereert, aan dat de server authentiek is.
dus, zolang de client de server waarmee hij communiceert vertrouwt, worden de gegevens die naar en van de server worden verzonden als veilig beschouwd. Dit brengt me bij de volgende vraag:
welk type certificaat is vereist voor RDS?
het volgende blog bevat informatie over het type certificaten en hoe u ze kunt maken met behulp van de interne CA van het domein.
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
basisvereisten voor Extern bureaublad-certificaten:
- het certificaat wordt geïnstalleerd in het “persoonlijke” certificaatarchief van de computer.
- het certificaat heeft een bijbehorende privésleutel.
- de extensie ” Enhanced Key Usage “heeft een waarde van” Server Authentication “of” Remote Desktop Authentication ” (1.3.6.1.4.1.311.54.1.2). Certificaten zonder” Enhanced Key Usage ” extensie kunnen ook worden gebruikt.
zoals de functie suggereert, hebben we een’ server Authentication ‘ certificaat nodig. Dit certificaat kan worden gegenereerd met behulp van de sjabloon ‘Workstation Authentication’ (indien nodig).
hier is het exacte proces:
- open CERTSRV.MSC en certificaten configureren.
- Open Certificeringsinstantie.
- vouw in het detailvenster de naam van de instructeurcomputer uit.
- Klik met de rechtermuisknop op Certificaatsjablonen en selecteer Beheren. Klik met de rechtermuisknop op Workstation-verificatie en klik op Sjabloon dupliceren.
- wijzig op het tabblad Algemeen de naam van de Sjabloonweergave in Client-Server-verificatie en vink het selectievakje certificaat publiceren in Active Directory aan.
- klik op het tabblad Extensies op Toepassingsbeleid en vervolgens op Bewerken. Klik op Toevoegen en selecteer serververificatie. Klik op OK totdat u terugkeert naar het dialoogvenster Eigenschappen van nieuwe sjabloon.
- klik op het tabblad Beveiliging. Voor Domeincomputers klikt u op het selectievakje ‘Auto-inschrijving toestaan’. Klik op OK. Sluit de console Certificaatsjablonen.
- in de module certsrv klikt u met de rechtermuisknop op Certificaatsjablonen en selecteert u nieuwe en vervolgens uit te geven certificaatsjabloon.
- Selecteer Client-Server authenticatie en klik op OK.
dit zal zichtbaar zijn bij het bekijken van het certificaat in de MMC-module’ Certificates’, zoals hieronder:
wanneer u het certificaat opent, zal het tabblad’ Algemeen ‘ook het doel van dit certificaat bevatten om ‘serververificatie’ te zijn, zoals hieronder te zien is:
een andere manier om dit te valideren, zou zijn om naar de sectie ‘Details’ van het certificaat te gaan en te kijken naar de eigenschap’ Enhanced Key Usage’:
de eenvoudigste manier om een certificaat te verkrijgen, als u de clientcomputers beheert die worden verbonden, is door Active Directory Certificate Services te gebruiken. U kunt uw eigen certificaten aanvragen en implementeren en ze worden door elke machine in het domein vertrouwd.
als u gebruikers toestaat extern verbinding te maken en ze zullen geen deel uitmaken van uw domein, moet u certificaten implementeren van een openbare CA. Voorbeelden met inbegrip van, maar niet beperkt tot: GoDaddy, Verisign, Entrust, Thawte, DigiCert
Nu u weet welk type certificaat u nodig hebt, laten we het hebben over de inhoud van het certificaat.
in Windows 2008/2008 R2 maakt u verbinding met de farmnaam, die volgens DNS round robin eerst wordt doorgestuurd naar de redirector, naast de connection broker en ten slotte naar de server die uw sessie zal hosten.
in Windows 2012 maakt u verbinding met de Connection Broker en het stuurt u naar de collectie met behulp van de collectienaam.
de certificaten die u implementeert moeten een onderwerpnaam of een alternatieve onderwerpnaam hebben die overeenkomt met de naam van de server waarmee de gebruiker verbinding maakt. Voor het publiceren moet het certificaat bijvoorbeeld de namen bevatten van alle RDSH-servers in de collectie. Het certificaat voor RDWeb moet de FQDN van de URL bevatten, op basis van de naam waarmee de gebruikers verbinding maken. Als je gebruikers extern hebt verbonden, moet dit een externe naam zijn (moet overeenkomen met wat ze verbinden). Als gebruikers intern verbinding maken met RDweb, moet de naam overeenkomen met de Interne naam. Voor Single Sign On moet de naam van het onderwerp opnieuw overeenkomen met de servers in de collectie.
voor ons voorbeeld, laten we mijn RDS-implementatie beschouwen als de volgende machines:
RDSH1.RENDER.COM sessiehost met externe Apps geconfigureerd
RDSH2.RENDER.COM sessiehost met externe Apps geconfigureerd
RDVH1.MAKEN.Com-virtualisatiehost met VDI-VMs geconfigureerd
RDVH2.RENDER.COM virtualisatie host met VDI VM ‘ s geconfigureerd
RDCB.RENDER.COM Connection Broker
RDWEB.RENDER.COM RDWeb en Gateway server
wanneer mijn client intern verbinding maakt, zal hij de FQDN van de server die de webpagina host invoeren, d.w.z.: RDWEB.RENDER.COM.
de naam van het certificaat moet deze naam zijn, van de URL waarmee de gebruiker de verbinding zal starten. Maar we moeten niet vergeten dat de verbinding niet alleen hier eindigt. De verbinding stroomt dan van de webserver naar een van de session hosts of virtualisatie hosts en ook de connection broker.
het certificaat kan op al deze servers worden gebruikt. Daarom raden we aan dat de alternatieve naam van het certificaat de namen bevat van alle andere servers die deel uitmaken van de implementatie.
kortom, het certificaat voor mijn omgeving zou als volgt zijn:
Type: Server Authentication
naam: RDWEB.RENDER.COM
SAN: RDSH1.RENDER.COM; RDSH2.RENDER.COM; RDVH1.RENDER.COM; RDVH2.MAKEN.COM; RDCB.RENDER.COM
dit is alles wat je nodig hebt zolang je 5 of minder servers in de implementatie hebt. Maar we hebben een probleem als we meer servers in de implementatie hebben. Dit komt omdat, door het ontwerp, de SAN (Subject Alternate Name) op een certificaat, slechts 5 servernamen kan bevatten. Als je er meer hebt, moet je een wildcard certificaat krijgen dat is uitgegeven voor alle servers in de implementatie. Hier verandert mijn certificaat als volgt:
Type: Serverauthenticatie
naam: RDWEB.RENDER.COM
SAN:*.MAKEN.COM (95) 79>
in het volgende scenario staan we nog steeds voor een aantal uitdagingen. Merk op dat dit alleen geldt als u externe gebruikers hebt die toegang hebben tot de implementatie.
externe naam: RDWEB.RENDER.com
Interne naam: RDWEB.MAKEN.lokaal
hier, als u een certificaat met RDWEB.RENDER.COM in de naam worden de certificaatfouten nog steeds weergegeven. Dit komt omdat het certificaat verondersteld wordt een server te valideren met de FQDN: ‘RDWEB.RENDER.COM’. echter, uw server is ‘ RDWEB.MAKEN.LOCAL’ en de’. com ‘naar’.lokale ‘ magie gebeurt alleen op uw openbare firewall / router met behulp van port forwarding (meest voorkomende scenario).
in dergelijke scenario ’s hebben we eerder aanbevolen dat de naam op het certificaat de’. com ‘- naam bevat en het SAN De ‘ bevat.lokale naam.
onlangs stoppen alle leveranciers van openbare certificaten met het uitgeven van certificaten met”.Lokaal in hen. Beginnend met Windows 8 en Windows Server 2012, hebben we niet langer de externe en interne Namen nodig om in het certificaat te worden opgenomen.
in scenario ‘ s waarbij externe clients verbinding maken en u een achtervoegsel voor een privé-intern domein hebt (domein.Lokaal), kunt u een certificaat krijgen van een openbare CA met de externe (RDWEB.DOMAIN.COM) geef een naam aan de RAD-webtoegang en RD-Gateway-functies, omdat dit de enige functies zijn die aan internet worden blootgesteld. Voor RD Connection Broker – Publishing en RD Connection Broker – Single Sign On inschakelen kunt u gebruik maken van een intern certificaat met het domein.De lokale naam staat erop. Dit werkt echter, zoals eerder vermeld, alleen met clients die verbinding maken via RDC 8.0 of hoger.
de RD-Gateway en Extern bureaublad-Client versie 8.0 (en hoger) biedt externe gebruikers een veilige verbinding met de implementatie. Eenmaal aangesloten op de implementatie, het interne certificaat met de ‘.local ‘ naam zal zorgen voor Remote App signing (publishing) en Single Sign-On.
nu, laten we kijken waar we het certificaat dat we hebben configureren:
Open het Serverbeheer op de Connection Broker-server en klik op Extern bureaublad-Services in het linkerdeelvenster.
eenmaal hier ziet u uw implementatie zoals in de afbeelding hieronder. Klik op taken en selecteer “Deployment Properties bewerken””
dit zal het eigenschappenvenster van de implementatie weergeven. Selecteer de optie certificaten in het linkerdeelvenster:
nu, zoals eerder besproken, kunt u het certificaat dat is gemaakt selecteren met behulp van de’ Selecteer bestaand certificaat ‘ knop aan de onderkant van het scherm.
wijs het gewoon naar de “.pfx ‘ bestand en laat het toe om het certificaat voor de rol te importeren.
u kunt een enkel certificaat gebruiken voor alle rollen, als uw clients alleen intern zijn in het domein, door een eenvoudig jokercertificaat te genereren (*.MAKEN.LOCAL) en het binden aan alle rollen.
merk op dat zelfs als u meerdere servers hebt die deel uitmaken van deze implementatie, het serverbeheer het certificaat zal importeren naar alle servers in de implementatie, ze in de vertrouwde root van de machines zal plaatsen en ze aan de respectieve rollen zal binden.
– Kiran Kadaba
