Cum se configurează Windows să lucreze mai ușor cu scripturile PowerShell

Windows și PowerShell au caracteristici de securitate încorporate și configurații implicite destinate să împiedice utilizatorii finali să lanseze în mod accidental scripturi în cursul activităților lor zilnice. Cu toate acestea, în cazul în care activitățile zilnice implică în mod obișnuit scrierea și rularea propriilor scripturi PowerShell, aceasta poate fi mai mult o provocare decât un beneficiu. Aici, vă vom arăta cum să rezolvați aceste caracteristici fără a compromite complet siguranța.

Cum și de ce Windows & PowerShell împiedică execuția scriptului.

PowerShell este în mod eficient shell-ul de comandă și limbajul de scripting care intenționează să înlocuiască CMD și scripturile batch pe sistemele Windows. Ca atare, un script PowerShell poate fi destul de mult configurat să facă tot ce ai putea face manual din linia de comandă. Asta înseamnă să faci practic orice schimbare posibilă în sistemul tău, până la restricțiile care există în contul tău de utilizator. Deci, dacă ați putea să faceți dublu-clic pe un script PowerShell și să îl rulați cu privilegii complete de Administrator, un simplu paragraf de acest gen ar putea chiar să vă distrugă ziua:

Get-ChildItem "$ env: SystemDrive \" -Recurse -ErrorAction SilentlyContinue | Eliminați-Element -Force -Recurse -ErrorAction SilentlyContinue

NU executați comanda de mai sus!

Acest lucru merge pur și simplu prin sistemul de fișiere și șterge orice poate. Interesant este că acest lucru nu poate face sistemul inoperabil cât de repede puteți crede - chiar și atunci când conduceți dintr-o sesiune ridicată. Dar dacă cineva vă sună după ce a executat acest script, deoarece dintr-o dată nu își pot găsi fișierele sau nu poate rula anumite programe, "oprirea și pornirea" probabil va duce doar la Windows Startup Repair unde vor fi spus că este nimic nu se poate face pentru a rezolva problema. Ce ar putea fi mai rău este că, în loc să obțineți un script care doar tras sistemul lor de fișiere, prietenul dvs. ar putea fi înșelat să ruleze unul care descărc și instalează un keylogger sau un serviciu de acces la distanță. Apoi, în loc să vă punem întrebări despre reparații la pornire, acestea pot sfârși prin a cere poliției câteva întrebări despre frauda bancară!

Până acum ar trebui să fie evident de ce anumite lucruri sunt necesare pentru a proteja utilizatorii finali de ei înșiși, ca să spunem așa. Dar utilizatorii de putere, administratorii de sistem și alți geeks sunt, în general (deși există excepții) un pic mai precaut de aceste amenințări, știind cum să le arate și să le evite cu ușurință, și doresc doar să lucreze mai bine. Pentru a face acest lucru, va trebui fie să dezactiveze sau să lucreze în jurul câtorva blocuri rutiere:

• PowerShell nu permite execuția script-ului extern în mod implicit.
  Setarea ExecutionPolicy din PowerShell previne implicit execuția de script-uri externe în toate versiunile de Windows. În unele versiuni Windows, implicit nu permite executarea script-ului. V-am arătat cum să modificați această setare în Cum să permiteți executarea scripturilor PowerShell pe Windows 7, dar o vom acoperi și pe câteva niveluri aici.
• PowerShell nu este asociat implicit cu extensia .PS1.
  Am adus acest lucru inițial în seria PowerShell Geek School. Windows stabilește acțiunea implicită pentru fișierele .PS1 pentru a le deschide în Notepad, în loc să le trimită interpretului de comandă PowerShell. Acest lucru este de a preveni în mod direct executarea accidentală a script-urilor malware atunci când acestea sunt pur și simplu dublu-clic.
• Unele scripturi PowerShell nu vor funcționa fără permisiuni de administrator.
  Chiar și în cazul unui cont la nivel de Administrator, trebuie să continuați să efectuați anumite acțiuni prin controlul contului de utilizator (UAC). Pentru instrumentele de linie de comandă, acest lucru poate fi puțin cam greu de spus. Nu vrem să dezactivați UAC, dar este încă plăcut când putem face ceva mai ușor de rezolvat.

