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


10.06.2019

Inteligentne zarządzanie...

W dniach 11, 12 i 13 czerwca – odpowiednio – w Gdańsku, w Warszawie i w Katowicach,...
27.05.2019

Rozwiązania na platformie GCP

Citrix SD-WAN i Citrix ADC
27.05.2019

Chmura hybrydowa

Dell Technologies Cloud
27.05.2019

Uproszczona komunikacja

Cisco Webex
24.05.2019

Konferencja IT Manager of...

W dniach 12–14 czerwca w Sopocie odbędzie się konferencja IT Manager of Tomorrow 2019. To...
24.05.2019

Ochrona sieci

Fortinet FortiOS 6.2
24.05.2019

Mniejsza złożoność

Rittal VX25 Ri4Power
24.05.2019

All-in-one NAS

QNAP TDS-16489U R2
24.05.2019

Układy SoC

AMD Ryzen Embedded R1000

Delegowanie uprawnień za pomocą powershell remoting

Data publikacji: 03-04-2017 Autor: Bartosz Bielawski

W pierwszych dwóch częściach cyklu o zarządzaniu Windowsami z poziomu Linuksa skupiliśmy się na module pywinrm i problemach, jakie mogą pojawić się w trakcie jego użytkowania. W trzeciej części opisujemy, jak umożliwić delegowanie uprawnień z wykorzystaniem PowerShell remoting, z którego pywinrm domyślnie nie korzysta, oraz przyjrzymy się temu, jak ograniczyć liczbę systemów, w których trzeba dokonać zmian, aby za pomocą pywinrm móc się z nimi połączyć.

PowerShell remoting tworzony był z założeniem, że samo umożliwienie zdalnego zarządzania systemem to za mało. Od początku zwracano uwagę na bezpieczeństwo i ścisłą kontrolę tego, co poszczególni użytkownicy mogą zrobić po połączeniu się ze zdalną końcówką. Z każdą kolejną wersją narzędzie oferowało coraz większe możliwości – począwszy od ograniczonych końcówek dostępu w wersji drugiej PowerShella, przez konfigurowanie końcówek z wybranymi poświadczeniami, kolejne wersje plików konfiguracyjnych i ostatecznie po możliwość stosowania, oferowanych w ramach piątej wersji PowerShell, końcówek Just Enough Admin (JEA).

Aby nie ograniczyć tworzonego przez nas rozwiązania jedynie do ostatniej wersji PowerShella, przyjrzymy się dwóm rozwiązaniom:

  • plikowi startowemu wykorzystywanemu w końcówce pracującej pod kontrolą użytkownika o podwyższonych uprawnieniach (dostępne dla każdej wersji PowerShella, począwszy od wersji trzeciej);
  • ograniczonej końcówce JEA, korzystając z kont wirtualnych (wymagającej, jak już wspomniano, wersji piątej PowerShella).

 

W obu przypadkach użytkownik korzystający z Linuksa będzie mógł zarządzać serwerem DNS, a konkretniej, dodawać i usuwać wpisy typu A oraz CNAME.

> PLIK STARTOWY

Pliki startowe stanowią swoisty profil zdalnych końcówek dostępu. Są one rozwiązaniem umożliwiającym nam pełną kontrolę nad tym, jakie możliwości będzie miał dany użytkownik po połączeniu z końcówką. Wymagają też jednak najwięcej pracy – większość konfiguracji, która w przypadku korzystania z plików konfiguracyjnych sprowadza się do zmiany pojedynczej opcji w tymże pliku, tu jest bardziej skomplikowana i musi zostać przeprowadzona za każdym razem krok po kroku. Aby narzucane przez nas ograniczenia były skuteczne, końcówka musi ograniczać możliwości użytkownika do wykonywania zdefiniowanych przez nas poleceń. Żeby jednak nadal była ona funkcjonalna, kilka standardowych poleceń trzeba zdefiniować samodzielnie. Polecenia te wymagane są dla prawidłowego funkcjonowania końcówki i podobnie jak większość poleceń, które będziemy oferować łączącym się użytkownikom, są tak zwanymi funkcjami zastępczymi – swoistymi pośrednikami pomiędzy użytkownikiem końcowym a cmdletem, z którego zamierza on skorzystać.

Funkcje te zwykle zmieniają zachowanie polecenia oraz ograniczają dostępne parametry i wartości argumentów. Kod inicjalizujący ograniczoną (czyli bezpieczną) końcówkę, bez oferowania jakiejkolwiek funkcjonalności, znajduje się poniżej i jest szkieletem naszego pliku konfiguracyjnego:

foreach ($cmd in Get-Command) {
$cmd.Visibility = 'Private'
}
foreach ($var in Get-Variable) {
$var.Visibility = 'Private'
}
$ExecutionContext.SessionState.Applications.Clear()
$ExecutionContext.SessionState.Scripts.Clear()

$iss = [Management.Automation.Runspaces.InitialSessionState]::CreateRestricted(
'RemoteServer'
)
foreach ($proxy in $iss.Commands |
Where-Object {
$_.Visibility -eq 'Public' -and
$_.CommandType -eq 'Function'
}
) {
$cmd = Get-Command -Type Cmdlet -ea SilentlyContinue $proxy.Name
if ($cmd) {
$alias = Set-Alias -Name "$($proxy.Name)" -Value "$($cmd.ModuleName)$($cmd.Name)" -PassThru
$alias.Visibility = 'Private'
}
Set-Item -Path "function:global:$($proxy.Name)" -Value $proxy.Definition
}
$ExecutionContext.SessionState.LanguageMode = 'NoLanguage'

Tak utworzony szkielet musimy jedynie uzupełnić o wymagane polecenia. Gdy zdefiniujemy już wszystkie funkcje, które zamierzamy oferować naszym użytkownikom, pozostanie jedynie zadbać o to, aby polecenia były uruchamiane z odpowiednimi uprawnieniami.

[...]

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.0 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"