Kako odpraviti napako Execution Policy Restricted v sistemu Windows PowerShell

Najvarnejši način za odpravo napake “Execution Policy Restricted” v sistemu Windows PowerShell ni kopiranje najširšega možnega ukaza, ki ga najdete. Najprej ugotovite, katera izvajalna politika je dejansko veljavna, nato izberite najožjo spremembo, ki ustreza temu, kar želite zagnati.

Trenutna Microsoftova dokumentacija poudarja tudi pomen konteksta različice. Dokumentacija za Windows PowerShell 5.1 navaja Restricted kot privzeto izvajalno politiko za računalnike s sistemom Windows. Trenutna dokumentacija za PowerShell 7.6 definira Default kot RemoteSigned v sistemu Windows. Če so vsi obsegi nedefinirani (Undefined), Microsoft še vedno navaja dejanski rezervni način na odjemalcih Windows kot Restricted. Praktična lekcija je preprosta: ne sklepajte o svoji politiki na podlagi različice sistema Windows ali navodila. Ukaze za politiko zaženite na računalniku, na katerem se pojavlja napaka.

Ta vodnik primerja glavne popravke glede na obseg, trajnost, vpliv na skrbništvo in model zaupanja. Cilj je zagnati legitimni skript, ne da bi oslabili varnost sistema bolj, kot je potrebno.

Kaj napaka Restricted dejansko pomeni

Pri politiki Restricted PowerShell dovoljuje posamezne ukaze, vendar ne dovoljuje zagona datotek skriptov. To vključuje skripte PowerShell in povezane konfiguracijske ali skriptne datoteke modulov. Microsoft opisuje izvajalno politiko kot varnostno funkcijo, ki nadzoruje pogoje, pod katerimi se nalagajo skripti in konfiguracijske datoteke. To ni varnostna meja; Microsoft izrecno navaja, da uporabnik še vedno lahko vnaša ukaze interaktivno. Preberite trenutno dokumentacijo about_Execution_Policies za PowerShell 7.6 in dokumentacijo o izvajalni politiki za Windows PowerShell 5.1.

Pogosta napaka navaja, da datoteke .ps1 ni mogoče naložiti, ker je izvajanje skriptov onemogočeno; pred spremembo politike zabeležite natančno sporočilo.

Ta razlika je pomembna. Izvajalna politika lahko pomaga preprečiti naključno izvajanje skriptov, vendar nastavitev RemoteSigned ali Bypass ne naredi skripta zaupanja vrednega. Najprej preglejte skript in njegov vir.

Korak 1: določite veljavno politiko in vse obsege

Zaženite ta dva ukaza:

Get-ExecutionPolicy

Get-ExecutionPolicy -List

Prvi vrne veljavno politiko za trenutno sejo. Drugi našteje politike, uporabljene na ravneh MachinePolicy, UserPolicy, Process, CurrentUser in LocalMachine. Microsoft priporoča Get-ExecutionPolicy -List posebej za pregled politik, ki lahko vplivajo na sejo. Glejte Get-ExecutionPolicy.

Preverite vse obsege, namesto da predpostavljate, da je vrednost LocalMachine tista, ki nadzoruje sejo.

Če sta MachinePolicy ali UserPolicy definirana, ustavite, preden poskušate vsiliti lokalno zaobid. Te vrednosti izvirajo iz skupinske politike (Group Policy) in lahko preglasijo nastavitve izvajalne politike, opravljene s PowerShellom. Na upravljanem delovnem računalniku je naslednji pravilen korak običajno slediti postopku organizacije ali kontaktirati IT oddelek.

Izberite popravek glede na potrebo, ne glede na najkrajši ukaz

Korak 2: uporabite skrbniške pravice samo za spremembo na ravni celotnega računalnika

Ne morate odpreti povišanega PowerShell-a samo za spremembo obsega CurrentUser ali Process. Microsoft navaja, da je povišanje pravic potrebno pri spreminjanju politike za lokalni računalnik, kar pomeni LocalMachine. To je koristen kompromis: če samo vaš uporabniški račun potrebuje lokalno skriptiranje, spreminjanje politike za vse uporabnike dodaja obseg brez dodane koristi.

Zagon kot skrbnik je primeren za namerno spremembo LocalMachine, vendar je nepotreben za obseg Process ali CurrentUser.

Priporočilo glede na potrebo: uporabite CurrentUser za razvojni račun, ki redno zaganja lokalno ustvarjene skripte. LocalMachine rezervirajte za skrbnika, ki namerno želi, da ista nastavitev vpliva na vse uporabnike.

Korak 3: za redno lokalno skriptiranje razmislite o CurrentUser RemoteSigned

