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

Systemy 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 wymagają pisania i uruchamiania 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.

W jaki sposób i dlaczego Windows i PowerShell uniemożliwiają wykonanie skryptu.

PowerShell jest efektywnie 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 są nic, co można zrobić, aby rozwiązać problem. Co może być gorsze, zamiast dostać skrypt, który po prostu zgłasza swój system plików, twój przyjaciel może zostać oszukany do uruchomienia jednego, 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 sobie z tym poradzić.

Te same problemy zostały poruszone w temacie Jak korzystać z pliku wsadowego, aby skrypty PowerShell były łatwiejsze do uruchomienia, gdzie 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órych te funkcje mają zapobiegać.

Zmiana powiązania plików .PS1.

Pierwszą, a może przede wszystkim, irytacją do obejścia jest domyślne powiązanie 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 na pełne przejście do funkcji podwójnego kliknięcia, prawdopodobnie będziesz chciał dostosować te ustawienia.

Możesz zmienić skojarzenie plików .PS1 z dowolnym programem za pomocą panelu sterowania Domyślne programy, ale bezpośrednie przeszukanie rejestru pozwoli ci uzyskać większą kontrolę nad tym, jak dokładnie pliki zostaną otwarte. Umożliwia to także 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 zbadać wartości w nim zawarte, ale zasadniczo 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 właśnie pobierany 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, że plik "otworzy" go, a ta czynność jest zwykle ustawiona na korzystanie z Notatnika.

Jeśli chcesz trzymać się gotowych ciągów poleceń już dostępnych, możesz po prostu zmienić wartość "(Domyślna)" w kluczu Shell, aby dopasować nazwę klucza, który pasuje do tego, co chcesz zrobić dwukrotnie. Można to łatwo zrobić z Regedit lub możesz skorzystać z lekcji wyniesionych z naszego samouczka na temat odkrywania rejestru za pomocą PowerShell (plus niewielka korekta 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. Poleceniem 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ć domyślną wartość (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 zajmiemy się dostosowywaniem sposobu obsługi skryptów PowerShell po otwarciu w PowerShell z Explorera w następnej sekcji. Pamiętaj, że scoping zapobiega utrzymywaniu się PSDrives w różnych sesjach. Najprawdopodobniej zechcesz dołączyć linię New-PSDrive na początku każdego skryptu konfiguracyjnego stworzonego do tego celu lub dodać ją do swojego profilu PowerShell. W przeciwnym razie przed wykonaniem zmian w ten sposób musisz uruchomić ten bit ręcznie.

Zmiana ustawienia PowerShell ExecutionPolicy.

PowerShell's 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:

• Ograniczony - nie można uruchamiać żadnych skryptów. (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 też 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.
• Nieograniczone - 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.

Zgodnie z sugestią zawartą w opisie niezdefiniowanej, powyższe zasady można ustawić w co najmniej jednym 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 ustawienia domyślnego (w większości przypadków jest to Ograniczony).

• MachinePolicy reprezentuje zasady grupy obowiązujące na poziomie komputera. Zasadniczo jest to stosowane tylko 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 wpłyną 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ć za pomocą odpowiedniej składni Set-ExecutionPolicy z sesji.
• CurrentUser to zasięg skonfigurowany w lokalnym rejestrze i ma zastosowanie do konta użytkownika użytego do uruchomienia 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 podwyższonej sesji.

Ponieważ ten artykuł dotyczy głównie poruszania się po bezpieczeństwie w celu ułatwienia korzystania, obawiamy się tylko trzech niższych zakresów. 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 stosowne 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 mogą to ominąć użytkownicy, którzy wiedzą, 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 pozwala ci ręcznie uruchamiać skrypty z wiersza poleceń, jakkolwiek chcesz, ale zachowuje upomnienie o skrypty pobierane 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 kliknąć dwukrotnie skrypt, niż na ogół wywoływać go ręcznie z sesji interaktywnej.

Aby ustawić zasady CurrentUser i LocalMachine jak na powyższym zrzucie ekranu, uruchom następujące komendy 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óry 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 komputera, możesz uruchomić to polecenie (upewniając się, że dysk HKCR PSDrive jest najpierw odwzorowany):

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ż wszystko, co robi, to wykonanie skryptu 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ć uruchomione po dwukrotnym kliknięciu, 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 również 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. Jednakże możemy dodać nową opcję menu kontekstowego, aby umożliwić nam łatwe uruchamianie skryptów w podwyższonych sesjach, kiedy 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órych 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ślnie)" w obszarze Polecenie na:

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

Powtórzenie tego w PowerShellu będzie wymagało trzech linii tym razem. 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 zawinąć 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 przez monit UAC.

Ostatnie poprawki.

Jest tylko kilka dodatkowych usprawnień, które mogą pomóc ci jeszcze bardziej uprościć ż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 "'

Jeszcze mniejszym przykrością jest zwyczaj znikania konsoli po ukończeniu skryptu. Kiedy tak się dzieje, nie mamy żadnej 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" "-Command" "" & Rozpocznij-przetwarzanie PowerShell.exe -ArgumentList '-NoExit -ExecutionPolicy RemoteSigned -File \ "% 1 \"' - Czasownik "

Oczywiście, damy ci te również w poleceniach PowerShell. Ostatnie przypomnienie: Elewacja 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" "-Kommand" "" & 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óbkowania. 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 byśmy o tym nie wiedzieli!

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 programistyczny Daniela Schroedera
• Sprawdzanie uprawnień administratora w PowerShell - Hej, skrypciarze! Blog