Remote Desktop Services — zarządzanie usługami pulpitu zdalnego

Protokół RDP w typowym scenariuszu zapewnia możliwość dostępu do pulpitu zdalnego. To wyjątkowo dobre rozwiązanie m.in. dlatego, że działa w trybie graficznym, więc zwykle nie ma problemów z jego obsługą przez osoby mniej techniczne. Dobrym przykładem wykorzystania RDP jest praca w modelu hybrydowym — niezależnie, czy wyniki naszej pracy powstaną w domu, czy we firmie, będą dostępne na jednym fizycznym urządzeniu, co ułatwia dostęp do nich. Pracownik w domu łączy się z firmową siecią VPN, po czym z wykorzystaniem lokalnego adresu IP bądź nazwy hosta w domenie uzyskuje dostęp do swojego służbowego komputera.

Może zaistnieć potrzeba, aby umożliwić dostęp do wybranej aplikacji lub konkretnego systemu szerszej grupie osób, które przykładowo nigdy nie pojawiają się w firmie lub są całkowicie spoza struktury organizacji. W tym celu sprawdza się rola Remote Desktop Services dostępna w Windows Server. Najbardziej podstawowe wykorzystanie dotyczy jednego serwera. Natomiast w większych konfiguracjach można utworzyć klaster serwerów RDP, co pozwoli na równoważenie obciążenia maszyn, a dodatkowo może zapewnić podstawową ciągłość działania podczas niedostępności części serwerów. Bez wdrożenia licencji dostępowej usługa RDS będzie działać przez 120 dni.

Konfiguracja dla jednego serwera

W tym przypadku wszystkie niezbędne do działania usługi są po prostu instalowane na jednym serwerze, nie są rozproszone w porównaniu z klastrem RDP. Z poziomu Server Manager uruchamiamy Add Roles and Features Wizard. Najszybciej zainstalować potrzebne usługi wybierając Remote Desktop Services installation jako installation type. Używamy jednego serwera, dlatego w kolejnym kroku określamy deployment type jako Quick Start.

Pojawi się wybór deployment scenario. Nie zamieramy korzystać z maszyn wirtualnych (używany w tym celu jest Hyper-V), stąd zaznaczamy Session-based desktop deployment. Jeśli nie dodawaliśmy wcześniej puli serwerów instalacja usług będzie możliwa wyłącznie na aktualnym hoście. W trakcie instalacji serwer zostanie ponownie uruchomiony.

Po zakończeniu instalacji w Server Manager pojawi się zakładka Remote Desktop Services. Otwieramy w niej RD Gateway, wskazujemy nasz serwer, po czym określamy domenę, pod jaką RDS będzie dostępny. Niezbędna jest konfiguracja certyfikatu self-signed używanego do wewnętrznej komunikacji pomiędzy usługami RDS. Wystarczy w TASKS wybrać Edit Deployment Properties i rozwinąć kartę Certificates. Tworzymy jeden certyfikat i konfigurujemy dla każdej z czterech widocznych usług, czyli Connection Broker (funkcje SSO i Publishing), Web Access oraz Gateway.

Pod adresem <domena>/RDWeb dostępny będzie panel usługi przeznaczony dla użytkowników. Niestety jego wygląd może nie sprawiać dobrego wrażenia.

To domyślnie instalowana wersja, która dodatkowo nie umożliwia połączenia RDP z użyciem przeglądarki. Możemy wyłącznie pobierać pliki konfiguracyjne, które następnie uruchamiamy w lokalnych klientach RDP. Istnieje jednak możliwość instalacji bardziej współczesnej wersji, która zdecydowanie lepiej wygląda.

Uruchamiamy PowerShell i wykonujemy:

Install-Module -Name PowerShellGet -Force

Zamykamy bieżące okno i ponownie uruchamiamy PowerShell, po czym wykonujemy kolejno:

Install-Module -Name RDWebClientManagement
Install-RDWebClientPackage