Za mnoge osebne razvojne računalnike je praktična trajna izbira:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

RemoteSigned omogoča zagon lokalnih skriptov brez zahteve po podpisu, medtem ko skripti, označeni kot preneseni z interneta, zahtevajo zaupanja vreden digitalni podpis, razen če datoteko izrecno odklenete. To ohranja uporabno razliko med kodo, ki ste jo ustvarili lokalno, in kodo, pridobljeno iz drugega vira.

Ta ilustracija prikazuje ukaz RemoteSigned za celoten računalnik, ker je obseg izpuščen; LocalMachine je privzeti obseg. Raje uporabite izrecen obseg, da je vpliv nameren.

Pogosta napaka je zagon Set-ExecutionPolicy RemoteSigned brez -Scope. Microsoft dokumentira LocalMachine kot privzeti obseg pri nastavljanju izvajalne politike. Zato je bolje biti izrecen:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Sprememba je veljavna takoj; PowerShell ni treba znova zagnati za spremembe CurrentUser ali LocalMachine.

Korak 4: za začasno sejo raje uporabite politiko na obsegu Process

Če odpravljate napake ali enkrat zaženete zaupanja vreden lokalni skript, se izognite trajni spremembi uporabnika ali računalnika. Ožja možnost je:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

Obseg Process velja samo za trenutno sejo PowerShell. Microsoft navaja, da je shranjen v spremenljivki okolja $Env:PSExecutionPolicyPreference in je izbrisan, ko se proces zapre.

Če ima večja aplikacija, namestitveni program ali nadzorovano okolje avtomatizacije že svoj varnostni model, PowerShell zagotavlja tudi Bypass:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Bypass na obsegu Process izgine, ko se proces PowerShell zapre, vendar odstrani tudi opozorila in blokiranje izvajalne politike za to sejo.

Kompromis: obseg Process minimizira trajnost, vendar je Bypass širši od RemoteSigned znotraj te seje. Microsoft opisuje Bypass kot tak, ki ničesar ne blokira in ne prikazuje opozoril ali pozivov, ter navaja, da je namenjen scenarijem, kjer drugo aplikacija zagotavlja varnostni model. Za normalno interaktivno sejo odpravljanja napak najprej uporabite Process RemoteSigned, razen če imate specifičen razlog za Bypass.

Za ločen enkraten proces Windows PowerShell lahko zaženete tudi:

powershell.exe -ExecutionPolicy RemoteSigned -File .\script.ps1

Za PowerShell 7 je izvršljiva datoteka pwsh.exe. Nastavitev izvajalne politike v ukazni vrstici še vedno ne preglasi izvajalne politike, ki jo uveljavlja skupinska politika.

Korak 5: če RemoteSigned blokira prenesen skript, odklenite samo to datoteko

RemoteSigned obravnava datoteke, označene kot izvorne iz interneta, drugače. Microsoft dokumentira cmdlet Unblock-File kot tistega, ki odstrani to oznako internetne cone, kar omogoča zagon pregledanega nepodpisanega skripta pod pravilom RemoteSigned.

Najprej pregledajte skript. Če zaupate viru in ste vsebino pregledali, zaženite:

Unblock-File -Path .\script.ps1

Lahko uporabite tudi potrditveno polje Unblock v pogovornem oknu Lastnosti datoteke. Microsoft navaja, da Unblock-File opravi isto osnovno operacijo. Glejte Unblock-File.

Odklepanje enega pregledanega prenesenega skripta je ožje kot oslabitev politike za vse skripte na računalniku.

Preverite lahko, ali ima datoteka alternativni tok podatkov Zone.Identifier z:

Get-Item .\script.ps1 -Stream Zone.Identifier -ErrorAction SilentlyContinue

Microsoft opozarja, da metode prenosa ne označujejo vseh datotek enako, zato odsotnost tega toka ni dokaz, da je skript varen.

Korak 6: uporabite AllSigned, ko ima organizacija postopek podpisovanja

AllSigned zahteva, da so vsi skripti in konfiguracijske datoteke podpisane s strani zaupanja vrednega izdajatelja, vključno s skripti, ustvarjenimi lokalno. To organizaciji zagotavlja dosleden postopek zaupanja izdajatelju, vendar ustvari tudi operativno preobremenjenost: skripti potrebujejo podpise Authenticode in uporabniki morajo zaupati relevantnim izdajateljem.

Microsoftova dokumentacija about_Signing pojasnjuje, kako PowerShell preverja podpise skriptov in kako delujejo pozivi za zaupanja vredne izdajatelje.