Aceleasi probleme sunt aduse in modul de utilizare a unui fisier batch pentru a face scripturile PowerShell mai usor de rulat, unde ne indreptam spre scrierea unui fisier batch pentru a le face temporar. Acum, vă vom arăta cum să vă configurați sistemul cu o soluție mai lungă. Rețineți că, în general, nu trebuie să efectuați aceste modificări pe sisteme care nu sunt utilizate exclusiv de către dvs. - în caz contrar, puneți alți utilizatori la risc mai mare de a se întâlni în aceleași probleme pe care aceste caracteristici le pot preveni.

Schimbarea asocierii fișierelor .PS1.

Prima, și probabil cea mai mare, supărare pentru a obține în jur este asocierea implicită pentru fișierele .PS1. Asocierea acestor fișiere cu orice altceva decât PowerShell.exe are sens pentru a împiedica executarea accidentală a scenariilor nedorite. Dar, având în vedere că PowerShell vine cu un mediu integrat de scripting (ISE), care este special conceput pentru editarea scripturilor PowerShell, de ce am dori să deschidem fișierele .PS1 în Notepad în mod implicit? Chiar dacă nu sunteți gata să treceți complet la activarea funcționalității dublu-clic-pentru-a alerga, probabil că doriți să modificați aceste setări.

Puteți schimba asocierea fișierului .PS1 cu orice program doriți cu panoul de control Implicit Programe, dar saparea direct în Registru vă va oferi un pic mai mult control asupra modului exact în care fișierele vor fi deschise. Acest lucru vă permite, de asemenea, să setați sau să modificați opțiunile suplimentare disponibile în meniul contextual pentru fișierele .PS1. Nu uitați să efectuați o copie de rezervă a registrului înainte de a face acest lucru!

Setările de registry care controlează modul în care sunt deschise scripturile PowerShell sunt stocate în următoarea locație:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Pentru a explora aceste setări înainte de a le schimba, aruncați o privire asupra acelei chei și a sub-cheilor cu Regedit. Cheia Shell ar trebui să aibă doar o valoare, "(Default)", care este setată la "Open".Acesta este un indicator al acțiunii implicite pentru dublul clic pe fișier, pe care îl vom vedea în sub-chei.

Extindeți cheia Shell și veți vedea trei sub-chei. Fiecare dintre acestea reprezintă o acțiune pe care o puteți efectua și care este specifică pentru scripturile PowerShell.

Aveți posibilitatea să extindeți fiecare cheie pentru a explora valorile din cadrul acesteia, dar în principiu acestea sunt egale cu următoarele valori prestabilite:

• 0 - Rulați cu PowerShell. "Run with PowerShell" este de fapt numele unei opțiuni deja din meniul contextual pentru scripturi PowerShell. Textul este tras de la o altă locație în loc să utilizeze numele cheii ca și celelalte. Și încă nu este acțiunea implicită dublu-clic.
• Editați - Deschideți în PowerShell ISE. Acest lucru are mult mai mult sens decât Notepad, dar tot trebuie să faceți clic dreapta pe fișierul .PS1 pentru ao face în mod implicit.
• Deschideți - Deschideți în Notepad. Rețineți că acest nume de cheie este, de asemenea, șirul stocat în valoarea "(implicită)" a cheii Shell. Aceasta înseamnă că faceți dublu-clic pe fișierul care îl va "Deschide", iar acea acțiune este în mod normal setată să folosească Notepad.

Dacă doriți să vă lipiți de șirurile de comandă pre-construite deja disponibile, puteți să schimbați valoarea "(Implicit)" din cheia Shell pentru a se potrivi cu numele cheii care corespunde cu ceea ce doriți să faceți dublu-clic. Acest lucru se poate face cu ușurință din cadrul programului Regedit sau puteți folosi lecțiile învățate din tutorialul nostru privind explorarea registrului cu PowerShell (plus un mic PSDrive tweak) pentru a începe să construiți un script reutilizabil care vă poate configura sistemele pentru dvs. Comenzile de mai jos trebuie executate dintr-o sesiune PowerShell ridicată, similar cu executarea CMD ca Administrator.

