Dostęp do uprawnień administratora to podstawa w pracy z PowerShellem. Weryfikacja, czy skrypt, polecenie albo sama konsola działają z odpowiednimi uprawnieniami, pozwala uniknąć wielu problemów – od błędów wykonania po poważniejsze zagrożenia. W tym wpisie pokażę proste sposoby, dzięki którym szybko sprawdzisz, czy działasz jako administrator – i już nigdy nie będziesz się nad tym zastanawiać.
Powiązane wpisy:
Uprawnienia w PowerShellu
Dlaczego warto sprawdzić uprawnienia?
Zanim zaczniemy zagłębiać się w konkretne przykłady warto najpierw rozważyć, dlaczego warto w ogóle zaprzątać sobie głowę tym tematem. Sprawdzenie, czy skrypt posiada uprawnienia administratora, ma kluczowe znaczenie z kilku istotnych powodów:
Wykonywanie zadań wymagających uprawnień administratora
Wiele zadań w systemie operacyjnym Windows wymaga uprawnień administratora. Do podstawowych należy instalacja i aktualizacja aplikacji, zarządzanie usługami systemowymi, modyfikacja konfiguracji systemu czy chociażby zmiana hasła użytkownika. Wiedza czy dany skrypt należy uruchomić podniesionymi uprawnieniami, czy nie jest w tym wypadku bezcenna.
Uniknięcie błędów i problemów
Próba wykonania zadań wymagających specyficznych uprawnień bez posiadania tych uprawnień zwykle prowadzi do błędów i problemów. W niektórych szczególnych przypadkach wykonanie części skryptu narobi więcej szkód, niż przyniesie pożytku.
Bezpieczeństwo systemu
Sprawdzanie, czy skrypt faktycznie wymaga uprawnień administratora, pomaga zapobiec nadmiernemu nadawaniu uprawnień i potencjalnym atakom.
Zgodność z zasadami bezpieczeństwa
W środowiskach korporacyjnych istnieją zazwyczaj zasady bezpieczeństwa, których zadaniem jest monitorowanie wszystkich działań administratora. Sprawdzenie uprawnień skryptów pomaga zachować zgodność z tymi zasadami.
Jak widzisz sprawdzanie, czy skrypty i polecenia PowerShell są uruchamiane z uprawnieniami administratora to kluczowy krok w dbaniu o bezpieczeństwo, stabilność i skuteczność wykonywanych działań w organizacji. Przejdźmy zatem do kilku prostych metod, które ułatwią to zadanie.
Sprawdzenie wizualne
Pierwszym i najprostszym sposobem jest spojrzenie na okno konsoli PowerShell (o ile oczywiście skrypt czy polecenie wykonujesz w otwartym oknie konsoli).
Okno konsoli PowerShell
W większości przypadków, gdy PowerShell posiada podniesione uprawnienia, na pasku tytułu zobaczysz napis Administrator. W przeciwnym razie najprawdopodobniej PowerShell działa jako zwykły użytkownik.
Katalog domowy
Jeżeli uruchomisz PowerShella z podniesionymi uprawnieniami to mogłeś zauważyć, że startuje on w nieco innym katalogu domowym. Standardowo jest to katalog domowy użytkownika, w przypadku podniesionych uprawnień będzie to zwykle C:\Windows\System32. To również może być informacja, że masz doczynienia z uprawnieniami administratora.
Jeśli jesteś w innym katalogu możesz ewentualnie wykonać polecenie: cd $HOME
Jeżeli przeniesiesz się do C:\Windows\System32 to zwykle oznacza, że działasz na uprawnieniach admina.
Operacje wymagające uprawnień
Jeśli w dalszym ciągu nie jesteś w 100% pewny/a czy PowerShell działa z uprawnieniami administratora kolejnym ze sposobów może być próba wykonania poleceń, które tych uprawnień wymagają (np. Set-ExecutionPolicy, Install-WindowsFeature). Jeżeli otrzymasz błąd związany z odmową dostępu — prawdopodobnie nie jesteś w trybie admina.
💡Tutaj jednak bym uważał i nie wykonywał zbyt agresywnych poleceń (czyli poleceń, które przykładowo zmieniają coś w systemie lub resetują komputer), gdyż w przeciwnym razie możesz narobić sobie szkód.
Windows Terminal
Kolejnym dobrym sposobem może być wykorzystanie właściwiości Windows Terminala, który obecnie wykorzystywany jest coraz częściej. Zwykle przy pracy otwartych mamy kilka zakładek — PowerShell, CMD, Azure itd. Czasem łatwo przeoczyć, które okno działa z uprawnieniami administratora. Można to rozwiązać prostym trikiem: zmiana koloru tła lub ikonki tylko dla profilu z uprawnieniami administratora. Jak to zrobić? Już pokazuję.
Jak to ustawić?
1. Otwórz ustawienia Windows Terminal
- Kliknij strzałkę przy zakładkach i wybierz:
Settings (Ustawienia)
(lub naciśnij Ctrl + ,)
2. Znajdź profil PowerShell 7
- W lewej kolumnie wybierz profil np.
PowerShell 7. - Kliknij, aby go edytować.
3. Skonfiguruj profil dla trybu administratora
Musisz utworzyć oddzielny profil, który będzie działał tylko w trybie admina i miał inną kolorystykę lub ikonę.
➕ Dodaj nowy profil (przykład):
W pliku settings.json (możesz go edytować ręcznie z poziomu Windows Terminal) dodaj taki profil:
jsonCopyEdit{
"guid": "{GUID-DLA-ADMINA}",
"name": "PowerShell (Admin)",
"commandline": "powershell.exe",
"hidden": false,
"startingDirectory": "%USERPROFILE%",
"icon": "ms-appx:///ProfileIcons/pwsh-admin.png",
"background": "#550000", // ciemnoczerwone tło
"colorScheme": "Campbell",
"elevate": true // kluczowe!
}
Warto wiedzieć
"elevate": true– powoduje, że profil uruchamia się zawsze jako administrator (Windows zapyta o zgodę)."background"– zmienia kolor tła tylko dla tego profilu (można dać np. czerwony, granatowy)."icon"– możesz ustawić osobną ikonę, np. ikonę z kłódką, aby wizualnie odróżnić profil.
4. Zapisz zmiany i uruchom nowy profil
Po zapisaniu i ponownym uruchomieniu Windows Terminala zobaczysz nowy wpis w liście zakładek:
PowerShell (Admin)
Gdy go klikniesz, uruchomi się PowerShell z podniesionymi uprawnieniami i specjalnym wyglądem, który sam ustawiłeś.
Klasa .NET WindowsIdentity
Ponieważ PowerShell sam w sobie nie posiada konkretnego cmdletu, który rozwiązywałby nasz problem, niedogodność tę należy ominąć stosując specjalną klasę WindowsIdentity. Klasa ta umożliwia wykonanie szeregu różnych inspekcji. Dla nas najistotniejszy jest token zalogowanego konta Windows i sprawdzenie, do jakich grup przypisana jest uruchomiona instacja PowerShell.
W najprostszej formie wygląda to następująco:
PS C:\Users\Admin> [Security.Principal.WindowsIdentity]::GetCurrent().Groups
BinaryLength AccountDomainSid Value
------------ ---------------- -----
12 S-1-1-0
16 S-1-5-32-545
12 S-1-5-4
12 S-1-2-1
12 S-1-5-11
12 S-1-5-15
52 S-1-11-96-3623454863-58364-18864-2661722203-1597581903-1886212171-3126173085-891278134-3015806222-3609238202
12 S-1-5-113
12 S-1-2-0
16 S-1-5-64-36
W wyniku działania otrzymujemy różne wartości, które na pierwszy rzut oka nic nam nie mówią. To są tzw. SIDy (Security Identifier), czyli unikalne identyfikatory bezpieczeństwa przypisane do każdego obiektu w systemie Windows (obiektem może być użytkownik, grupa użytkowników, komputer lub domena). Jest to ciąg liczbowy, który jednoznacznie identyfikuje obiekt w systemie. SID służy do kontroli dostępu i autoryzacji w systemach operacyjnych Windows.
No dobrze, ale co nam to daje? Otóż jeżeli znamy konkretnego SIDa to możemy wykonać coś takiego:
PS C:\Users\Admin> [Security.Principal.WindowsIdentity]::GetCurrent().Groups -contains 'S-1-5-32-544'
False
Wynik False oznacza, że dany SID 'S-1-5-32-544’ nie został odnaleziony.
No ok wszystko fajnie, tylko dalej nie wiadomo, o co chodzi.
Spokojnie już wyjaśniam SID 'S-1-5-32-544' należy do grupy tzw. Well know SID czyli identyfikatorów dobrze znanych. W tym konkretnym wypadku jest to SID wbudowanej grupy administratorów na komputerze lokalnym. Jeżeli komputer dołączy do domeny to grupa Administratorzy Domeny również stanie się częścią grupy Administratorzy. Kiedy komputer zostanie kontrolerem domeny to grupa Enterprise Administrator również zostanie dodana do grupy Administratorzy.
Reasumując, jeżeli SID 'S-1-5-32-544' znajdzie się w wykazie grup, które nam się wyświetlą to PowerShell został uruchomiony z uprawnieniami Administratora.
Sprawdźmy to. Teraz ponownie wylistuję grupy tym razem w konsoli z uprawnieniami Administratora:
PS C:\Windows\system32> [Security.Principal.WindowsIdentity]::GetCurrent().Groups
BinaryLength AccountDomainSid Value
------------ ---------------- -----
12 S-1-1-0
12 S-1-5-114
16 S-1-5-32-544
16 S-1-5-32-545
12 S-1-5-4
12 S-1-2-1
12 S-1-5-11
12 S-1-5-15
52 S-1-11-96-3623454863-58364-18864-2661722203-1597581903-1886212171-3126173085-891278134...
12 S-1-5-113
12 S-1-2-0
16 S-1-5-64-36
Jak widzisz pojawiła się nowa grupa z naszym SIDem. Teraz czas na drugie polecenie
PS C:\Windows\system32> [Security.Principal.WindowsIdentity]::GetCurrent().Groups -contains 'S-1-5-32-544'
True
W wyniku wartość True, zatem w tym wypadku PowerShell posiada podwyższone uprawnienia.
Nieco innym podejściem może być sprawdzenie konkretnej roli zamiast SIDa:
PS C:\Windows\system32> ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")
True
Generalnie całość działania jest bardzo podobna.
Sprawdzenie w skrypcie
Teraz w celu małej automatyzacji zastosuję omówiąną metodę w celu spadzenia z jakimi uprawnieniami został uruchomiony skrypt. Zadanie to można oczywiście wykonać na wiele sposobów, a jednym z nich jest zastosowanie prostej instrukcji warunkowej. Oto jak może to wyglądać:
$principal = New-Object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())
if ($principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
Write-Host "PowerShell został uruchomiony z uprawnieniami administratora."
} else {
Write-Host "PowerShell nie został uruchomiony z uprawnieniami administratora."
}
Przedstawiona metoda umożliwia weryfikację uprawnień, która może być przydatna w złożonych scenariuszach.
Samodzielny skrypt
Może się jednak zdarzyć, że dany skrypt chcąc nie chcąc musi działać z podniesionymi uprawnieniami. W tym wypadku warto zastosować coś takiego:
# Sprawdź czy PowerShell został uruchomiony jako administrator
if (-not ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
# Uruchom skrypt ponownie jako administrator
Start-Process powershell.exe -NoProfile -ExecutionPolicy Bypass -File '"$PSCommandPath"' -Verb RunAs
# Zakończ bieżącą sesję PowerShell
Exit
}
# Kod skryptu, który zostanie wykonany tylko jeśli PowerShell został uruchomiony z uprawnieniami administratora
Write-Host "Ten skrypt został uruchomiony jako administrator."
Jest to szczególnie przydatne, gdy nie masz otwartej sesji z uprawnieniami administracyjnymi lub gdy chcesz wykonać skrypt na zdalnym komputerze z uprawnieniami administracyjnymi (ewentualnie ludzie, z którymi pracujesz nie wiedzą jakie skrypty jak należyuruchamiać, ale mam nadzieję, że to nie to)
Jak to działa?
W pierwszym kroku sprawdzamy, czy uruchomiona instancja PowerShell posiada podniesione uprawnienia. W tym celu możemy zastosować instrukcję warunkową If z negacją 'if (-not (warunek))’. Jeżeli sprawdzenie zwróci wartość False wykona się instrukcja w nawiasach klamrowych. Dla jasności rozbiję ją na części:
Start-Process powershell.exe – uruchamia nowy proces, w tym wypadku nową instancję PowerShell (powershell.exe świadczy, że będzie do Windows PowerShell)
-No Profile – przy uruchomieniu PowerShella profil użytkownika nie załąduje się. (O profilach będziesz mógł poczytać tu – za jakiś czas).
-ExecutionPolicy Bypass – ominięcie polityki bezpieczeństwa dotyczącej uruchamiania skryptów. (Z tym szczególna ostrożność. Coś więcej o politykach znajdziesz tu – za jakiś czas)
-File '”$PSCommandPath”’ – reprezentuję ścieżkę do pliku (w tym wypadku skryptu), który ma zostać wykonany przez PowerShella.
-Verb RunAs – służy do uruchomienia polecenia lub skryptu z podwyższonymi uprawnieniami administracyjnymi.
Jeżeli wszystko zadziałało pomyślnie to nowo uruchomiona konsola posiada już podniesione uprawnienia.
#Request -RunAsAdministrator
Kolejna metoda to wykorzystanie specjalnej dyrektywy #Request -RunAsAdministrator. Co prawda możliwość ta dostępna jest od PowerShell w wersji 4.0 jednak wydaje mi się, że obecnie nie stanowi to już żadnej przeszkody. Całość prezentuję się następująco:
#requires -version 4.0
#requires -RunAsAdministrator
Write-Host "PowerShell został uruchomiony jako administrator" -ForegroundColor Green
Dyrektywę umieść na początku skryptu. Więcej na ten temat znajdziesz -> tutaj
Uruchamiamy skrypt i patrzymy co się dzieje. W przypadku braku odpowiednich uprawnień pojawi się błąd i informacja, która podpowie, jak uruchomić PowerShell z uprawnieniami administratora.
W przypadku gdy skrypt uruchomi się z odpowiednimi uprawnieniami w konsoli pojawi się zielony napis.
Dla chętnych
Dodatkowo w ramach małego bonusu dla chętnych pokażę, jak można sprawdzić, które procesy posiadają podwyższone uprawnienia. W tym wypadku pomocny będzie cmdlet Get-Process oraz Add-Member, co ciekawe w tym przypadku nie musisz mieć podniesionych uprawnień.
Get-Process | Add-Member -Name Elevated -MemberType ScriptProperty -Value `
{if ($this.Name -in @('Idle','System')) {$null} `
else {-not $this.Path -and -not $this.Handle} } -PassThru | Where-Object Elevated -eq 'True'
Podsumowanie
Przedstawione wyżej metody pozwolą sprawdzić, czy też zapewnić, że skrypt wykonuję się z odpowiednimi uprawnieniami. Pamiętaj jednak, że nie zawsze jest to konieczne. Stosuj to tylko w uzasadnionych okolicznościach.
Źródła:
https://megamorf.gitlab.io/2020/05/26/check-if-powershell-is-running-as-administrator/
https://petri.com/how-to-check-a-powershell-script-is-running-with-admin-privileges/
To wszystko na dziś!
Jeśli masz ciekawe spostrzeżenia lub doświadczenia w tym temacie – koniecznie podziel się nimi w komentarzach.
A jeśli moje materiały są dla Ciebie pomocne, możesz postawić mi wirtualną kawę.
Dzięki za wsparcie!