Teraz pojawia się inny problem. Musimy poleceniem Import-RDWebClientBrokerCert zaimportować wygenerowany wcześniej certyfikat. Jest on w formacie PFX i zabezpieczony hasłem, co było wymagane. Wspomniane polecenie nie obsługuje jednak haseł, dlatego musimy „odhasłować” istniejący certyfikat. Rozwiązaniem będzie konwersja do formatu CRT. Po tej czynności import powinien zadziałać, więc wykonujemy ostatnie polecenia:

Import-RDWebClientBrokerCert /sciezka/do/pliku/crt
Publish-RDWebClientPackage -Type Production -Latest

W ten sposób udało nam się uruchomić nową wersję panelu pod adresem <domena>/rdweb/webclient. Na tym etapie usługa będzie poprawnie działać, ale warto zmienić konfigurację serwera IIS. Przede wszystkim używany jest certyfikat self-signed, więc w przypadku zewnętrznych przeglądarek pojawi się odpowiedni komunikat o braku prywatnego połączenia. Jeśli zamierzamy tę usługę wystawić publicznie, należy pamiętać o skorzystaniu z właściwego certyfikatu. Połączenie nieszyfrowane w RDS nie jest możliwe do realizacji.

IIS obsługuje jedynie format PFX certyfikatów. Plik importujemy w karcie Server Certificates. Nasza usługa działa w ramach domyślnej witryny, dlatego w jej widoku w menu Actions wybieramy Bindings… i wskazujemy zaimportowany certyfikat dla portu 443.

Można w tym samym miejscu zauważyć, że nie została zdefiniowana nazwa serwera. Oznacza to dostępność panelu RDS nie tylko w ramach naszej domeny, ale także adresu IP serwera oraz każdej innej domeny na niego wskazującej, o ile nie została dodana do osobnej witryny w IIS. RDS co prawda działa poprawnie nawet w takiej konfiguracji, ale wciąż przeglądarki będą wyświetlać błędy, ponieważ certyfikat nie obejmuje przykładowo adresu IP. Z tego względu warto ustawić, aby Host Name wskazywał na prawidłową domenę, co zapobiegnie takim sytuacjom.

Przydatne może być również dodanie przekierowań. Aktualnie wejście na domenę bez podania pełnego adresu /rdweb/webclient/ zwróci domyślną stronę „powitalną” IIS. Dodatkowo starsza wersja panelu cały czas pozostaje dostępna po wejściu na /rdweb. Należy więc dodać przekierowania 301 dla Default Web Site oraz dla lokalizacji /RDWeb/Pages/en-US do /rdweb/webclient/.

Dzięki tym czynnościom uzyskamy solidnie działającą usługę. W panelu RDS domyślnie do wykorzystania będą dostępne aplikacje Kalkulator, Paint i WordPad. Dodanie innych programów ogranicza się do przejścia w Server Manager -> Remote Desktop Services -> Collections -> QuickSessionCollection i dalej TASKS -> Publish RemoteApp Programs. Zostanie wyświetlona lista zainstalowanych aplikacji, z której wybieramy interesujące nas pozycje. Możemy ułatwić pracę użytkownikom, dodając także explorer.exe (należy przejść do folderu Windows po wybraniu Add…), ale trzeba pamiętać, że udostępni to możliwość uruchomienia innych narzędzi, co nie zawsze będzie pożądane.

Korzystanie z RDS po stronie użytkownika jest bardzo wygodne. Logujemy się z użyciem poświadczeń domenowych, po czym zobaczymy listę aplikacji do uruchomienia.

Każdy wybór aplikacji zostanie poprzedzony pytaniem o możliwość dostępu do lokalnego schowka, mikrofonu, drukarki i opcji pozwalającej na transfer plików. Oczywiście można uruchomić wiele aplikacji jednocześnie.

W tej sytuacji nie ma potrzeby, aby wystawiać na zewnątrz usługę RDP. Serwer może działać całkowicie lokalnie. Korzystając przykładowo z mechanizmu Virtual IP wystarczy zezwolić jedynie na ruch HTTP/HTTPS i przekierować go do lokalnej maszyny.