Mai întâi, veți dori să configurați o PSDrive pentru HKEY_CLASSES_ROOT, deoarece aceasta nu este configurată în mod prestabilit. Comanda pentru aceasta este:

Registrul HKCR nou-PSDrive HKEY_CLASSES_ROOT

Acum puteți naviga și modifica cheile de registry și valorile din HKEY_CLASSES_ROOT la fel ca în HKCU și HKLM PSDrives.

Pentru a configura dublu-clic pentru a lansa scripturile PowerShell direct:

Setați-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(Implicit)' 0

Pentru a configura dublu clic pentru a deschide scripturi PowerShell în PowerShell ISE:

Setați-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(Implicit) "Editați"

Pentru a restabili valoarea implicită (setați dublu clic pentru a deschide scripturi PowerShell în Notepad):

Setați-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell "(implicit)" Deschideți "

Acestea sunt doar principiile de modificare a acțiunii implicite dublu-clic. Vom detalia modul în care sunt gestionate scripturile PowerShell când sunt deschise în PowerShell de la Explorer în secțiunea următoare. Rețineți că definirea domeniului împiedică persistența PSDrives în toate sesiunile. Deci, probabil că doriți să includeți linia New PSDrive la începutul oricărui script de configurare pe care îl construiți în acest scop sau să îl adăugați în profilul dvs. PowerShell. În caz contrar, va trebui să rulați acest bit manual înainte de a încerca să faceți modificări în acest fel.

Modificarea setării PowerShell ExecutionPolicy.

PowerShell's ExecutionPolicy este un alt nivel de protecție împotriva executării de scripturi malware. Există mai multe opțiuni pentru acest lucru și câteva moduri diferite de a fi setate. De la cele mai puțin la cele mai puțin sigure, opțiunile disponibile sunt:

• Restricționată - nu sunt permise să ruleze scripturi. (Setare implicită pentru majoritatea sistemelor.) Acest lucru va împiedica funcționarea scriptului de profil.
• AllSigned - Toate scripturile trebuie semnate digital de către un editor de încredere pentru a fi difuzate fără a solicita utilizatorului. Scripturile semnate de către editori definite în mod explicit ca neîncredere sau scripturile care nu au fost semnate digital deloc nu vor fi difuzate. PowerShell va solicita utilizatorului confirmarea dacă un script este semnat de un editor care încă nu este definit ca fiind de încredere sau nu este de încredere. Dacă nu ați semnat digital scenariul de profil și ați stabilit încrederea în acea semnătură, acesta nu va putea să ruleze. Aveți grijă editorilor pe care îi aveți încredere, deoarece în continuare puteți rula scripturi malware dacă aveți încredere în cel rău.
• RemoteSigned - Pentru scripturile descărcate de pe Internet, aceasta este în mod similar aceeași cu "AllSigned". Cu toate acestea, script-urile create local sau importate din alte surse decât Internetul sunt permise să ruleze fără nici un prompt de confirmare. Aici, va trebui să fiți atent și la semnăturile digitale în care aveți încredere, dar chiar să fiți mai atenți la scripturile ne-semnate pe care le alegeți să le executați. Acesta este cel mai înalt nivel de securitate în care puteți avea un script de profil de lucru fără a trebui să îl semnați digital.
• Fără restricții - toate scripturile sunt permise să ruleze, însă va fi necesar un mesaj de confirmare pentru scripturi de pe Internet. Din acest punct de vedere, depinde în întregime de dvs. să evitați să faceți scripturi de neîntemeiate.
• Bypass - Totul rulează fără avertisment. Fii atent cu asta.
• Nedefinit - în domeniul de aplicare actual nu este definită nicio politică. Acest lucru este folosit pentru a permite revenirea la politicile definite în domeniile inferioare (mai multe detalii de mai jos) sau la setările implicite ale sistemului de operare.

