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


17.09.2019

PLNOG23 czyli sieci 5G,...

Największa polska konferencja telekomunikacyjna powraca do Krakowa! Wśród nowości ścieżka...
05.09.2019

Cloudya – nowa usługa NFON

Po ponad dekadzie ciągłego rozwoju technologii Cloudya, swobodna i niczym nie ograniczona...
02.09.2019

Na dużą skalę

Kaspersky Hybrid Cloud Security
02.09.2019

Bezpieczny brzeg sieci

Fortinet Secure SD-Branch
02.09.2019

Nowoczesne centra danych

AMD EPYC
30.08.2019

Dostęp do AI i ML

VMware Cloud Foundation
30.08.2019

Lekkość i moc

Toshiba Portégé A30-E
30.08.2019

Bez przestojów

APC Easy UPS On-Line
29.08.2019

Duże moce

Lenovo ThinkSystem SR635 i SR655

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"