Jak zaprzyjaźnić się z Windows Server Core – część 5

Od pewnego czasu można w zasadzie powiedzieć, że wraz z premierą Windows Server 2012 podejście firmy Microsoft do zarządzania serwerami uległo zmianie –  zredukowano możliwości zarządzania i konfiguracji z interfejsu graficznego. Obecnie wiele funkcjonalności serwerowych jest konfigurowanych i zarządzanych wyłącznie za pomocą PowerShell. Jednym z kluczowych rozwiązań tego narzędzia jest możliwość administracji zdalnej, czyli PowerShell Remoting.

Uwaga: artykuł dotyczy wyłącznie korzystania z funkcjonalności PowerShell Remoting w środowisku Active Directory.

PowerShell Remoting

PowerShell Remoting  opiera się na implementacji protokołu Web Services for Management (WSMan) firmy Microsoft i używa usługi Windows Remote Management (WinRM) do zarządzania komunikacją i uwierzytelnianiem.  Struktura ta została zaprojektowana jako bezpieczna i niezawodna metoda zarządzania komputerami, oparta na dobrze znanych standardach, takich jak Simple Object Access Protocol (SOAP) i Hypertext Transfer Protocol (HTTP).

Niektóre polecenia cmdlet udostępniają możliwości komunikacji zdalnej poprzez parametr „ComputerName”, ale większość z nich  nie obsługuje samodzielnie komunikacji zdalnej. Dzięki PowerShell Remoting mamy do dyspozycji środowisko zdalne, które umożliwia zdalne wykonanie dosłownie każdego polecenia, które można uruchomić w lokalnym PowerShell. Dzięki temu, zamiast dodawać możliwości komunikacji zdalnej do każdego pojedynczego polecenia cmdlet, czy też własnego skryptu, możemy umożliwić powłoce PowerShell wysłanie kodu na komputery docelowe, wykonanie go tam, a następnie przekazanie wyników.

Krótki przegląd PowerShell Remoting

• Korzysta z protokołu WS-MAN, używając HTTP (domyślnie) lub HTTPS.
• Działa w oparciu o usługę WinRM.
• Usługa WinRM jest domyślnie włączona w systemach Windows Server, począwszy od Windows Server 2012.
• Reguła Windows Defender Firewall jest domyślnie skonfigurowana, tak aby umożliwić komunikację wyłącznie na profilu domenowym i prywatnym dla usługi WinRM.
• Dla komunikacji zdalnej wymagany jest Windows PowerShell 2.0 lub nowszy (w Windows 10 i Windows Server 2019/2022 jest to wersja 5.1)
• PowerShell Remoting nie jest domyślnie włączony na klienckim systemie operacyjnym – można go skonfigurować za pomocą zasad grupy albo  polecenia cmd: „winrm qc” lub cmdlet: „Enable-PSRemoting -Force”.
• Musi być włączony na każdym systemie, który będzie odbierał połączenia przychodzące.
• Dla komunikacji po HTTP korzysta z portu 5985, natomiast dla komunikacji HTTPS  –  z portu 5986.

Architektura PowerShell Remoting

PowerShell Remoting korzysta z usługi WinRM, która zarządza komunikacją z innymi aplikacjami,  w tym obsługuje komunikację dla 64-bitowego i 32-bitowego programu Windows PowerShell oraz innych aplikacji korzystających z tej usługi, między innymi Server Manager i Windows Admin Center, o których pisałem wcześniej.

Usługa WinRM rejestruje jednego lub więcej słuchaczy (Listeners). Każdy odbiornik akceptuje ruch przychodzący za pośrednictwem protokołu HTTP lub HTTPS i może być powiązany z jednym lokalnym adresem IP, lub wieloma adresami IP. Ruch przychodzący zawiera nagłówek pakietu, który wskazuje punkt końcowy. Każdy z tych punktów jest skojarzony z określoną aplikacją, a gdy ruch kieruje się do punktu końcowego, usługa WinRM uruchamia skojarzoną aplikację, przekazuje ruch przychodzący i czeka, aż aplikacja zakończy swoje zadanie.  Może ona przekazywać dane z powrotem do usługi WinRM, który przesyła je ponownie do komputera, z którego zadanie zostało zlecone. Program Windows PowerShell potrafi zarejestrować wiele punktów końcowych za pomocą usługi WinRM.  Można także tworzyć własne niestandardowe punkty końcowe, które mają przypisane bardzo precyzyjne uprawnienia i możliwości.

