Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


12.05.2022

Odszyfrowanie historii

Z inicjatywy prezesa IPN, dr. Karola Nawrockiego, powstało Biuro Nowych Technologii. Jego...
01.04.2022

Program partnerski

NGAGEFirma NFON, ogólnoeuropejski dostawca komunikacji głosowej w chmurze, ogłosił...
01.04.2022

SI w TFI PZU

Na platformie do inwestowania inPZU działa już nowa metoda identyfikacji tożsamości...
01.04.2022

Kooperacja w chmurze

To oparta na stworzonej przez NetApp technologii ONTAP i w pełni zarządzana przez...
01.04.2022

Nowe laptopy od Dynabook

Dynabook wprowadza do swojej oferty dwa laptopy z procesorami Intel Core 12. generacji,...
01.04.2022

Ryzen do stacji roboczych

AMD przedstawił nową gamę procesorów Ryzen Threadripper PRO 5000 serii WX.
31.03.2022

Serwery dla MŚP

Firma Lenovo wprowadziła nowe rozwiązania w zakresie infrastruktury IT Future Ready,...
31.03.2022

Innowacyjny kontroler SSD

Microchip zaprezentował nowe kontrolery SSD, które umożliwią obsługę napędów o pojemności...
31.03.2022

Wydajny jak Brother

Brother dodał do swojej oferty trzy nowe, atramentowe urządzenia wielofunkcyjne, które...

PowerShell Remoting

Data publikacji: 03-03-2022 Autor: Bartosz Bielawski

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”.

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"