24, 2014
Jó reggelt AskPerf! Kiran itt egy kérdéssel az Ön számára: miért van szükségünk tanúsítványokra? Nos, a tanúsítványokat két gép közötti kommunikáció aláírására használják. Amikor egy ügyfél csatlakozik egy kiszolgálóhoz, a kapcsolatot fogadó kiszolgáló identitását, viszont az ügyféltől származó információkat tanúsítványok segítségével érvényesítik.
ez azért van így, hogy megakadályozzuk az esetleges ember-In-The-middle támadásokat. Amikor kommunikációs csatornát állít be az ügyfél és a kiszolgáló között, a tanúsítványt kibocsátó/előállító hatóság kezeskedik a kiszolgáló hitelességéért.
tehát mindaddig, amíg az ügyfél megbízik abban a szerverben, amellyel kommunikál, a szerverre küldött adatok biztonságosnak tekinthetők. Ez elvezet a következő kérdés:
milyen típusú tanúsítvány szükséges az RDS – hez?
a következő blog információkat tartalmaz a tanúsítványok típusáról és arról, hogyan hozhatja létre őket a tartomány belső HITELESÍTÉSSZOLGÁLTATÓJÁNAK használatával.
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
a Távoli asztali tanúsítványokra vonatkozó alapvető követelmények:
- a tanúsítvány telepítve van a számítógép “személyes” tanúsítványtárolójában.
- a tanúsítvány rendelkezik egy megfelelő privát kulccsal.
- az “Enhanced Key Usage” kiterjesztés értéke “Server Authentication” vagy “Remote Desktop Authentication” (1.3.6.1.4.1.311.54.1.2). Az “Enhanced Key Usage” kiterjesztés nélküli tanúsítványok is használhatók.
ahogy az általa végrehajtott funkció sugallja, szükségünk van egy ‘szerver hitelesítési’ tanúsítványra. Ez a tanúsítvány a ‘munkaállomás-hitelesítés’ sablonnal generálható (ha szükséges).
itt van a pontos folyamat:
- nyissa meg a CERTSRV-t.MSc és configure tanúsítványok.
- Nyílt Tanúsító Hatóság.
- a Részletek ablaktáblában bontsa ki az oktató számítógép nevét.
- kattintson a jobb gombbal a Tanúsítványsablonokra, majd válassza a kezelés lehetőséget. Kattintson a jobb gombbal a munkaállomás-hitelesítés elemre, majd kattintson a sablon másolása elemre.
- az Általános lapon módosítsa a sablon megjelenítési nevét ügyfél-kiszolgáló hitelesítésre, majd ellenőrizze a tanúsítvány közzététele lehetőséget az Active Directory-ban.
- a Bővítmények lapon kattintson az alkalmazás házirendek, majd a Szerkesztés elemre. Kattintson a Hozzáadás gombra, majd válassza a kiszolgáló hitelesítése lehetőséget. Kattintson az OK gombra, amíg vissza nem tér az új sablon tulajdonságai párbeszédpanelre.
- kattintson a Biztonság fülre. Tartományi számítógépek esetén kattintson az ‘Autoenroll engedélyezése’ jelölőnégyzetre. Kattintson az OK gombra. Zárja be a Tanúsítványsablonok konzolt.
- a certsrv beépülő modulban kattintson a jobb gombbal a Tanúsítványsablonok elemre, majd válassza az Új, majd a kiadni kívánt tanúsítványsablon lehetőséget.
- válassza az ügyfél-kiszolgáló hitelesítés lehetőséget, majd kattintson az OK gombra.
ez látható lesz a tanúsítvány megtekintésekor a’ tanúsítványok ‘MMC beépülő modulban, az alábbiak szerint:
amikor megnyitja a tanúsítványt, az ‘Általános’ fül tartalmazza a tanúsítvány célját is, hogy ‘szerver hitelesítés’ legyen, amint az alább látható:
ennek érvényesítésének másik módja az lenne, ha a tanúsítvány ‘Részletek’ szakaszába lépne, és megnézné a ‘továbbfejlesztett kulcshasználat’ tulajdonságot:
a tanúsítvány megszerzésének legegyszerűbb módja az Active Directory tanúsítványszolgáltatások használata, ha vezérli a csatlakozó ügyfélgépeket. Saját tanúsítványokat kérhet és telepíthet, és azokat a tartomány minden gépe megbízhatja.
ha engedélyezni kívánja a felhasználók számára, hogy külső kapcsolatot létesítsenek, és nem lesznek a tartomány részei, akkor nyilvános hitelesítésszolgáltatótól kell telepítenie a tanúsítványokat. Példák, de nem kizárólag: GoDaddy, Verisign, Entrust, Thawte, DigiCert
most, hogy tudja, milyen típusú tanúsítványra van szüksége, beszéljünk a tanúsítvány tartalmáról.
A Windows 2008/2008 R2 rendszerben a farm nevéhez csatlakozik, amely a DNS-körmérkőzés szerint először az átirányítóhoz, a kapcsolatközvetítő mellett, végül pedig a munkamenetet fogadó szerverhez kerül.
Windows 2012 rendszerben a Kapcsolatközvetítőhöz csatlakozik, és a gyűjtemény nevével irányítja a gyűjteményhez.
a telepített tanúsítványoknak rendelkezniük kell egy olyan tárgynévvel vagy alternatív névvel, amely megegyezik annak a kiszolgálónak a nevével, amelyhez a felhasználó csatlakozik. Így például a közzétételhez a tanúsítványnak tartalmaznia kell a gyűjtemény összes RDSH-kiszolgálójának nevét. Az RDWeb tanúsítványának tartalmaznia kell az URL FQDN-jét, azon név alapján, amelyhez a felhasználók csatlakoznak. Ha a felhasználók kívülről csatlakoznak, akkor ennek külső névnek kell lennie (meg kell egyeznie azzal, amelyhez csatlakoznak). Ha a felhasználók belsőleg csatlakoznak az RDweb-hez, a névnek meg kell egyeznie a belső névvel. Egyszeri bejelentkezéshez, ismét a tárgy nevének meg kell egyeznie a gyűjtemény szervereivel.
példánkban vegyük fontolóra, hogy az RDS telepítésem a következő gépeket tartalmazza:
RDSH1.RENDER.COM Session Host konfigurált Távoli alkalmazásokkal
RDSH2.RENDER.COM Session Host távoli alkalmazások konfigurálva
RDVH1.RENDER.COM virtualizációs gazdagép VDI virtuális gépekkel konfigurálva
RDVH2.RENDER.COM virtualizációs gazdagép VDI virtuális gépekkel konfigurálva
RDCB.RENDER.COM kapcsolat bróker
RDWEB.RENDER.COM RDWeb és Gateway server
amikor az ügyfelem belsőleg csatlakozik, beírja a weblapot tároló szerver FQDN-jét, azaz: RDWEB.RENDER.COM.
a tanúsítvány nevének ennek a névnek kell lennie, annak az URL-nek, amelyhez a felhasználó kezdeményezni fogja a kapcsolatot. De emlékeznünk kell arra, hogy a kapcsolat nem csak itt ér véget. A kapcsolat ezután a webszerverről az egyik munkamenet-gazdagépre vagy virtualizációs gazdagépre, valamint a kapcsolatközvetítőre áramlik.
a tanúsítvány minden ilyen kiszolgálón gyakori lehet. Ezért javasoljuk, hogy a tanúsítvány tárgy alternatív neve tartalmazza a telepítés részét képező összes többi kiszolgáló nevét.
röviden, a környezetem tanúsítványa a következő lenne:
Típus: szerver hitelesítés
név: RDWEB.RENDER.COM
SAN: RDSH1.RENDER.COM; RDSH2.RENDER.COM; RDVH1.RENDER.COM; RDVH2.RENDER.C; RDCB.RENDER.COM
ez minden, amire szüksége van, amíg 5 vagy kevesebb szerver van a telepítésben. De van egy probléma, amikor több szerver van a telepítésben. Ez azért van, mert a San (Subject Alternate Name) a tanúsítványon csak 5 kiszolgálónevet tartalmazhat. Ha több van belőlük, be kell szereznie egy helyettesítő tanúsítványt, amely a telepítés összes szerverét lefedi. Itt a tanúsítványom a következőképpen változik:
Típus: szerver hitelesítés
név: RDWEB.RENDER.COM
SAN: *.RENDER.COM
a következő forgatókönyvvel kapcsolatban még mindig vannak kihívások. Ne feledje, hogy ez csak akkor igaz, ha külső felhasználók férnek hozzá a telepítéshez.
külső név: RDWEB.RENDER.com
belső név: RDWEB.RENDER.helyi
itt, ha kap egy tanúsítványt RDWEB.RENDER.COM a névben a tanúsítványhibák továbbra is megjelennek. Ez azért van, mert a tanúsítványnak egy kiszolgálót kell érvényesítenie az FQDN-vel: ‘RDWEB.RENDER.COM’. a szerver azonban ‘ RDWEB.RENDER.Helyi ‘és a’. com ‘to’.helyi ‘ varázslat csak a nyilvános tűzfalon/útválasztón történik porttovábbítással (a leggyakoribb forgatókönyv).
ilyen esetekben korábban azt javasoltuk, hogy a tanúsítványon szereplő név tartalmazza a.com nevet, a SAN pedig a ‘nevet.helyi név.
a közelmúltban minden nyilvános tanúsítványszolgáltató leállítja a tanúsítványok kiadását a’.Helyi ‘ bennük. A Windows 8-tól és a Windows Server 2012-től kezdve már nincs szükségünk a külső és belső nevekre a tanúsítványban.
olyan esetekben, amikor külső ügyfelek csatlakoznak, és van egy privát belső tartomány utótagja (tartomány.Helyi), akkor kap egy igazolást a nyilvános CA a külső (RDWEB.DOMAIN.COM) nevezze el és kösse össze a RD Web Access és RD Gateway szerepkörökkel, mert csak ezek a szerepkörök vannak kitéve az internetnek. Az RD Connection Broker-Publishing és az RD Connection Broker-Enable Single Sign On esetén használhat egy belső tanúsítványt a ‘domainnel.Helyi neve van rajta. Ez azonban, amint azt korábban említettük, csak az RDC 8.0 vagy újabb rendszeren keresztül csatlakozó ügyfelekkel fog működni.
az RD Gateway és a Remote Desktop Client 8.0 (és újabb) verziója biztonságos kapcsolatot biztosít a külső felhasználók számára a telepítéshez. Miután csatlakozott a telepítéshez, a belső tanúsítvány a’.a helyi név gondoskodik a távoli alkalmazás-aláírásról (közzétételről) és az egyszeri bejelentkezésről.
most nézzük meg, hol konfiguráljuk a tanúsítványt:
nyissa meg a Kiszolgálókezelőt a Connection Broker kiszolgálón, majd kattintson a Távoli asztali szolgáltatások elemre a bal oldali ablaktáblában.
itt egyszer látni fogja a telepítést az alábbi ábrán látható módon. Kattintson a Feladatok elemre, majd válassza a “telepítési tulajdonságok szerkesztése “lehetőséget”
Ez megjeleníti a telepítés tulajdonságlapját. Válassza a tanúsítványok lehetőséget a bal oldali ablaktáblán:
Most, amint azt korábban tárgyaltuk, kiválaszthatja a létrehozott tanúsítványt a képernyő alján található ‘meglévő tanúsítvány kiválasztása’ gombbal.
csak mutasson rá a’.pfx fájlt, és lehetővé teszi, hogy importálja a tanúsítványt a szerepkör.
egyetlen tanúsítványt használhat az összes szerepkörhöz, ha az ügyfelek csak a tartományon belül vannak, egy egyszerű helyettesítő tanúsítvány (*.RENDER.Helyi), és minden szerephez kötődik.
ne feledje, hogy még ha több kiszolgálója is van, amelyek a telepítés részét képezik, a Kiszolgálókezelő importálja a tanúsítványt a telepítés összes kiszolgálójára, elhelyezi őket a gépek megbízható gyökerében, és összekapcsolja őket a megfelelő szerepkörökkel.
– Kiran Kadaba
