Cum se configurează Windows pentru a lucra cu scripturi PowerShell mai ușor

Windows și PowerShell au caracteristici de securitate integrate ș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 și PowerShell împiedică execuția de script-uri.

PowerShell este în mod eficient shell-ul de comandă și limba 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ă. Acest lucru înseamnă că ați făcut practic orice schimbare posibilă pe sistemul dvs., până la restricțiile în vigoare în contul dvs. 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, o simplă linie unică ca aceasta 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!

Aceasta pur și simplu trece 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 alergi dintr-o sesiune ridicată. Dar dacă vă sună cineva după ce ați rulat acest script, pentru că dintr-o dată nu își pot găsi fișierele sau nu pot rula unele programe, "oprirea și pornirea" probabil va duce doar la Windows Startup Repair unde vor fi anunțate că există nimic nu se poate face pentru a rezolva problema. Ce ar putea fi mai rău este, î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 serviciu de acces la distanță. Apoi, în loc să vă punem întrebări despre Reparația de pornire, s-ar putea să sfătuiți poliția cu câteva întrebări despre frauda bancară!

Până acum ar trebui să fie evident de ce sunt necesare anumite lucruri 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 executarea script-ului extern în mod implicit.
Setarea ExecutionPolicy din PowerShell previne implicit executarea 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 nivele 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 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 cu un cont la nivel de Administrator, tot trebuie să treci prin Controlul Contului de Utilizator (UAC) pentru a efectua anumite acțiuni. 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ă frumos atunci 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 vom indruma prin scrierea unui fisier batch pentru a ajunge in jurul lor 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 dvs. - în caz contrar, puneți alți utilizatori la un risc mai mare de a rula în aceleași probleme pe care aceste caracteristici sunt menite să le împiedice.

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 scripturilor 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 pregătit să treceți complet la activarea funcționalității cu dublu clic pe execuție, probabil că veți dori să modificați aceste setări.

Puteți schimba asocierea fișierului .PS1 cu orice program doriți cu panoul de control Implicit, dar saparea directă în Registru vă va oferi un control mai exact asupra modului î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ă faceț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 la acea cheie și sub-cheile acesteia cu Regedit. Cheia Shell ar trebui să aibă doar o singură valoare, "(Default)", 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ă scripturilor PowerShell.

Aveți posibilitatea să extindeți fiecare cheie pentru a explora valorile din cadrul acesteia, dar ele sunt, în esență, 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 scripturile PowerShell. Textul este tras de la o altă locație în loc să folosească numele cheii ca celelalte. Și nu este încă acțiunea implicită dublu-clic.
Editați - Deschideți în PowerShell ISE. Acest lucru are mult mai mult sens decât Notepad, dar 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ă utilizeze 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 pentru a explora registrul 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 să fie difuzate dintr-o sesiune PowerShell ridicată, similară executării 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 cum ați proceda î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ă PSDrives-ul să persiste î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 la 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.

Schimbarea setării PowerShell ExecutionPolicy.

PowerShell's ExecutionPolicy este un alt nivel de protecție împotriva execuției de scripturi malware. Există mai multe opțiuni pentru aceasta ș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. (Setarea implicită pentru majoritatea sistemelor.) Acest lucru va împiedica funcționarea scriptului de profil.
AllSigned - Toate scripturile trebuie să fie semnate digital de 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, de asemenea, care semnături digitale 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ă difuzați scripturi inexacte.
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 sugerează 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 se aplică în general 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 acestui exemplu de PowerShell. Modificările politicii din acest domeniu nu vor afecta alte procese de execuție PowerShell și vor fi ineficace după terminarea acestei sesiuni. Acest lucru poate fi configurat de parametrul -ExecutionPolicy când PowerShell este lansat sau poate fi setat cu sintaxa Set-ExecutionPolicy potrivită din cadrul sesiunii.
CurrentUser 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 cu adevărat 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 cu ușurință orice setare a politicilor pe care o considerăm potrivită pentru o anumită situație în orice moment.

Pentru a păstra un anumit 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ă rularea de scripturi de către oricine altul decât dumneavoastră. 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. Utilizarea aplicației CurrentUser (de exemplu: tine) ca nerestricționată vă permite să executați manual scripturi din linia de comandă, oricum doriți, dar păstrează un memento de prudență pentru scripturile descărcate de pe Internet. Setarea RemoteSigned la nivel de proces ar trebui făcută într-o comandă rapidă la 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, punând î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ă fie numit 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 ridicată:

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

Pentru a aplica politica RemoteSigned pe scripturile executate de la 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 să ocolească toate setările 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-Object (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 în ExecutarePolicy. 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 cu 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ții pe care probabil veți avea-o - chiar și cu restricții. Deoarece bypass-ul va fi aplicat în domeniul de aplicare al procesului, afectează doar sesiunile lansate atunci când script-urile sunt executate de la Explorer. Cu toate acestea, aceasta înseamnă că ați putea sfârși 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 de registry pe care tocmai am interogat-o. Puteți face acest lucru 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ă, cu ajutorul cartușului HKCR PSDrive.

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

Executaț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 crescute, 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 când este necesar. Acesta 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, în care am folosit un fișier batch în loc de hack-uri de registru 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 o 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 de fapt nevoie de trei linii de data asta. Unul pentru fiecare cheie nouă și unul pentru a seta valoarea "(Implicit)" pentru Comandă. Nu uitați elevația ș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 citate unice și să ne ducem la ghilimele interne simple, pentru a evita erorile în parsarea comenzilor.

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

Noua opțiune va produce două instanțe PowerShell consecutive. Primul este doar un lansator pentru 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 măsuri suplimentare 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 "Editați" (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 scenariu 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 punerea unei pauze 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" "-ExecuțiePolicy" "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)

Setați-PropertyProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command (implicit) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -NoExit "" -ExecutionPolicy "" RemoteSigned " -file ""% 1 ""

(Admin)

Set-ItemProperty '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")) Write-Output 'Running as 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 ca 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ă intercepteze ș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:

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