PowerShell Remoting najczęściej utożsamiany jest z narzędziem służącym wyłącznie do uruchamiania poleceń na zdalnym serwerze (bądź serwerach) z uprawnieniami identycznymi z tymi, z których korzystamy lokalnie. Istotnie – domyślna końcówka PowerShell Remoting służy dokładnie do tego. Warto jednak wiedzieć, że PowerShell Remoting może znaleźć także inne zastosowania.

Możliwości PS Remoting są szersze, niż się to może wydawać przy pierwszym kontakcie. Remoting może bowiem posłużyć także jako instrument do oferowania użytkownikom uprawnień innych niż domyślne, którzy bez tego narzędzia nie mogliby nawet zalogować się na serwerze. Zanim jednak zagłębimy się w szczegóły implementacji tego typu rozwiązań, przyjrzymy się temu, jak ewoluowały możliwości ich konfiguracji.

Rozwój Remoting

PowerShell Remoting pojawił się po raz pierwszy w drugiej wersji PowerShella. Technologię tę od samego początku wykorzystywano w Microsoft Exchange – i choć sposób tworzenia końcówek różnił się od metody domyślnej, to ograniczenia dostępu były integralnym elementem. Role Based Access Control (RBAC) bazował właśnie na możliwościach oferowanych przez PowerShell Remoting, czyli na tworzeniu końcówek o ograniczonym dostępie. Zwykli administratorzy mogli również stworzyć ograniczone końcówki, wymagało to jednak doskonałej znajomości technologii oraz skrupulatnego odtwarzania środowiska, w którym takie rozwiązanie byłoby możliwe. To wszystko sprawiło, że poza gronem nielicznych entuzjastów rozwiązanie to nie było zbyt popularne.

W wersji trzeciej PowerShella pojawiła się koncepcja „konfiguracji końcówek” oraz możliwość konfigurowania końcówki jako uruchamianej z uprawnieniami wybranego użytkownika. Oznaczało to zdecydowanie ułatwione delegowanie uprawnień, gdzie łączymy się, korzystając z użytkownika o obniżonych uprawnieniach, ale wszelkie akcje wykonywane są z uprawnieniami podwyższonymi. Niestety konfiguracje końcówek okazały się nie odzwierciedlać dość dobrze modelu, który był potrzebny do wygodnej i precyzyjnej konfiguracji PowerShell Remoting w scenariuszach, gdzie chcielibyśmy delegować uprawnienia.

Wreszcie w wersji piątej PowerShella pojawiło się rozwiązanie zdecydowanie ciekawsze. Oprócz konfiguracji końcówek wprowadzono bowiem role: bardzo wygodny sposób kojarzenia użytkowników łączących się z naszą końcówką z oferowanymi im poleceniami. Domyślnie założenie zakładało wykorzystanie poleceń „wbudowanych”, ale o wiele praktyczniejszym rozwiązaniem może być stworzenie własnego modułu, dzięki czemu uzyskamy pełną kontrolę nad tym, co, kto i gdzie może wykonać.

Role w PowerShell Remoting

Tworzenie ról wykorzystywanych w końcówkach PowerShell Remoting wymaga utworzenia odpowiedniej struktury w jednym z folderów domyślnie przeznaczonych dla modułów PowerShella. Zwykle będzie to folder C:Program FilesWindowsPowerShellModules. Warto zwrócić uwagę, że choć lokalizacja przeznaczona jest dla modułów, to konfiguracja roli nie będzie sensu stricte modułem: nie musimy tworzyć manifestu, nie mamy obsługi podfolderów przeznaczonych dla różnych wersji modułu. W folderze utworzonym w tej lokalizacji umieścić musimy podfolder RoleCapabilities, a w nim dla każdej definiowanej roli plik o rozszerzeniu PSRC. Nazwa utworzonej roli będzie pokrywać się z nazwą bazową pliku. Plik ten utworzymy, wykorzystując specjalnie do tego przeznaczone polecenie, New-PSRoleCapabilityFile. Na tym etapie pominiemy szczegóły dotyczące zawartości tego pliku:

mkdir -Path 'C:Program FilesWindowsPowerShellModulesRole'
mkdir -Path 'C:Program FilesWindowsPowerShellModulesRoleRoleCapabilities'
New-PSRoleCapabilityFile -Path 'C:Program FilesWindowsPowerShellModulesRoleRoleCapabilitiesMojaRola.psrc'
 

Dzięki temu utworzony zostanie plik zawierający przykłady konfiguracji, jaką plik taki oferuje, w postaci komentarzy, na przykład:

# Cmdlets to make visible when applied to a session
# VisibleCmdlets = 'Invoke-Cmdlet1', @{ Name = 'Invoke-Cmdlet2'; Parameters = @{ Name = 'Parameter1'; ValidateSet = 'Item1', 'Item2' }, @{ Name = 'Parameter2'; ValidatePattern = 'L*' } }
# Functions to make visible when applied to a session
# VisibleFunctions = 'Invoke-Function1', @{ Name = 'Invoke-Function2'; Parameters = @{ Name = 'Parameter1'; ValidateSet = 'Item1', 'Item2' }, @{ Name = 'Parameter2'; ValidatePattern = 'L*' } }

Wystarczy więc usunąć symbol inicjujący komentarz, przekształcić przykładową linię, by po chwili mieć przygotowany plik konfiguracyjny:

@{
 ModulesToImport = @(
 'Microsoft.PowerShell.Management'
 )
 VisibleCmdlets = @(
 @{
 Name = 'Get-Service'
 Parameters = @{
 Name = 'DisplayName'
 ValidatePattern = 'DNS.*'
 }
 }
 @{
 Name = 'Restart-Service'
 Parameters = @{
 Name = 'DisplayName'
 ValidateSet = 'DNS Server'
 }
 }
 )
 Description = 'Testowa rola do zarządzania serwerem DNS'
}

Oczywiście nic nie stoi na przeszkodzie, by takich ról przygotować więcej. Jest to wręcz wskazane, gdyż plik konfigurujący końcówkę pozwoli nam poszczególne role przypisać różnym grupom w ramach Active Directory, a łączący się z końcówką użytkownik będzie mógł skorzystać z roli stanowiącej połączenie wszystkich przypisanych mu ról.

[...]

Autor zawodowo zajmuje się informatyką. Jest Microsoft MVP w dziedzinie PowerShella, blogerem oraz jednym z moderatorów forum dotyczącego skryptów w serwisie TechNet. Autor książki „Windows PowerShell 5.1 Biblia”.