Jak skonfigurować system Windows do pracy ze skryptami PowerShell w bardziej prosty sposób

Windows i PowerShell mają wbudowane funkcje bezpieczeństwa i domyślne konfiguracje mające na celu zapobieganie przypadkowemu uruchamianiu skryptów przez użytkowników w trakcie ich codziennych czynności. Jeśli jednak twoje codzienne czynności rutynowo obejmują pisanie i uruchamianie własnych skryptów PowerShell, może to być bardziej uciążliwe niż korzyść. Tutaj pokażemy, jak obejść te funkcje bez całkowitego naruszenia bezpieczeństwa.

Jak i dlaczego Windows i PowerShell uniemożliwiają wykonanie skryptu.

PowerShell jest faktycznie powłoką poleceń i językiem skryptowym, który ma zastąpić CMD i skrypty wsadowe w systemach Windows. W związku z tym skrypt PowerShell może być skonfigurowany tak, aby cokolwiek można zrobić ręcznie z wiersza poleceń. Oznacza to praktycznie każdą możliwą zmianę w twoim systemie, aż do ograniczeń na twoim koncie użytkownika. Tak więc, gdybyś mógł dwukrotnie kliknąć skrypt PowerShell i uruchomić go z pełnymi uprawnieniami administratora, prosty jednolinijkowy taki jak ten mógłby naprawdę zniszczyć twój dzień:

Get-ChildItem "$ env: SystemDrive \" -Recurse -ErrorAction SilentlyContinue | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue

NIE uruchamiaj powyższego polecenia!

To po prostu przechodzi przez system plików i usuwa wszystko, co może. Co ciekawe, może to nie spowodować, że system przestanie działać tak szybko, jak mogłoby się wydawać - nawet po uruchomieniu z podwyższonej sesji. Ale jeśli ktoś zadzwoni do ciebie po uruchomieniu tego skryptu, ponieważ nagle nie może znaleźć swoich plików lub uruchamiać niektórych programów, "wyłączenie i ponowne włączenie" prawdopodobnie doprowadzi ich do naprawy systemu Windows, gdzie zostaną poinformowani, że jest nic, co można zrobić, aby rozwiązać problem. Co może być gorsze, zamiast dostać skrypt, który po prostu marnotrawi ich system plików, twój przyjaciel może zostać oszukany do uruchomienia takiego, który pobiera i instaluje keylogger lub usługę zdalnego dostępu. Następnie zamiast zadawać pytania dotyczące naprawy uruchamiania, mogą w końcu zadać policji kilka pytań dotyczących oszustwa bankowego!

Do tej pory powinno być oczywiste, dlaczego pewne rzeczy są potrzebne, by tak rzec, chronić użytkowników końcowych przed sobą. Jednak zaawansowani użytkownicy, administratorzy systemu i inni geekowie generalnie (choć są wyjątki) są nieco bardziej ostrożni wobec tych zagrożeń, wiedząc, jak je wykryć i łatwo ich uniknąć, i po prostu chcą kontynuować pracę. Aby to zrobić, będą musieli albo wyłączyć, albo obejść kilka bloków drogowych:

PowerShell domyślnie nie pozwala na zewnętrzne wykonywanie skryptów.
Ustawienie ExecutionPolicy w PowerShell zapobiega domyślnemu uruchamianiu zewnętrznych skryptów we wszystkich wersjach systemu Windows. W niektórych wersjach systemu Windows ustawienie domyślne nie pozwala na wykonanie skryptu. Pokazaliśmy, jak zmienić to ustawienie w Jak umożliwić wykonywanie skryptów PowerShell w systemie Windows 7, ale omówimy to również na kilku poziomach.
PowerShell nie jest domyślnie skojarzony z rozszerzeniem .PS1.
Wprowadziliśmy to początkowo w naszej serii PowerShell Geek School. System Windows ustawia domyślną akcję dla plików .PS1, aby otworzyć je w Notatniku, zamiast wysyłać je do interpretera poleceń PowerShell. Ma to na celu bezpośrednie zapobieganie przypadkowemu uruchamianiu złośliwych skryptów po dwukrotnym kliknięciu.
Niektóre skrypty PowerShell nie będą działały bez uprawnień administratora.
Nawet działając z kontem na poziomie administratora, nadal musisz przejść przez kontrolę konta użytkownika (UAC), aby wykonać określone czynności. W przypadku narzędzi wiersza polecenia może to być co najmniej kłopotliwe. Nie chcemy wyłączać UAC, ale nadal jest miło, kiedy możemy łatwiej sobie z tym poradzić.

