po raz pierwszy opublikowane w TECHNET w styczniu 24, 2014
Dzień dobry AskPerf! Kiran z pytaniem do ciebie: po co nam certyfikaty? Certyfikaty są używane do podpisywania komunikacji między dwoma maszynami. Gdy klient łączy się z serwerem, tożsamość serwera, który odbiera połączenie, a tym samym informacje od klienta, są weryfikowane za pomocą certyfikatów.
ma to na celu zapobieganie ewentualnym atakom typu man-in-the-middle. Gdy kanał komunikacji jest ustawiony między Klientem a serwerem, organ, który wystawia / generuje certyfikat, poświadcza, że serwer jest autentyczny.
tak więc, o ile klient ufa serwerowi, z którym się komunikuje, dane wysyłane do i z serwera są uważane za bezpieczne. To prowadzi mnie do następnego pytania:
jaki rodzaj certyfikatu jest wymagany dla RDS?
poniższy blog zawiera informacje dotyczące typu certyfikatów i sposobu ich tworzenia przy użyciu wewnętrznego urzędu certyfikacji domeny.
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
podstawowe wymagania dotyczące certyfikatów pulpitu zdalnego:
- certyfikat jest instalowany w „osobistym” magazynie certyfikatów komputera.
- certyfikat posiada odpowiedni klucz prywatny.
- rozszerzenie „Enhanced Key Usage „ma wartość” Server Authentication „lub” Remote Desktop Authentication ” (1.3.6.1.4.1.311.54.1.2). Można również używać certyfikatów bez rozszerzenia „Enhanced Key Usage”.
ponieważ funkcja, którą wykonuje, sugeruje, że potrzebujemy certyfikatu 'Server Authentication’. Certyfikat ten można wygenerować za pomocą szablonu „uwierzytelnianie stacji roboczej” (jeśli jest to wymagane).
oto dokładny proces:
- Otwórz CERTSRV.MSC i konfiguracja certyfikatów.
- Otwórz Urząd Certyfikacji.
- w okienku SZCZEGÓŁY rozwiń nazwę komputera instruktora.
- kliknij prawym przyciskiem myszy Szablony certyfikatów i wybierz Zarządzaj. Kliknij prawym przyciskiem myszy uwierzytelnianie stacji roboczej i kliknij duplikat szablonu.
- na karcie Ogólne Zmień nazwę wyświetlania szablonu na uwierzytelnianie klient-serwer i sprawdź Opublikuj certyfikat w Active Directory.
- na karcie Rozszerzenia kliknij zasady aplikacji, a następnie Edytuj. Kliknij Dodaj, a następnie wybierz Uwierzytelnianie serwera. Kliknij OK, aż wrócisz do okna dialogowego Właściwości nowego szablonu.
- kliknij kartę Zabezpieczenia. W przypadku komputerów z domeną kliknij pole wyboru „Zezwalaj na Autoenrolowanie”. Kliknij OK. Zamknij konsolę szablonów certyfikatów.
- w przystawce certsrv kliknij prawym przyciskiem myszy Szablony certyfikatów i wybierz nowy, a następnie szablon certyfikatu do wydania.
- Wybierz uwierzytelnianie klient-serwer, a następnie kliknij OK.
będzie to widoczne podczas wyświetlania certyfikatu w przystawce MMC „certyfikaty”, jak poniżej:
po otwarciu certyfikatu zakładka „Ogólne” będzie również zawierać cel tego certyfikatu jako „uwierzytelnianie serwera”, jak pokazano poniżej:
innym sposobem sprawdzenia tego jest przejście do sekcji „Szczegóły” certyfikatu i zapoznanie się z właściwością „ulepszone użycie klucza”:
najprostszym sposobem uzyskania certyfikatu, jeśli kontrolujesz maszyny klienckie, które będą się łączyć, jest użycie usług certyfikatów Active Directory. Możesz zażądać i wdrożyć własne certyfikaty, które będą zaufane przez każdą maszynę w domenie.
jeśli chcesz umożliwić użytkownikom łączenie się zewnętrznie, a nie będą oni częścią twojej domeny, musisz wdrożyć certyfikaty z publicznego urzędu certyfikacji. Przykłady, w tym między innymi: GoDaddy, Verisign, Entrust, Thawte, DigiCert
teraz, gdy wiesz, jakiego typu certyfikatu potrzebujesz, porozmawiajmy o jego zawartości.
w systemie Windows 2008/2008 R2 łączysz się z nazwą farmy, która zgodnie z DNS round robin zostaje najpierw przekierowana do redirector, obok brokera połączeń, a na końcu do serwera, który będzie obsługiwał Twoją sesję.
w systemie Windows 2012 łączysz się z brokerem połączeń i przekierowuje Cię do kolekcji za pomocą nazwy kolekcji.
wdrożone certyfikaty muszą mieć nazwę tematu lub alternatywną nazwę tematu, która odpowiada nazwie serwera, z którym łączy się użytkownik. Na przykład do publikacji certyfikat musi zawierać nazwy wszystkich serwerów RDSH w kolekcji. Certyfikat dla RDWeb musi zawierać FQDN adresu URL w oparciu o nazwę, z którą łączą się użytkownicy. Jeśli masz użytkowników łączących się zewnętrznie, musi to być nazwa zewnętrzna (musi pasować do tego, z czym się łączą). Jeśli masz użytkowników łączących się wewnętrznie z RDweb, nazwa musi być zgodna z nazwą wewnętrzną. W przypadku jednokrotnego logowania Nazwa tematu musi być zgodna z serwerami w kolekcji.
w naszym przykładzie rozważ, że moje wdrożenie RDS zawiera następujące maszyny:
RDSH1.RENDER.COM Host sesji z skonfigurowanymi aplikacjami zdalnymi
RDSH2.RENDER.COM Host sesji ze zdalnymi aplikacjami skonfigurowany
RDVH1.RENDER.Host wirtualizacji COM z skonfigurowanymi maszynami wirtualnymi VDI
RDVH2.RENDER.COM host wirtualizacji z skonfigurowanymi maszynami wirtualnymi VDI
RDCB.RENDER.COM Broker połączeń
RDWEB.RENDER.COM RDWeb i serwer Gateway
gdy mój klient połączy się wewnętrznie, wejdzie do FQDN serwera, na którym znajduje się strona internetowa, tj.: RDWEB.RENDER.COM.
nazwa certyfikatu musi być nazwą adresu URL, do którego użytkownik zainicjuje połączenie. Ale musimy pamiętać, że połączenie nie kończy się tylko tutaj. Połączenie następnie przepływa z serwera www do jednego z hostów sesji lub hostów wirtualizacji, a także brokera połączeń.
certyfikat może być wspólny dla wszystkich tych serwerów. Dlatego zalecamy, aby alternatywna nazwa tematu certyfikatu zawierała nazwy wszystkich innych serwerów, które są częścią wdrożenia.
w skrócie, certyfikat dla mojego środowiska będzie następujący:
Typ: Uwierzytelnianie serwera
Nazwa: RDWEB.RENDER.COM
SAN: RDSH1.RENDER.COM; RDSH2.RENDER.COM; RDVH1.RENDER.COM; RDVH2.RENDER.Kom; RDCB.RENDER.COM
to wszystko, czego potrzebujesz, o ile masz 5 lub mniej serwerów we wdrożeniu. Ale mamy problem, gdy mamy więcej serwerów we wdrożeniu. Dzieje się tak dlatego, że z założenia SAN (Subject Alternate Name) na certyfikacie może zawierać tylko 5 nazw serwerów. Jeśli masz ich więcej, musisz uzyskać certyfikat wieloznaczny, który obejmuje wszystkie serwery we wdrożeniu. Tutaj mój certyfikat zmienia się następująco:
Typ: Uwierzytelnianie serwera
Nazwa: RDWEB.RENDER.COM
SAN: *.RENDER.COM
wciąż napotykamy pewne wyzwania, jeśli chodzi o następujący scenariusz. Pamiętaj, że jest to prawdą tylko wtedy, gdy masz zewnętrznych użytkowników, którzy uzyskują dostęp do wdrożenia.
RDWEB.RENDER.com
Nazwa wewnętrzna: RDWEB.RENDER.lokalny
tutaj, jeśli otrzymasz certyfikat z RDWEB.RENDER.COM w nazwie nadal pojawiają się błędy certyfikatu. To dlatego, że certyfikat ma zweryfikować serwer z FQDN: 'RDWEB.RENDER.COM’. jednak twoim serwerem jest ’ RDWEB.RENDER.Lokalne „i”. com „do”.lokalna magia dzieje się tylko na Twojej publicznej zaporze / routerze przy użyciu przekierowania portów (najczęstszy scenariusz).
w takich scenariuszach wcześniej zalecaliśmy, aby nazwa na certyfikacie zawierała nazwę ’.com’, a SAN ’.lokalna nazwa.
ostatnio wszyscy dostawcy certyfikatów publicznych przestają wystawiać certyfikaty za pomocą”.Lokalne w nich. Począwszy od Windows 8 i Windows Server 2012, nie potrzebujemy już zewnętrznych i wewnętrznych nazw zawartych w certyfikacie.
w scenariuszach, w których masz klientów zewnętrznych łączących się i masz prywatny sufiks domeny wewnętrznej (domena.Lokalne), można uzyskać certyfikat z publicznego urzędu certyfikacji z zewnętrznym (RDWEB.DOMAIN.COM) nazwij go i powiązaj z rolami dostępu do sieci Web i bramy usług pulpitu zdalnego, ponieważ są to jedyne role, które są wystawione na działanie Internetu. W przypadku brokera połączeń usług pulpitu zdalnego-Publishing i brokera połączeń usług pulpitu zdalnego-Enable Single Sign On, możesz skorzystać z wewnętrznego certyfikatu za pomocą domeny.Jest na niej nazwisko. To jednak, jak wspomniano wcześniej, będzie działać tylko z klientami łączącymi się przez RDC 8.0 lub wyżej.
Brama usług pulpitu zdalnego i klient pulpitu zdalnego w wersji 8.0 (lub nowszej) zapewniają użytkownikom zewnętrznym bezpieczne połączenie z wdrożeniem. Po podłączeniu do wdrożenia, wewnętrzny certyfikat z”.nazwa lokalna zajmie się zdalnym podpisywaniem aplikacji (publikowaniem) i jednokrotnym logowaniem.
teraz przyjrzyjmy się, gdzie konfigurujemy certyfikat, który mamy:
Otwórz Menedżera serwera na serwerze brokera połączeń i kliknij Usługi pulpitu zdalnego w lewym górnym okienku.
po kliknięciu tutaj zobaczysz swoje wdrożenie pokazane jak na poniższej ilustracji. Kliknij zadania i wybierz „Edytuj Właściwości wdrażania”
to spowoduje wyświetlenie arkusza właściwości rozmieszczenia. Wybierz opcję certyfikaty w lewym okienku:
teraz, jak wspomniano wcześniej, możesz wybrać utworzony certyfikat za pomocą przycisku „Wybierz istniejący certyfikat” u dołu ekranu.
po prostu wskaż to”.plik pfx i pozwolić na import certyfikatu dla roli.
możesz użyć jednego certyfikatu dla wszystkich ról, jeśli twoi klienci są tylko wewnętrzni w domenie, generując prosty certyfikat wieloznaczny (*.RENDER.Lokalny) i wiążąc go ze wszystkimi rolami.
zauważ, że nawet jeśli masz wiele serwerów, które są częścią tego wdrożenia, Menedżer serwera zaimportuje certyfikat do wszystkich serwerów we wdrożeniu, umieści je w zaufanym katalogu głównym maszyn i powiąże je z odpowiednimi rolami.
– Kiran Kadaba