După cum este sugerat de descrierea Undefined, politicile de mai sus pot fi stabilite într-unul sau mai multe domenii. Puteți utiliza Get-ExecutionPolicy, cu parametrul -List, pentru a vedea toate domeniile și configurația lor actuală.

Domeniile sunt listate în ordinea precedentă, cu domeniul de aplicare definit de cel mai înalt nivel suprasolicitând toate celelalte. Dacă nu sunt definite politici, sistemul revine la setarea implicită (în majoritatea cazurilor, acesta este restricționat).

• MachinePolicy reprezintă o politică de grup în vigoare la nivelul computerului. Acest lucru este, în general, aplicat numai într-un domeniu, dar se poate face și pe plan local.
• UserPolicy reprezintă o politică de grup în vigoare pentru utilizator. De asemenea, acest lucru este, de obicei, utilizat numai în mediile de afaceri.
• Procesul este un domeniu specific pentru acest exemplu de PowerShell. Modificările politicii din acest domeniu nu vor afecta alte procese care rulează PowerShell și vor fi ineficiente după terminarea acestei sesiuni. Acest lucru poate fi configurat de parametrul -ExecutionPolicy atunci când este lansat PowerShell sau poate fi setat cu sintaxa Set-ExecutionPolicy corespunzătoare din cadrul sesiunii.
• Utilizatorul curent este un domeniu care este configurat în registrul local și se aplică contului de utilizator utilizat pentru a lansa PowerShell. Acest domeniu de aplicare poate fi modificat cu Set-ExecutionPolicy.
• LocalMachine este un domeniu configurat în registrul local și aplicabil tuturor utilizatorilor din sistem. Acesta este domeniul implicit care se modifică dacă Set-ExecutionPolicy este executat fără parametrul -Scope. Întrucât se aplică tuturor utilizatorilor din sistem, acesta poate fi modificat numai dintr-o sesiune ridicată.

Deoarece acest articol se referă în principal la obținerea securității pentru a facilita utilizarea, suntem doar preocupați de cele trei domenii inferioare. Setările MachinePolicy și UserPolicy sunt într-adevăr utile numai dacă doriți să impuneți o politică restrictivă care nu este atât de simplu ocolită. Prin păstrarea modificărilor noastre la nivel de Proces sau mai jos, putem folosi oricând orice setare de politică pe care o considerăm potrivită pentru o anumită situație în orice moment.

Pentru a menține un echilibru între securitate și utilitate, politica afișată în captura de ecran este probabil cea mai bună. Setarea politicii LocalMachine la Restricted în general împiedică executarea de script-uri de către oricine altul decât dvs. Desigur, acest lucru poate fi ocolit de utilizatori care știu ce fac fără prea mult efort. Dar ar trebui să păstreze orice utilizator non-tech savvy de la declanșarea accidentală ceva catastrofal în PowerShell. Având setarea curentă a aplicației curentă (adică: dvs.) ca nerestricționată, puteți executa manual scripturi din linia de comandă, oricum doriți, dar reține un avertisment de precauție pentru scripturile descărcate de pe Internet. Setarea RemoteSigned la nivel de proces ar trebui făcută într-o comandă rapidă către PowerShell.exe sau (după cum vom proceda mai jos) în valorile din Registrul care controlează comportamentul scripturilor PowerShell. Acest lucru va permite o ușurință ușoară cu dublu clic pe funcționalitate pentru toate scripturile pe care le scrieți, oferind în același timp o barieră mai puternică împotriva executării neintenționate a scripturilor (potențial malware) din surse externe. Vrem să facem acest lucru aici, deoarece este mult mai ușor să dai dublu clic pe un script decât să îl numești manual dintr-o sesiune interactivă.

Pentru a seta politicile CurrentUser și LocalMachine ca în captura de ecran de mai sus, executați următoarele comenzi dintr-o sesiune PowerShell elevată:

Set-ExecutionPolicy Restricted Set-ExecutionPolicy Nerestricționat -Scope CurrentUser