Te same problemy zostały poruszone w temacie Jak korzystać z pliku wsadowego, aby skrypty PowerShell łatwiej działały, a my przeprowadzamy Cię przez pisanie pliku wsadowego, aby tymczasowo ominąć te pliki. Teraz pokażemy, jak ustawić system z bardziej długoterminowym rozwiązaniem. Pamiętaj, że nie powinieneś zasadniczo wprowadzać tych zmian w systemach, które nie są używane wyłącznie przez Ciebie - w przeciwnym razie narażasz innych użytkowników na większe ryzyko wystąpienia tych samych problemów, które te funkcje mają zapobiegać.

Zmiana powiązania plików .PS1.

Pierwszą, a może przede wszystkim, irytacją do obejścia jest domyślne skojarzenie plików .PS1. Powiązanie tych plików z czymkolwiek innym niż PowerShell.exe ma sens w zapobieganiu przypadkowemu uruchamianiu niepożądanych skryptów. Ale biorąc pod uwagę, że PowerShell jest wyposażony w zintegrowane środowisko skryptowe (ISE), które zostało specjalnie zaprojektowane do edycji skryptów PowerShell, dlaczego chcemy domyślnie otwierać pliki .PS1 w Notatniku? Nawet jeśli nie jesteś gotowy, aby w pełni włączyć funkcję podwójnego kliknięcia, prawdopodobnie zechcesz dostosować te ustawienia.

Można zmienić skojarzenie plików .PS1 z dowolnym programem za pomocą panelu sterowania Domyślne programy, ale bezpośrednie przeszukanie rejestru pozwoli uzyskać większą kontrolę nad tym, w jaki sposób pliki zostaną otwarte. Umożliwia to również ustawienie lub zmianę dodatkowych opcji dostępnych w menu kontekstowym plików .PS1. Nie zapomnij zrobić kopii rejestru, zanim to zrobisz!

Ustawienia rejestru kontrolujące sposób otwierania skryptów PowerShell są przechowywane w następującej lokalizacji:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Aby poznać te ustawienia, zanim przejdziemy do ich zmiany, spójrz na ten klucz i jego podklucze za pomocą Regedit. Klucz Shell powinien mieć po prostu jedną wartość "(domyślnie)", która jest ustawiona na "Otwórz". To jest wskaźnik do akcji domyślnej dla podwójnego kliknięcia pliku, który zobaczymy w podkluczach.

Rozwiń klucz Shell, a zobaczysz trzy podklucze. Każda z nich reprezentuje akcję, którą można wykonać, która jest specyficzna dla skryptów PowerShell.

Możesz rozwinąć każdy klucz, aby poznać wartości w nim zawarte, ale w zasadzie są one zgodne z następującymi wartościami domyślnymi:

0 - Uruchom z PowerShell. "Uruchom z PowerShell" to tak naprawdę nazwa opcji już w menu kontekstowym dla skryptów PowerShell. Tekst jest po prostu wyciągany z innej lokalizacji, zamiast używać nazwy klucza, jak inne. I nadal nie jest domyślną czynnością dwukrotnego kliknięcia.
Edytuj - Otwórz w PowerShell ISE. Ma to więcej sensu niż Notatnik, ale nadal musisz kliknąć plik .PS1 prawym przyciskiem myszy, aby zrobić to domyślnie.
Otwórz - otwórz w Notatniku. Zauważ, że ta nazwa klucza jest również ciągiem przechowywanym w wartości "(Domyślne)" klucza Shell. Oznacza to dwukrotne kliknięcie na plik, który "otworzy" go, a ta czynność jest zwykle ustawiona na korzystanie z Notatnika.

Jeśli chcesz pozostać przy wcześniej przygotowanych ciągach poleceń, które już są dostępne, możesz po prostu zmienić wartość "(Domyślna)" w kluczu Shell, aby pasowała do nazwy klucza, który odpowiada podwójnemu kliknięciu. Można to łatwo zrobić z poziomu Regedit lub możesz skorzystać z lekcji z naszego samouczka na temat odkrywania rejestru za pomocą PowerShell (plus mała modyfikacja PSDrive), aby rozpocząć tworzenie skryptu wielokrotnego użytku, który może skonfigurować twoje systemy. Poniższe polecenia muszą być uruchamiane z podwyższonej sesji PowerShell, podobnie do uruchamiania CMD jako Administrator.

