publicerades först på TECHNET den Jan 24, 2014
God morgon AskPerf! Kiran här med en fråga till dig: Varför behöver vi certifikat? Tja, certifikat används för att underteckna kommunikationen mellan två maskiner. När en klient ansluter till en server valideras identiteten på den server som tar emot anslutningen och i sin tur information från klienten med hjälp av certifikat.
detta görs för att förhindra eventuella man-in-the-middle-attacker. När en kommunikationskanal är inställd mellan klienten och servern, garanterar den myndighet som utfärdar/genererar certifikatet att servern är autentisk.
så, så länge klienten litar på servern den kommunicerar med, anses data som skickas till och från servern vara säkra. Detta leder mig till nästa fråga:
vilken typ av certifikat krävs för RDS?
följande blogg innehåller information om typen av certifikat och hur du kan skapa dem med hjälp av domänens interna CA.
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
grundläggande krav för certifikat för fjärrskrivbord:
- certifikatet är installerat i datorns” personliga ” certifikatbutik.
- certifikatet har en motsvarande privat nyckel.
- tillägget ”Enhanced Key Usage” har ett värde av antingen ”Server Authentication” eller ”Remote Desktop Authentication” (1.3.6.1.4.1.311.54.1.2). Certifikat utan” Enhanced Key Usage ” – tillägg kan också användas.
som funktionen Den utför antyder behöver vi ett certifikat för serverautentisering. Detta certifikat kan genereras med hjälp av mallen’ Workstation Authentication ’ (om det behövs).
här är den exakta processen:
- öppna CERTSRV.MSC och konfigurera certifikat.
- Öppna Certifieringsmyndigheten.
- expandera instruktörens datornamn i informationsfönstret.
- högerklicka på certifikatmallar och välj Hantera. Högerklicka på Arbetsstationsautentisering och klicka på Duplicera Mall.
- på fliken Allmänt ändrar du mallens visningsnamn till klient-Server-autentisering och markerar publicera certifikat i Active Directory.
- på fliken Tillägg klickar du på programpolicyer och sedan på Redigera. Klicka på Lägg till och välj serverautentisering. Klicka på OK tills du återgår till dialogrutan Egenskaper för ny mall.
- klicka på fliken Säkerhet. För Domändatorer, klicka på kryssrutan för att ’Tillåt Autoenroll’. Klicka på OK. Stäng konsolen certifikatmallar.
- högerklicka på certifikatmallar i snapin-modulen certsrv och välj Ny sedan certifikatmall att utfärda.
- Välj klient-Server-autentisering och klicka sedan på OK.
detta visas när certifikatet visas i snapin-modulen ’certifikat’ MMC, enligt nedan:
när du öppnar certifikatet kommer fliken ’Allmänt’ också att innehålla syftet med detta certifikat att vara ’serverautentisering’ enligt nedan:
ett annat sätt att validera detta skulle vara att gå till avsnittet ’Detaljer’ i certifikatet och titta på egenskapen ’Enhanced Key Usage’ :
det enklaste sättet att få ett certifikat, om du kontrollerar klientmaskinerna som ska anslutas, är att använda Active Directory-certifikattjänster. Du kan begära och distribuera dina egna certifikat och de kommer att lita på varje maskin i domänen.
om du ska tillåta användare att ansluta externt och de inte kommer att vara en del av din domän måste du distribuera certifikat från en offentlig CA. Exempel inklusive, men inte begränsat till: GoDaddy, Verisign, Entrust, Thawte, DigiCert
nu när du vet vilken typ av certifikat du behöver, låt oss prata om innehållet i certifikatet.
i Windows 2008/2008 R2 ansluter du till gårdsnamnet, som enligt DNS round robin först riktas till omdirigeraren, bredvid anslutningsmäklaren och slutligen till servern som kommer att vara värd för din session.
i Windows 2012 ansluter du till Anslutningsmäklaren och den dirigerar dig till samlingen med hjälp av samlingsnamnet.
certifikaten du distribuerar måste ha ETT ämnesnamn eller ämnesalternativ som matchar namnet på servern som användaren ansluter till. Så till exempel för publicering måste certifikatet innehålla namnen på alla RDSH-servrar i samlingen. Certifikatet för RDWeb måste innehålla FQDN för webbadressen, baserat på namnet användarna ansluter till. Om du har användare som ansluter externt måste detta vara ett externt namn (måste matcha vad de ansluter till). Om du har användare som ansluter internt till RDweb måste namnet matcha det interna namnet. För enkel inloggning måste ämnesnamnet igen matcha servrarna i samlingen.
för vårt exempel, låt oss överväga min RDS-distribution för att innehålla följande maskiner:
RDSH1.RENDER.COM Sessionsvärd med Fjärrappar konfigurerade
RDSH2.RENDER.COM Sessionsvärd med Fjärrappar konfigurerade
RDVH1.GÖRA.COM Virtualization host med VDI VMs konfigurerad
RDVH2.RENDER.COM Virtualiseringsvärd med VDI VMs konfigurerad
RDCB.RENDER.COM anslutning mäklare
RDWEB.RENDER.COM RDWeb och Gateway server
när min klient ansluter internt kommer han att ange FQDN för servern som är värd för webbsidan, dvs: RDWEB.RENDER.COM.
namnet på certifikatet måste vara det här namnet på den URL som användaren kommer att initiera anslutningen till. Men vi måste komma ihåg att anslutningen inte bara slutar här. Anslutningen flyter sedan från webbservern till en av sessionsvärdarna eller virtualiseringsvärdarna och även anslutningsmäklaren.
certifikatet kan vara vanligt på alla dessa servrar. Det är därför vi rekommenderar att certifikatets alternativa namn innehåller namnen på alla andra servrar som ingår i distributionen.
kort sagt, certifikatet för min miljö skulle vara följande:
Typ: serverautentisering
namn: RDWEB.RENDER.COM
SAN: RDSH1.RENDER.COM; RDSH2.RENDER.COM; RDVH1.RENDER.COM; RDVH2.GÖRA.COM; RDCB.RENDER.COM
det här är allt du behöver så länge du har 5 eller mindre servrar i distributionen. Men vi har ett problem när vi har fler servrar i distributionen. Detta beror på att san (Subject Alternate Name) på ett certifikat endast kan innehålla 5 servernamn. Om du har fler av dem måste du få ett jokerteckencertifikat utfärdat för att täcka alla servrar i distributionen. Här ändras mitt certifikat enligt följande:
Typ: serverautentisering
namn: RDWEB.RENDER.COM
SAN:*.GÖRA.COM
vi stöter fortfarande på några utmaningar när det gäller följande scenario. Observera att detta endast gäller när du har externa användare som har åtkomst till distributionen.
externt namn: RDWEB.RENDER.com
internt namn: RDWEB.GÖRA.lokal
här, om du får ett certifikat med RDWEB.RENDER.COM i namnet visas certifikatfelen fortfarande. Detta beror på att certifikatet är tänkt att validera en server med FQDN: ’RDWEB.RENDER.COM’. din server är dock ’ RDWEB.GÖRA.Lokala ’och’. com ’till’.lokal ’ magi händer bara på din offentliga brandvägg / router med port forwarding (vanligaste scenariot).
i sådana scenarier rekommenderade vi tidigare att namnet på certifikatet innehåller’. com ’- namnet och SAN innehåller’.lokalt namn.
nyligen slutar alla offentliga certifikatleverantörer att utfärda certifikat med’.Lokala i dem. Från och med Windows 8 och Windows Server 2012 behöver vi inte längre de externa och interna Namnen som finns i certifikatet.
i scenarier där du har externa klienter som ansluter i och du har en privat intern domän suffix (domän.Lokal), kan du få ett certifikat från en offentlig CA med den externa (RDWEB.DOMAIN.COM) namnge och binda det till roller för FJÄRRSKRIVBORDSWEBBÅTKOMST och FJÄRRSKRIVBORDSGATEWAY, eftersom dessa är de enda roller som exponeras för internet. För FJÄRRSKRIVBORDSANSLUTNINGSMÄKLARE-publicering och FJÄRRSKRIVBORDSANSLUTNINGSMÄKLARE-aktivera Enkel inloggning kan du använda ett internt certifikat med domänen.Lokala namn på den. Detta kommer dock, som tidigare nämnts, bara att fungera med klienter som ansluter via RDC 8.0 eller högre.
FJÄRRSKRIVBORDSGATEWAYEN och fjärrskrivbordsklienten version 8.0 (och senare) ger de externa användarna en säker anslutning till distributionen. När du är ansluten till utplaceringen, det interna certifikatet med ’.lokalt namn tar hand om Fjärrappsignering (publicering) och enkel inloggning.
nu kan vi titta på var vi konfigurerar certifikatet vi har:
öppna Serverhanteraren på Connection Broker-servern och klicka på Remote Desktop Services i den vänstra rutan.
en gång här ser du din distribution som visas som i bilden nedan. Klicka på uppgifter och välj ”Redigera Distributionsegenskaper”
detta kommer att ta upp egenskapsbladet för utplaceringen. Välj alternativet certifikat i den vänstra rutan:
nu, som diskuterats tidigare, kan du välja certifikatet som skapades med knappen ’Välj befintligt certifikat’ längst ner på skärmen.
peka bara på ’.PFX ’ fil och låt den importera certifikatet för rollen.
du kan använda ett enda certifikat för alla roller, om dina klienter endast är interna i domänen, genom att generera ett enkelt jokerteckencertifikat (*.GÖRA.Lokal) och binda den till alla roller.
Observera att även om du har flera servrar som ingår i denna distribution, importerar Serverhanteraren certifikatet till alla servrar i distributionen, placerar dem i den betrodda roten på maskinerna och binder dem till respektive roller.
– Kiran Kadaba