Pentru a aplica politica RemoteSigned pe scripturile care rulează din Explorer, va trebui să schimbăm o valoare în interiorul uneia dintre cheile de registry la care ne-am uitat mai devreme. Acest lucru este deosebit de important deoarece, în funcție de versiunea dvs. PowerShell sau Windows, configurația implicită ar putea fi ocolirea tuturor setărilor de ExecutionPolicy, cu excepția AllSigned. Pentru a vedea ce configurație actuală este pentru computerul dvs., puteți rula această comandă (asigurându-vă că HKCR PSDrive este cartografiat mai întâi):

Obțineți-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command | Selectați-Obiect '(Implicit)'

Configurația implicită va fi probabil una dintre următoarele două șiruri de caractere, sau ceva destul de similar:

(Văzut pe Windows 7 SP1 x64, cu PowerShell 2.0)

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

(Văzut pe Windows 8.1 x64, cu PowerShell 4.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "dacă ((Get-ExecutionPolicy) -ne 'AllSigned') Set -Policy Execution -Scope Process Bypass; „“

Primul nu este prea rău, deoarece tot ceea ce face este să executați scriptul în cadrul setărilor existente de executare politică. S-ar putea face mai bine, prin impunerea unor restricții mai stricte pentru o acțiune mai predispusă la accidente, dar acest lucru nu a fost intenționat inițial să fie declanșat printr-un dublu clic oricum și politica implicită este, de obicei, restricționată. Cea de-a doua opțiune este, totuși, o ocolire completă a oricărei ExecuțiePolicy pe care o veți avea probabil - chiar Restricted. Deoarece bypass-ul va fi aplicat în domeniul de aplicare al procesului, acesta afectează numai sesiunile lansate atunci când script-urile sunt executate de la Explorer. Cu toate acestea, aceasta înseamnă că puteți termina lansarea de scripturi pe care altfel le-ați putea aștepta (și doriți) ca politica dvs. să interzică.

Pentru a seta ExecutionPolicy la nivel de proces pentru scripturile lansate de la Explorer, în conformitate cu captura de ecran de mai sus, va trebui să modificați aceeași valoare a registry pe care tocmai am interogat-o. Puteți să o faceți manual în Regedit, schimbând-o la acest lucru:

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

De asemenea, puteți schimba setarea din cadrul PowerShell dacă preferați. Amintiți-vă să faceți acest lucru dintr-o sesiune ridicată, mapată cu HKCR PSDrive.

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command "(implicit)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "ExecutareaPolicy" % 1" “

Porniți scripturile PowerShell ca Administrator.

Așa cum este o idee proastă de a dezactiva UAC în întregime, este de asemenea o practică de securitate incorectă de a rula scripturi sau programe cu privilegii ridicate, cu excepția cazului în care de fapt aveți nevoie de ele pentru a efectua operații care necesită acces la Administrator. Deci, nu se recomandă construirea unui prompt UAC în acțiunea implicită pentru scripturile PowerShell. Cu toate acestea, putem adăuga o nouă opțiune de meniu contextual pentru a ne permite să rulați cu ușurință scripturi în sesiuni înalte atunci când este necesar. Acest lucru este similar cu metoda folosită pentru a adăuga "Open with Notepad" în meniul contextual al tuturor fișierelor - dar aici vom viza numai scripturile PowerShell.De asemenea, vom trece câteva tehnici utilizate în articolul precedent, unde am folosit un fișier batch în loc de hack-uri pentru a lansa scriptul PowerShell.

Pentru a face acest lucru în Regedit, reveniți în cheia Shell, la:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Înăuntru, creați un nou sub-cheie. Sunați-l "Rulați cu PowerShell (Admin)". Sub aceasta, creați o altă sub-cheie numită "Comandă". Apoi, setați valoarea "(Implicit)" de sub Comandă la aceasta:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File \ "% 1 \"' “

A face același lucru în PowerShell va avea nevoie de trei linii de data asta. Unul pentru fiecare cheie nouă și unul pentru a seta valoarea "(Implicit)" pentru Comandă. Nu uitați elevarea și maparea HKCR.

HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run cu PowerShell (Admin) 'New-Item' HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run cu PowerShell (Admin) \ Command "(Implicit)" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe " Start-Process PowerShell.exe -ArgumentList "-ExecuțiePolicy RemoteSigned -File \"% 1 \ "" - Verb RunAs "'

De asemenea, acordați o atenție deosebită diferențelor dintre șirul care este introdus prin PowerShell și valoarea reală care intră în Registru. În mod special, trebuie să înfășurăm întreaga chestiune în ghilimele simple și să ducem la o singură ghilimă internă, pentru a evita erorile în parsarea comenzilor.

Acum ar trebui să aveți o nouă intrare din meniul de context pentru scripturi PowerShell, numită "Run with PowerShell (Admin)".

Noua opțiune va produce două instanțe PowerShell consecutive. Primul este doar un lansator pentru cel de-al doilea, care folosește Start-Process cu parametrul "-Verb RunAs" pentru a cere altitudine pentru noua sesiune. De acolo, scriptul dvs. ar trebui să poată rula cu privilegii de administrator după ce faceți clic pe promptul UAC.

Ultimele retușuri.

Există doar câteva modificări pentru acest lucru, care pot ajuta la îmbunătățirea vieții. Pentru unul, cum să scapi complet de funcția Notepad? Trebuie doar să copiați valoarea "(Implicit)" din tasta de comandă din "Editare" (mai jos), în aceeași locație, sub Open.

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

Sau, puteți folosi acest bit de PowerShell (cu Admin & HKCR, desigur):

Setați-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Open \ Command (implicit) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe "

O altă supărare minore este obiceiul consolei de a dispărea odată ce un script este complet. Când se întâmplă acest lucru, nu avem nicio șansă să examinăm rezultatele scriptului pentru erori sau alte informații utile. Acest lucru poate fi luat în considerare prin a pune o pauză la sfârșitul fiecărui scenariu, desigur. Alternativ, putem modifica valorile "(Implicit)" pentru tastele noastre de comandă pentru a include parametrul "-NoExit". Mai jos sunt valorile modificate.

(Fara acces Admin)

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

(Cu acces Admin)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Start-Process PowerShell.exe -ArgumentList '-NoExit-ExecutionPolicy RemoteSigned -File \ "% 1 \ Verb RunAs "

Și, bineînțeles, vă vom da și comenzile PowerShell. Ultimul memento: Elevation & HKCR!

(Non-Admin)

Setarea elementului de proprietate HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command (implicit) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -NoExit ""-ExecutionPolicy" "RemoteSigned" -file ""% 1 ""

(Admin)

Setare -Proprietate "HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run cu PowerShell (Admin) \ Command" (implicit) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe " "&" Start-Process PowerShell.exe -ArgumentList "-NoExit -ExecutionPolicySignedSigned -File \"% 1 \ "" - Verb RunAs

Luând-o pentru o rotire.

Pentru a testa acest lucru, vom folosi un script care ne poate arăta setările ExecutionPolicy în vigoare și dacă scriptul a fost sau nu lansat cu permisiuni de administrator. Scriptul va fi numit "MyScript.ps1" și va fi stocat în "D: \ Script Lab" pe sistemul nostru de probă. Codul este de mai jos, pentru referință.

dacă [[Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()) IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrator")) Scriere-ieșire "Rularea ca Administrator! Write-Output 'Running Limited!' Get-ExecutionPolicy -List

Folosind acțiunea "Run with PowerShell":

Folosind acțiunea "Run with PowerShell (Admin)", după ce faceți clic pe UAC:

Pentru a demonstra ExecutionPolicy în acțiune la domeniul de aplicare al procesului, putem face Windows să creadă că fișierul a venit de pe Internet cu acest bit de cod PowerShell:

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

Din fericire, am activat-NoExit. În caz contrar, acea eroare ar fi trebuit să clipească și nu am fi știut!

Zone.Identifier poate fi eliminat cu următorul text:

Clear-Content -Path "D: \ Script Lab \ MyScript.ps1 '-Stream" Zone.Identifier "

Referințe utile:

• Executarea scripturilor PowerShell dintr-un fișier batch - Blogul de programare al lui Daniel Schroeder
• Verificarea permisiunilor de administrator în PowerShell - Hei, Scripting Guy! Blog