Najpierw skonfiguruj PSDrive dla HKEY_CLASSES_ROOT, ponieważ nie jest to domyślnie ustawione. Polecenie dla tego jest:

New-PSDrive Rejestr HKCR HKEY_CLASSES_ROOT

Teraz możesz nawigować i edytować klucze rejestru i wartości w HKEY_CLASSES_ROOT, tak jak w standardowych HKCU i HKLM PSDrives.

Aby skonfigurować podwójne kliknięcie, aby bezpośrednio uruchomić skrypty PowerShell:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(domyślnie)' 0

Aby skonfigurować podwójne kliknięcie, aby otworzyć skrypty PowerShell w środowisku PowerShell:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell "(domyślnie)" Edytuj "

Aby przywrócić wartość domyślną (ustawia dwukrotnie, aby otworzyć skrypty PowerShell w Notatniku):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell (domyślnie) "Otwórz"

To tylko podstawy zmiany domyślnego działania dwukrotnego kliknięcia. Bardziej szczegółowo omówimy sposób, w jaki skrypty PowerShell są obsługiwane po otwarciu w PowerShell z Explorera w następnej sekcji. Należy pamiętać, że scoping zapobiega utrzymywaniu się PSDrives podczas sesji. Więc prawdopodobnie będziesz chciał dołączyć linię New-PSDrive na początku każdego skryptu konfiguracyjnego, który stworzyłeś w tym celu, lub dodać ją do swojego profilu PowerShell. W przeciwnym razie będziesz musiał uruchomić ten bit ręcznie przed próbą wprowadzenia zmian w ten sposób.

Zmiana ustawienia PowerShell ExecutionPolicy.

PowerShell ExecutionPolicy to kolejna warstwa ochrony przed wykonywaniem złośliwych skryptów. Istnieje wiele opcji do tego i kilka różnych sposobów, które można ustawić. Od większości do najmniej bezpiecznych dostępne są następujące opcje:

Ograniczone - Żadne skrypty nie mogą być uruchamiane. (Ustawienie domyślne dla większości systemów.) Zapobiegnie to nawet uruchomieniu skryptu profilu.
AllSigned - Wszystkie skrypty muszą być podpisane cyfrowo przez zaufanego wydawcę, aby działał bez pytania użytkownika. Skrypty podpisane przez wydawców jednoznacznie zdefiniowane jako niezaufane lub skrypty nie podpisane cyfrowo wcale nie będą działać. PowerShell poprosi użytkownika o potwierdzenie, czy skrypt jest podpisany przez wydawcę, który nie został jeszcze zdefiniowany jako zaufany lub niezaufany. Jeśli nie podpisałeś cyfrowo skryptu profilu i nie ustanowiłeś zaufania do tego podpisu, nie będzie można go uruchomić. Uważaj na wydawców, którym ufasz, ponieważ nadal możesz uruchamiać złośliwe skrypty, jeśli ufasz niewłaściwemu.
RemoteSigned - W przypadku skryptów pobranych z Internetu jest to faktycznie to samo, co "AllSigned". Jednak skrypty utworzone lokalnie lub importowane ze źródeł innych niż Internet mogą być uruchamiane bez pytania o potwierdzenie. Musisz również uważać na zaufane podpisy cyfrowe, a nawet uważać na niezalogowane skrypty, które wybierzesz. Jest to najwyższy poziom bezpieczeństwa, pod którym można mieć działający skrypt profilu bez konieczności jego cyfrowego podpisywania.
Bez ograniczeń - Wszystkie skrypty mogą być uruchamiane, ale prośba o potwierdzenie będzie wymagana dla skryptów z Internetu. Od tego momentu całkowicie zależy od Ciebie, aby uniknąć uruchamiania niewiarygodnych skryptów.
Obejście - wszystko działa bez ostrzeżenia. Ostrożnie z tym.
Niezdefiniowane - w bieżącym zakresie nie zdefiniowano żadnej polityki. Służy to zezwoleniu na powrót do zasad zdefiniowanych w niższych zakresach (więcej szczegółów poniżej) lub do wartości domyślnych systemu operacyjnego.

Jak sugeruje opis Undefined, powyższe zasady można ustawić w jednym lub kilku z kilku zakresów. Możesz użyć Get-ExecutionPolicy, z parametrem -List, aby zobaczyć wszystkie zakresy i ich bieżącą konfigurację.