Security PowerShell Remoting

Domyślnie punkty końcowe utworzone przez program Windows PowerShell zezwalają na połączenia tylko przez członków określonej grupy. W systemie Windows istnieją dwie grupy: Remote Management Users i local Administrators. Każdy punkt końcowy ma listę kontroli dostępu do systemu (SACL), którą da się zmienić, aby dokładnie kontrolować, kto może się z nim połączyć. Domyślnym zachowaniem zdalnym jest delegowanie poświadczeń logowania do komputera zdalnego. Komputer zdalny korzysta z poświadczeń użytkownika i w jego imieniu wykonuje określone zadania. Jeśli jest włączona inspekcja, zadania zdalne będą rejestrowane również w Podglądzie Zdarzeń.

Delegowanie poświadczeń do komputera zdalnego wiąże się z pewnymi zagrożeniami bezpieczeństwa. Z tego powodu domyślna komunikacja zdalna wymaga wzajemnego uwierzytelniania, które zapewnia łączenie się z docelowym komputerem. Uwierzytelnianie wzajemne jest natywną funkcją protokołu uwierzytelniania Kerberos usługi Active Directory, a podczas łączenia się między komputerami zaufanej domeny wzajemne uwierzytelnianie odbywa się automatycznie. Kiedy łączysz się z komputerami spoza domeny, musisz zapewnić inną formę wzajemnego uwierzytelniania w formie certyfikatu SSL (a także protokołu HTTPS, który należy wcześniej skonfigurować) lub wyłączyć wymaganie wzajemnego uwierzytelniania, dodając komputer zdalny do lokalnej listy TrustedHosts.

PowerShell Remoting w podstawowej konfiguracji wykorzystuje protokół HTTP, który nie zapewnia prywatności (szyfrowania) treści komunikacji, ale PowerShell domyślnie stosuje szyfrowanie na poziomie aplikacji. W środowisku domeny korzystającym z domyślnego protokołu uwierzytelniania Kerberos poświadczenia są wysyłane w postaci zaszyfrowanych biletów Kerberos, które nie zawierają haseł. Kiedy musimy połączyć się ze zdalnym komputerem , wykonujemy to za pomocą adresu IP lub aliasu DNS oraz konfigurujemy połączenie, używając protokołu HTTPS (co będzie przedmiotem kolejnego artykułu).

Połączenie do sesji zdalnej

Wyróżniamy trzy metody podłączenia do sesji zdalnej (w tym artykule interesują nas wyłącznie dwie pierwsze opcje):

1. One-to-One
2. One-to-Many (fan-out)
3. Many-to-One (fan-in)

One-to-One

Jeśli potrzebujemy, aby nasza sesja zdalna była interaktywna, konfigurujemy komunikację zdalną jeden do jednego. Wpisujemy polecenia na komputerze lokalnym, który w celu wykonania przesyła je następnie do zdalnego komputera. Wyniki są serializowane w formacie XML i przesyłane z powrotem do komputera, który następnie deserializuje je do obiektów i umieszcza w potoku programu PowerShell. W tym przypadku korzystamy z polecenia „Enter-PSSession” w połączeniu z parametrem  „ComputerName”. Aby dostosować sesję połączeniową do wymogów takich jak „UseSSL”, można użyć także innych parametrów. Po nawiązaniu połączenia monit programu Windows PowerShell zmienia się, wskazując nazwę komputera, z którym jesteśmy połączeni. Uruchomienie polecenia „Exit-PSSession” umożliwia zamknięcie z sesji i powrót do lokalnego wiersza polecenia. Jeśli podczas połączenia program PowerShell zostanie zamknięty, to samo stanie się z połączeniem.