Priporočilo glede na potrebo: AllSigned ima smisel, ko vaša organizacija že ima certifikate za podpisovanje kode, nadzor nad objavljanjem in postopek za posodabljanje podpisanih skriptov. Za posameznega razvijalca, ki piše lokalne pripomočke, RemoteSigned običajno vključuje manj trenja, hkrati pa ohranja preverjanje izvora iz interneta.

Korak 7: ne borite se proti skupinski politiki na upravljanem PC

PowerShell izpostavlja dva obsega politike, ki izvirata iz skupinske politike: MachinePolicy in UserPolicy. Microsoftova dokumentacija o skupinski politiki navaja, da nastavitev Turn on Script Execution lahko uveljavlja obnašanje Restricted, RemoteSigned ali AllSigned za upravljane uporabnike in računalnike. Nastavitev je pod:

Administrative Templates\Windows Components\Windows PowerShell

Glejte about_Group_Policy_Settings.

Če Get-ExecutionPolicy -List pokaže definirano MachinePolicy ali UserPolicy, lokalni ukaz Set-ExecutionPolicy morda ne bo dal pričakovanega dejanskega obnašanja. Praktična rešitev je, da zahtevate ustrezno politiko od skrbnika, uporabite podpisani skript, če je zahtevano, ali uporabite odobreno metodo namestitve.

Korak 8: obnovite nastavitev, ki ste jo dejansko spremenili, nato preverite

Pred spremembo trajnega obsega zabeležite njegovo obstoječo vrednost:

Get-ExecutionPolicy -Scope CurrentUser

Get-ExecutionPolicy -Scope LocalMachine

Če morate kasneje odstraniti vrednost politike, ki ste jo nastavili, Microsoft dokumentira nastavitev tega obsega na Undefined:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Undefined

Ne zaženite slepo Set-ExecutionPolicy Restricted samo zato, ker to prikazuje posnetek zaslona. Brez obsega ukaz cilja na LocalMachine po privzetem, in “Restricted” morda ni bila prejšnja vrednost tega obsega.

Posnetek zaslona ilustrira spremembo na Restricted, vendar bi pravi povratni korak moral obnoviti obseg in vrednost, ki ste jo zabeležili, namesto da ugibate prejšnjo konfiguracijo.

Na koncu preverite tako veljavno politiko kot skript:

Get-ExecutionPolicy

Get-ExecutionPolicy -List

.\script.ps1

Uspešen zagon skripta potrdi, da je takojšnji simptom odpravljen; ponovno preverite seznam politik, da potrdite, da niste nenamerno pustili širšega obsega spremenjenega.

Kateri popravek izbrati?

Pogoste napake, ki ustvarijo večji problem kot prvotna napaka

• Nastavitev Unrestricted ali Bypass trajno samo za zagon enega skripta. To razširi tisto, kar se lahko izvaja, ko bi ožja sprememba na ravni Process, CurrentUser ali specifična za datoteko lahko rešila težavo.
• Zagon vseh ukazov kot Administrator. Spremembe CurrentUser in Process ne potrebujejo spremembe politike LocalMachine.
• Ignoriranje skupinske politike. Če je naprava upravljana, je politika lahko namerna in lokalna sprememba drugega obsega ne nadomesti organizacijskega nadzora.
• Odklepanje skripta brez branja. Unblock-File odstrani blokado izvora iz interneta; ne validira kode.
• Predpostavka, da je podpisani skript samodejno neškodljiv. Microsoft opozarja, da je lahko podpisana koda še vedno zlonamerna; podpisi vzpostavijo informacije o izdajatelju in celovitosti, ne pa garancije za varno obnašanje.
• Pozabitev, kateri obseg ste spremenili. Ukaz brez -Scope lahko vpliva na LocalMachine, medtem ko sprememba Process izgine ob izhodu.

Zaključek

Za večino osebnega skriptiranja v sistemu Windows je CurrentUser RemoteSigned razumna trajna izbira, ko redno zaganjate lokalno ustvarjene skripte, medtem ko je Unblock-File ožja izbira za en pregledan skript, prenesen z interneta. Za začasno sejo odpravljanja napak Process RemoteSigned minimizira trajnost. Bypass ima legitimno vlogo pri nadzorovani avtomatizaciji, vendar je njegov kompromis, da so blokiranje izvajalne politike in opozorila za ta proces odstranjeni. Na upravljanih računalnikih je treba skupinsko politiko obravnavati kot avtoriteto, ne kot oviro, ki jo je treba zaobiti.

Najboljši popravek torej ni ena politika za vse. Je najmanjši obseg in najmanj dovoljeno obnašanje, ki še vedno podpira zaupanja vreden skript, ki ga morate zagnati.