Zakresy są wymienione w kolejności pierwszeństwa, a najwyższy zdefiniowany zakres przesłania wszystkie pozostałe. Jeśli nie zdefiniowano żadnych zasad, system powraca do domyślnego ustawienia (w większości przypadków jest to Ograniczony).

MachinePolicy reprezentuje zasady grupy obowiązujące na poziomie komputera. Zasadniczo jest to stosowane wyłącznie w domenie, ale może być również wykonywane lokalnie.
UserPolicy reprezentuje zasady grupy obowiązujące użytkownika. Zwykle jest to również używane tylko w środowiskach korporacyjnych.
Proces to zakres specyficzny dla tego wystąpienia programu PowerShell. Zmiany zasad w tym zakresie nie będą miały wpływu na inne działające procesy PowerShell i staną się nieskuteczne po zakończeniu tej sesji. Można to skonfigurować za pomocą parametru -ExecutionPolicy po uruchomieniu PowerShell lub można go ustawić przy użyciu odpowiedniej składni Set-ExecutionPolicy z poziomu sesji.
CurrentUser to zakres skonfigurowany w lokalnym rejestrze i dotyczy konta użytkownika używanego do uruchamiania PowerShell. Ten zakres można zmodyfikować za pomocą Set-ExecutionPolicy.
LocalMachine to zakres skonfigurowany w lokalnym rejestrze i mający zastosowanie do wszystkich użytkowników w systemie. Jest to domyślny zakres, który zostanie zmieniony, jeśli funkcja Set-ExecutionPolicy zostanie uruchomiona bez parametru -Scope. Dotyczy to wszystkich użytkowników systemu, dlatego można go zmienić tylko z sesji podwyższonej.

Ponieważ ten artykuł dotyczy głównie poruszania się po bezpieczeństwie w celu ułatwienia korzystania z niego, jesteśmy zaniepokojeni tylko trzema niższymi zakresami. Ustawienia MachinePolicy i UserPolicy są przydatne tylko wtedy, gdy chcesz wymusić restrykcyjne zasady, które nie są po prostu ominięte. Utrzymując nasze zmiany na poziomie Procesu lub poniżej, możemy z łatwością użyć dowolnego ustawienia polityki, które uznamy za odpowiednie w danej sytuacji w dowolnym momencie.

Aby zachować równowagę między bezpieczeństwem a użytecznością, zasady pokazane na zrzucie ekranu są prawdopodobnie najlepsze. Ustawienie zasady LocalMachine na Ograniczone ogólnie zapobiega uruchamianiu skryptów przez kogokolwiek innego niż ty. Oczywiście może to ominąć użytkownik, który wie, co robi bez większego wysiłku. Powinien jednak uniemożliwić użytkownikom, którzy nie znają technologii, przypadkowe wywołanie czegoś katastrofalnego w PowerShell. Posiadanie CurrentUser (tj. Ciebie) ustawionej jako Unrestricted umożliwia ręczne wykonywanie skryptów z wiersza poleceń, jakkolwiek chcesz, ale zachowuje przypomnienie o skrypcie pobranym z Internetu. Ustawienie RemoteSigned na poziomie procesu powinno zostać wykonane w skrócie do programu PowerShell.exe lub (jak to zrobimy poniżej) w wartościach rejestru kontrolujących zachowanie skryptów PowerShell. Umożliwi to łatwą, podwójną funkcję "kliknij, aby uruchomić" dla wszystkich pisanych skryptów, jednocześnie zwiększając barierę przed niezamierzonym uruchamianiem (potencjalnie szkodliwych) skryptów ze źródeł zewnętrznych. Chcemy to zrobić tutaj, ponieważ znacznie łatwiej jest przypadkowo dwukrotnie kliknąć skrypt, niż na ogół wywoływać go ręcznie z interaktywnej sesji.

Aby ustawić zasady CurrentUser i LocalMachine jak na powyższym zrzucie ekranu, uruchom następujące polecenia z podwyższonej sesji PowerShell:

Set-ExecutionPolicy Restricted Set-ExecutionPolicy Unrestricted -Scope CurrentUser

Aby wymusić zasadę RemoteSigned dla skryptów uruchamianych z Eksploratora, będziemy musieli zmienić wartość wewnątrz jednego z kluczy rejestru, którego szukaliśmy wcześniej. Jest to szczególnie ważne, ponieważ w zależności od wersji PowerShell lub Windows domyślną konfiguracją może być ominięcie wszystkich ustawień ExecutionPolicy z wyjątkiem AllSigned. Aby zobaczyć, jaka jest aktualna konfiguracja twojego komputera, możesz uruchomić to polecenie (upewniając się, że HKCR PSDrive jest zamapowany jako pierwszy):