To istota PowerShell Remoting jeśli potrzebujemy wykonać zadania na wielu komputerach jednocześnie. Wysyłamy pojedyncze polecenia do wielu komputerów. Każdy komputer wykonuje przesyłane polecenie, serializuje wyniki w formacie XML i przesyła i z powrotem do naszego komputera. Nasz komputer deserializuje kod XML do obiektów, a następnie umieszcza je w potoku PowerShell, dodając do każdego obiektu kilka właściwości, w tym właściwość „PSComputerName”. Wskazuje ona, z którego komputera pochodzi każdy wynik. Ta właściwość umożliwia sortowanie, grupowanie i filtrowanie na podstawie nazwy komputera. Uruchomienie polecenia „Invoke-Command” z parametrem „ComputerName” pozwala wykonać zadanie na wielu zdalnych komputerach.

Throttling

Domyślnie program PowerShell łączy się jednocześnie tylko z 32 komputerami. Jeśli nasza operacja dotyczy więcej niż 32 komputerów, nadmiarowe zostaną umieszczone w kolejce. Gdy komputery początkowe ukończą i zwrócą swoje wyniki, następne z kolejki przechodzą do puli operacyjnej. Można zmienić to zachowanie, używając parametru „ThrottleLimit”. Zwiększenie liczby nie powoduje dodatkowego obciążenia komputerów zdalnych, ale wiąże się z dodatkowym obciążeniem komputera lokalnego i wykorzystuje większą przepustowość. Każde równoległe połączenie jest wątkiem programu PowerShell –  dlatego zwiększenie liczby komputerów przyczynia się do większego wykorzystania pamięci i procesora na komputerze lokalnym.

Podsumowanie

Pomimo że usługa PowerShell Remoting istnieje już od wersji 2.0,  okazuje się, że wielu administratorów i organizacji z niej nie korzysta.  Wynika to w dużej mierze z przestarzałych zasad bezpieczeństwa lub nadmiernego unikania ryzyka.

Trzeba pamiętać, że domyślnie PowerShell nie wykonuje skryptów. Natomiast kiedy to robi, może wykonywać tylko polecenia, do których wykonywania użytkownik ma uprawnienia. Nie korzysta z jakiegoś „super konta” i dlatego też nie może ominąć istniejących uprawnień ani zabezpieczeń. Domyślnie PowerShell Remoting umożliwia administratorom łączenie się z komputerem zdalnym; po połączeniu można wykonywać tylko polecenia, do których dany administrator ma uprawnienia, bez możliwości ominięcia uprawnień lub podstawowych zabezpieczeń. W przeciwieństwie do wcześniejszych narzędzi, które działały na wysoce uprzywilejowanym koncie (takim jak LocalSystem), PowerShell Remoting wykonuje polecenia, działając w imieniu użytkownika, który przesłał polecenie.

Należy również zaznaczyć, że wielu administratorów nadal loguje się do konsoli serwerowej (fizycznie lub za pomocą pulpitu zdalnego), co jest znacznie większym zagrożeniem bezpieczeństwa niż w przypadku korzystania z usługi PowerShell Remoting. PowerShell oferuje lepszą możliwość ograniczenia nawet dla administratorów. Zdalny punkt końcowy można zmodyfikować, aby umożliwić łączenie się z nim tylko określonym użytkownikom.  Po połączeniu użytkownik może być ograniczony tylko do dozwolonych poleceń, co stwarza dosyć precyzyjne możliwości w zakresie  delegowanej administracji.

Oczywiście powyższy artykuł nie wyczerpuje całej tematyki, ale mam nadzieję, że przybliżenie podstawowych zagadnień związanych z PowerShell Remoting  okaże się zachętą do coraz szerszego stosowania tego rozwiązania.  Zwolenników szyfrowania połączenia z wykorzystaniem protokołu SSL zapraszam do kolejnego artykułu, który pojawi się w niedalekiej przyszłości.