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


26.10.2020

Nowa wersja nVision

Można już pobierać nową wersję nVision
26.10.2020

Monitorowanie infrastruktury

Vertiv Environet Alert
23.10.2020

Telefonia w chmurze

NFON Cloudya
23.10.2020

Nowości w EDR

Bitdefender GravityZone
23.10.2020

Wykrywanie anomalii

Flowmon ADS11
23.10.2020

Mobilny monitor

AOC 16T2
22.10.2020

HP Pavilion

HP zaprezentowało nowe laptopy z linii Pavilion.
22.10.2020

Inteligentny monitoring

WD Purple SC QD101
22.10.2020

Przełącznik 2,5GbE

QNAP QSW-1105-5T

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"