Get-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command | Wybierz obiekt "(domyślnie)"

Domyślną konfiguracją będzie prawdopodobnie jeden z następujących dwóch łańcuchów lub coś podobnego:

(Widziany w Windows 7 SP1 x64, z PowerShell 2.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-file" "% 1"

(Widziany w Windows 8.1 x64, z PowerShell 4.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "if ((Get-ExecutionPolicy) -ne" AllSigned ") Set-ExecutionPolicy-Bypass procesu obejścia; & '% 1 ""

Pierwszy nie jest taki zły, ponieważ wykonuje tylko skrypt w istniejących ustawieniach ExecutionPolicy. Mogłoby być lepiej, poprzez egzekwowanie bardziej rygorystycznych ograniczeń dla bardziej podatnych na wypadki działań, ale pierwotnie nie miało to być wyzwalane dwukrotnym kliknięciem, a domyślna polityka jest zwykle ograniczona. Drugą opcją jest pełne obejście jakiejkolwiek opcji ExecutionPolicy, którą prawdopodobnie będziesz mieć - nawet ograniczonej. Ponieważ obejście zostanie zastosowane w zakresie procesu, ma wpływ tylko na sesje uruchamiane podczas uruchamiania skryptów z Eksploratora. Oznacza to jednak, że możesz skończyć uruchamiając skrypty, których możesz oczekiwać (i chcesz), aby zasady zabraniały.

Aby ustawić opcję ExecutionPolicy na poziomie procesu dla skryptów uruchamianych z Eksploratora, zgodnie z powyższym zrzutu ekranu musisz zmodyfikować tę samą wartość rejestru, którą właśnie wysłaliśmy. Możesz to zrobić ręcznie w Regedit, zmieniając go na:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1"

Możesz także zmienić ustawienie z poziomu PowerShell, jeśli wolisz. Pamiętaj, aby zrobić to z podwyższonej sesji, z mapą HKCR PSDrive.

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command '(domyślnie) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -ExecutionPolicy "" RemoteSigned "" -file "" % 1 ""

Uruchom skrypty PowerShell jako administrator.

Zupełnie nieudanym pomysłem jest całkowite wyłączenie funkcji UAC. Złe praktyki zabezpieczeń to także uruchamianie skryptów lub programów z podwyższonymi uprawnieniami, chyba że są one rzeczywiście potrzebne do wykonywania operacji wymagających dostępu administratora. Dlatego też nie zaleca się budowania polecenia UAC w domyślnej akcji dla skryptów PowerShell. Możemy jednak dodać nową opcję menu kontekstowego, aby umożliwić nam łatwe uruchamianie skryptów w podwyższonych sesjach, gdy zajdzie taka potrzeba. Jest to podobne do metody używanej do dodawania "Otwórz za pomocą Notatnika" do menu kontekstowego wszystkich plików - ale tutaj będziemy kierować tylko skrypty PowerShell. Zamierzamy również przenieść niektóre techniki używane w poprzednim artykule, w którym użyliśmy pliku wsadowego zamiast hacków rejestru, aby uruchomić nasz skrypt PowerShell.

Aby to zrobić w Regedit, wróć do klucza Shell, pod adresem:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Tam utwórz nowy podklucz. Nazwij go "Uruchom z PowerShell (Admin)". Pod tym, utwórz kolejny podklucz o nazwie "Command". Następnie ustaw wartość "(Domyślne)" w obszarze Polecenie na:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Komenda" "" & Rozpocznij-przetwarzanie PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File \ "% 1 \"' -Verb RunAs  "

Takie samo działanie w PowerShell będzie wymagało teraz trzech linii. Jeden dla każdego nowego klucza i jeden dla ustawienia "(Domyślne)" dla polecenia. Nie zapomnij o elewacji i mapowaniu HKCR.

Nowa pozycja "HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run with PowerShell (Admin)" Nowa pozycja "HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run z PowerShell (Admin) \ Command 'Set-ItemProperty' HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run z PowerShell (Admin) \ Command "(domyślnie)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" &  Start-Process PowerShell.exe -ArgumentList "-ExecutionPolicy RemoteSigned -File \"% 1 \ "" - czasownik RunAs "'

Zwróć też uwagę na różnice między ciągiem, który jest wprowadzany przez PowerShell, a rzeczywistą wartością, która trafia do rejestru. W szczególności, musimy owijać całość w pojedyncze cudzysłowy i podwoić wewnętrzne pojedyncze cudzysłowy, aby uniknąć błędów w parsowaniu poleceń.

Teraz powinieneś mieć nowy wpis w menu kontekstowym dla skryptów PowerShell o nazwie "Uruchom z PowerShell (Admin)".

Nowa opcja spowoduje utworzenie dwóch kolejnych instancji PowerShell. Pierwszy to tylko program uruchamiający dla drugiego, który używa Start-Process z parametrem "-Verb RunAs", aby poprosić o podniesienie poziomu dla nowej sesji. Stamtąd Twój skrypt powinien być uruchamiany z uprawnieniami administratora po kliknięciu w monit UAC.

Ostatnie poprawki.

Jest tylko kilka dodatkowych usprawnień, które mogą jeszcze bardziej ułatwić życie. Po pierwsze, w jaki sposób całkowicie pozbyć się funkcji Notatnika? Po prostu skopiuj wartość "(domyślnie)" z klawisza polecenia w obszarze Edytuj (poniżej), w tej samej lokalizacji w obszarze Otwórz.

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe" "% 1"

Lub możesz użyć tego trochę PowerShell (oczywiście z Admin & HKCR):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Open \ Command '(domyślnie) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe ""% 1 "'

Kolejną mniejszą irytacją jest zwyczaj znikania konsoli po ukończeniu skryptu. Kiedy tak się dzieje, nie mamy szansy na sprawdzenie wyniku skryptu pod kątem błędów lub innych przydatnych informacji. Można to załatwić, oczywiście, umieszczając pauzę na końcu każdego ze skryptów. Alternatywnie możemy zmodyfikować wartości "(domyślne)" dla naszych klawiszy poleceń, aby uwzględnić parametr "-NoExit". Poniżej znajdują się zmodyfikowane wartości.

(Bez dostępu administratora)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-NoExit" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1"

(Z dostępem administracyjnym)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Komenda" "" & Rozpocznij przetwarzanie PowerShell.exe -ArgumentList '-NoExit -ExecutionPolicy RemoteSigned -File \ "% 1 \"' - Czasownik "

Oczywiście, damy wam te również w poleceniach PowerShell. Ostatnie przypomnienie: Wysokość i HKCR!

(Non-Admin)

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command '(domyślnie) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -NoExit "" -ExecutionPolicy "" RemoteSigned "" -plik ""% 1 ""

(Administrator)

Set-ItemProperty 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Uruchom z PowerShell (Admin) \ Command "(domyślnie)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Komenda" "" & Rozpocznij przetwarzanie PowerShell.exe -ArgumentList "-NoExit -ExecutionPolicy RemoteSigned -File \"% 1 \ "" - czasownik RunAs "'

Biorąc to za spin.

Aby przetestować to, użyjemy skryptu, który może pokazać nam ustawienia ExecutionPolicy i czy skrypt został uruchomiony z uprawnieniami administratora. Skrypt będzie się nazywał "MyScript.ps1" i będzie przechowywany w "D: \ Script Lab" w naszym systemie próbek. Kod znajduje się poniżej, dla odniesienia.

if (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()). IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrator")) Write-Output "Działa jako administrator!" else Write-Output 'Running Limited!' Get-ExecutionPolicy -List

Korzystanie z akcji "Uruchom za pomocą programu PowerShell":

Korzystanie z akcji "Uruchom z PowerShell (Admin)" po kliknięciu w UAC:

Aby zademonstrować działanie ExecutionPolicy w zakresie Procesu, możemy sprawić, że system Windows będzie myślał, że plik pochodzi z Internetu z tym kodem PowerShell:

Add-Content -Path 'D: \ Script Lab \ MyScript.ps1' -Value "[ZoneTransfer] 'nZoneId = 3" -Stream' Zone.Identifier "

Na szczęście mieliśmy -NoExit włączone. W przeciwnym razie błąd ten byłby tylko mrugnięty, a my nie wiedzielibyśmy!

Identyfikator Zone.Identifier można usunąć za pomocą tego:

Wyczyść-treść -Path 'D: \ Script Lab \ MyScript.ps1' -Stream 'Zone.Identifier'

Przydatne referencje:

Uruchamianie skryptów PowerShell z pliku wsadowego - blog programisty Daniela Schroedera
Sprawdzanie uprawnień administratora w PowerShell - Hej, skrypciarze! Blog