Klaster serwerów RDP

Z technicznej perspektywy to interesujący temat, a przy tym mimo wszystko stosunkowo łatwy do implementacji. W porównaniu do poprzedniego podejścia klaster nie ogranicza nas wyłącznie do poziomu pojedynczych aplikacji — użytkownicy końcowi uzyskują standardowy dostęp RDP. Ich dane są synchronizowane pomiędzy węzłami klastra. Zakładając dodatkowo użycie profili mobilnych, otrzymujemy możliwość synchronizacji także do zwykłych komputerów osobistych.

Aby utworzyć klaster w pierwszej kolejności musimy dodać serwery do Server Manager, co pozwoli na zarządzanie nimi z jednego miejsca. Wybieramy więc Add other servers to manage. Wskazujemy odpowiednie hosty z widocznej listy. W naszym przykładzie utworzymy klaster składający się z dwóch maszyn, a trzecia będzie pełniła rolę brokera połączeń i zapewniała dostęp klientom końcowym.

Analogicznie do poprzedniego opisu należy teraz zainstalować odpowiednie role. Natomiast można się domyślić, że procedura wygląda trochę inaczej. Jako deployment type wybieramy Standard deployment. Następny kluczowy krok to przydzielenie odpowiednich ról do właściwych maszyn. W naszym przypadku serwer RDP-WEB przypisujemy do roli Connection Broker i Web Access, a serwery RDP1 oraz RDP2 do Session Host.

Podobnie jak poprzednio instalujemy rolę RD Gateway (oczywiście na serwerze RDP-WEB w naszym przykładzie) oraz dodajemy certyfikaty. Jak wspomniałem wcześniej, dane użytkowników są synchronizowane pomiędzy serwerami. Jest to możliwe w tym przypadku dzięki wykorzystaniu plików wirtualnych dysków (VHDX). Konieczne będzie utworzenie folderu udostępnionego służącego do ich przechowywania.

Przechodzimy do zakładki Collections i w sekcji o tej samej nazwie wybieramy TASKS -> Create Session Collection. Nadajemy nazwę nowej kolekcji, określamy powiązane serwery, grupę użytkowników i lokalizację sieciową dla plików wirtualnych dysków oraz ich maksymalny rozmiar. Rozpocznie się tworzenie kolekcji.

Pozostałe czynności do wykonania są w zasadzie spójne ze zwykłą konfiguracją. Warto zainstalować nowszą wersję panelu, zaimportować poprawny certyfikat SSL i dodać odpowiednie przekierowania w IIS.

W Collections widoczne będą aktualne sesje oraz hosty, które je obsługują. Jeśli wystąpi „awaria” danego hosta, nowe połączenia po pewnym czasie zostaną przekierowane do działających węzłów. Dane powinny zostać zachowane, o ile użytkownik regularnie zapisuje zmiany w plikach.

Poniższy widok pozwala także na zdalne wylogowanie użytkownika, wysłanie do niego komunikatu czy podłączenie się do jego sesji, co umożliwi podgląd wykonywanych przez niego czynności lub pełny dostęp (Shadow).

Zaznaczę, że korzystanie z trybu shadow wymaga zmiany konfiguracji Windows Firewall. Wystarczy aktywować regułę Remote Desktop - Shadow (TCP-In). Domyślnie włączone będą prawdopodobnie tylko reguły dla RDS, co jednak nie umożliwi działania tej opcji.

Podsumowanie

Konfiguracja usługi RDS nie jest znacznie skomplikowana, a pozwala na sprawną obsługę połączeń RDP. Dzięki temu rozwiązaniu można bezpiecznie udostępnić dostęp do konkretnych zasobów lub całego systemu w ramach sieci firmowej. Zastosowanie wirtualnych dysków czy profili mobilnych umożliwia również synchronizację danych pomiędzy urządzeniami.