Så här konfigurerar du Windows för att arbeta med PowerShell-skript lättare

Windows och PowerShell har inbyggda säkerhetsfunktioner och standardkonfigurationer som syftar till att förhindra att slutanvändare av misstag startar skript under sin dagliga verksamhet. Men om dina dagliga aktiviteter rutinmässigt innebär att du skriver och kör dina egna PowerShell-skript, kan detta vara mer av en olägenhet än en fördel. Här visar vi hur du ska arbeta kring dessa funktioner utan att helt äventyra säkerheten.

Hur och varför Windows & PowerShell förhindrar att man kör exekvering av skript.

PowerShell är effektivt kommandoskalet och skriptspråk som är avsett att ersätta CMD- och batchskript på Windows-system. Som sådant kan ett PowerShell-skript ganska mycket konfigureras för att göra allt du kan göra manuellt från kommandoraden. Det motsvarar att göra praktiskt taget alla ändringar på ditt system, upp till begränsningarna på plats på ditt användarkonto. Så om du bara kan dubbelklicka på ett PowerShell-skript och köra det med fullständiga administratörsbehörigheter, kan en enkel liner så här verkligen försvåra din dag:

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

Kör INTE kommandot ovan!

Det går helt enkelt igenom filsystemet och tar bort vad som helst. Intressant kan detta inte göra systemet oanvändbart så fort du kanske tror - även om det körs från en förhöjd session. Men om någon ringer dig efter att ha kört det här skriptet, för att de plötsligt inte kan hitta sina filer eller köra några program, kommer "antagligen att stänga av den igen" förmodligen bara leda dem till Windows Startup Repair där de kommer att få veta det finns inget som kan göras för att åtgärda problemet. Vad som kan vara värre är att din vän kanske luras i att köra en som hämtar och installerar en keylogger eller fjärråtkomsttjänst istället för att få ett skript som bara sönder deras filsystem. Sedan kan du i stället för att fråga dig frågor om Startup Repair, kanske sluta fråga polisen några frågor om bankbedrägerier!

Hittills bör det vara uppenbart varför vissa saker behövs för att skydda slutanvändare från sig själva, så att säga. Men strömanvändare, systemadministratörer och andra geeks är i allmänhet (även om det finns undantag) lite mer försiktiga med dessa hot, att veta hur man kan upptäcka och enkelt undvika dem, och vill bara fortsätta jobba. För att göra detta måste de antingen avaktivera eller arbeta runt några vägblock:

PowerShell tillåter inte externt manusutförande.
Exekveringspolicy-inställningen i PowerShell förhindrar att externa skript utförs som standard i alla versioner av Windows. I vissa Windows-versioner tillåter standard inte alls att skriptet körs. Vi visade dig hur du ändrar inställningen i Så här tillåter du utförandet av PowerShell-skript i Windows 7, men vi täcker det på några nivåer här också.
PowerShell är inte associerat med .PS1 filtillägg som standard.
Vi tog upp det här först i vår PowerShell Geek School-serie. Windows anger standardåtgärden för .PS1-filer för att öppna dem i Anteckningar, istället för att skicka dem till PowerShell-kommandotolken. Det här är att direkt förhindra oavsiktligt utförande av skadliga skript när de helt enkelt dubbelklickas.
Vissa PowerShell-skript fungerar inte utan administratörsbehörigheter.
Även med ett administratörsnivåkonto behöver du fortfarande komma igenom användarkontokontroll (UAC) för att utföra vissa åtgärder. För kommandoradsverktyg kan detta vara lite omständligt att säga minst. Vi vill inte inaktivera UAC, men det är fortfarande trevligt när vi kan göra det lite lättare att hantera.

Samma problem uppkommer i hur man använder en batchfil för att göra PowerShell-skript enklare att köra, där vi går igenom dig genom att skriva en batchfil för att tillfälligt komma runt dem. Nu ska vi visa dig hur du ställer in ditt system med en mer långsiktig lösning. Tänk på att du inte i allmänhet ska göra dessa förändringar på system som inte uteslutande används av dig - annars ställer du andra användare på högre risk att lösa samma problem som dessa funktioner är avsedda att förhindra.

Ändrar .PS1 filförening.

Den första och kanske mest irriterande att komma runt är standardföreningen för .PS1-filer. Att associera dessa filer till något annat än PowerShell.exe är meningsfullt för att förhindra oavsiktligt utförande av oönskade skript. Men med tanke på att PowerShell kommer med en integrerad skriptmiljö (ISE) som är speciellt utformad för att redigera PowerShell-skript, varför skulle vi vilja öppna .PS1-filer i Anteckningsblock som standard? Även om du inte är redo att helt växla till aktivering av dubbelklick-till-kör-funktionalitet, vill du noga tweak dessa inställningar.

Du kan ändra .PS1-filföreningen till det program du vill ha med kontrollpanelen Standardprogram, men gräver direkt i registret ger dig lite mer kontroll över exakt hur filerna ska öppnas. Detta låter dig också ställa in eller ändra ytterligare alternativ som finns tillgängliga i snabbmenyn för .PS1-filer. Glöm inte att göra en säkerhetskopia av registret innan du gör det här!

Registreringsinställningarna som styr hur PowerShell-skript öppnas lagras på följande plats:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

För att utforska dessa inställningar innan vi ändrar dem, ta en titt på den nyckeln och dess undernycklar med Regedit. Shell-tangenten ska bara ha ett värde, "(Standard)", som är inställt på "Öppna". Det här är en pekare på standardåtgärden för att dubbelklicka på filen, vilket vi ser i undernycklarna.

Expandera Shell-tangenten, och du får se tre undernycklar. Var och en av dessa representerar en åtgärd som du kan utföra som är specifik för PowerShell-skript.

Du kan expandera varje nyckel för att utforska värdena inom, men de motsvarar i grunden följande standardvärden:

0 - Kör med PowerShell. "Kör med PowerShell" är egentligen namnet på ett alternativ redan i snabbmenyn för PowerShell-skript. Texten dras bara från en annan plats istället för att använda nyckelnamnet som de andra. Och det är fortfarande inte standard dubbelklick-åtgärd.
Redigera - Öppna i PowerShell ISE. Det här är mycket mer meningsfullt än Anteckningar, men du måste fortfarande högerklicka på .PS1-filen för att göra det som standard.
Öppna - Öppna i Anteckningsblock. Observera att detta nyckelnamn också är strängen som lagras i "(Standard)" -värdet på Shell-tangenten. Det betyder att dubbelklicka på filen kommer att "Öppna" den, och den här åtgärden är normalt inställd att använda Anteckningsblock.

Om du vill hålla fast vid de befintliga kommandoradserna som redan finns tillgängliga, kan du bara ändra värdet "(Standard)" i Shell-tangenten för att matcha namnet på den nyckel som matchar det du vill ha ett dubbelklick för att göra. Detta kan enkelt göras inom Regedit, eller du kan använda lärdomar från vår handledning om att utforska registret med PowerShell (plus en liten PSDrive-tweak) för att börja bygga ett återanvändbart manus som kan konfigurera dina system för dig. Nedanstående kommandon måste köras från en förhöjd PowerShell-session, som liknar kör CMD som administratör.

Först vill du konfigurera en PSDrive för HKEY_CLASSES_ROOT eftersom det inte är standard som standard. Kommandot för detta är:

Ny PSDrive HKCR-registret HKEY_CLASSES_ROOT

Nu kan du navigera och redigera registernycklar och värden i HKEY_CLASSES_ROOT precis som du skulle i de vanliga HKCU- och HKLM PSDrivesna.

Så här konfigurerar du dubbelklickning för att starta PowerShell-skript direkt:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(Standard)' 0

Så här konfigurerar du dubbelklickning för att öppna PowerShell-skript i PowerShell ISE:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell "(Standard)" Redigera "

För att återställa standardvärdet (uppsättningar dubbelklickar för att öppna PowerShell-skript i anteckningsblock):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell "(Standard)" Öppna "

Det är bara grunderna för att ändra standard dubbelklick-åtgärd. Vi kommer att gå in på mer detaljer om hur man anpassar hur PowerShell-skript hanteras när de öppnas i PowerShell från Explorer i nästa avsnitt. Tänk på att scoping hindrar PSDrives från att bestå över sessioner. Så du kommer noga att inkludera New-PSDrive-raden i början av ett konfigurationsskript du bygger för detta ändamål, eller lägga till det i din PowerShell-profil. Annars måste du köra den biten manuellt innan du försöker göra ändringar på det här sättet.

Ändra inställningen för PowerShell ExecutionPolicy.

PowerShells ExecutionPolicy är ett annat skyddslag mot utövande av skadliga skript. Det finns flera alternativ för detta, och ett par olika sätt kan det ställas in. Från de flesta till minst säkra är de tillgängliga alternativen:

Begränsad - Inga skript får köras. (Standardinställningen för de flesta system.) Detta kommer till och med att förhindra att ditt profilskript körs.
AllSigned - Alla skript måste signeras digitalt av en betrodd utgivare att köra utan att fråga användaren. Skript som är signerade av utgivare som uttryckligen definierats som otillförlitliga eller skript som inte digitalt signeras alls, kommer inte att köras. PowerShell kommer att uppmana användaren att bekräfta om ett skript är undertecknat av en utgivare som ännu inte definierats som betrodd eller otillförlitlig. Om du inte digitalt har skrivit ditt profilskript och etablerat förtroende för den signaturen, kommer det inte att kunna köras. Var försiktig med vilka utgivare du litar på, eftersom du fortfarande kan sluta köra skadliga skript om du litar på den felaktiga.
RemoteSigned - För skript som laddas ned från Internet, är detta effektivt detsamma som "AllSigned". Skript som skapas lokalt eller importeras från andra källor än Internet får dock köra utan någon bekräftelsespåskrift. Här måste du också vara försiktig med vilka digitala signaturer du litar på men även vara mer försiktig med de icke-signerade skript som du väljer att köra. Det här är den högsta säkerhetsnivån där du kan ha ett fungerande profilskript utan att behöva signera det digitalt.
Obegränsad - Alla skript får köras, men en bekräftelsespolicy krävs för skript från Internet. Från den här tiden är det helt upp till dig att undvika att köra otillförlitliga skript.
Bypass - Allt går utan varning. Var försiktig med den här.
Odefinierad - Ingen politik definieras i nuvarande omfattning. Detta används för att tillåta återgång till policyer definierade i lägre omfång (mer detaljer nedan) eller till standardinställningarna för OS.

Såsom föreslagits av beskrivningen av Odefinierad kan ovanstående policyer ställas in i ett eller flera av flera områden. Du kan använda Get-ExecutionPolicy, med -List-parametern, för att se alla scopes och deras nuvarande konfiguration.

Områdena är listade i prioritetsordning, med det översta definierade räckviddet som överstiger alla andra. Om ingen policy definieras, faller systemet tillbaka till standardinställningen (i de flesta fall är detta begränsat).

MachinePolicy representerar en koncernpolicy som är i kraft på datornivå. Detta tillämpas generellt endast i en domän, men kan också göras lokalt.
UserPolicy representerar en grupppolicy som har effekt på användaren. Detta används också bara i företagsmiljöer.
Processen är en omfattning som är specifik för denna instans av PowerShell. Ändringar av politiken inom detta räckvidd påverkar inte andra körbara PowerShell-processer, och kommer att vara ineffektiva efter det att denna session avslutats. Detta kan konfigureras av parametern -ExecutionPolicy när PowerShell lanseras, eller det kan ställas in med den korrekta Set-ExecutionPolicy-syntaxen från sessionen.
CurrentUser är ett räckvidd som är konfigurerat i det lokala registret och gäller för användarkontot som användes för att starta PowerShell. Detta räckvidd kan ändras med Set-ExecutionPolicy.
LocalMachine är en räckvidd som är konfigurerad i det lokala registret och tillämpas för alla användare på systemet. Detta är standardomfattningen som ändras om Set-ExecutionPolicy körs utan -Scope-parametern. Eftersom det gäller alla användare på systemet, kan det bara ändras från en förhöjd session.

Eftersom den här artikeln huvudsakligen handlar om att komma runt säkerheten för att underlätta användbarheten, är vi bara oroade över de tre nedre delarna. Inställningarna MachinePolicy och UserPolicy är bara användbara om du vill genomdriva en restriktiv policy som inte är så enkelt förbikopplad. Genom att hålla våra ändringar till Processnivå eller nedan kan vi när som helst enkelt använda vilken policyinställning som vi anser lämpliga för en given situation.

För att behålla viss balans mellan säkerhet och användbarhet är den policy som visas på skärmbilden troligen bäst. Att ställa in LocalMachine-policyen till Begränsad hindrar i allmänhet löpande skript av någon annan än dig. Naturligtvis kan detta kringgås av användare som vet vad de gör utan mycket ansträngning. Men det borde hålla alla icke-tekniskt kunniga användare från misstag utlösa något katastrofalt i PowerShell. Om du har CurrentUser (dvs .: du) som Obegränsad kan du manuellt exekvera skript från kommandoraden, men du behåller en påminnelse om försiktighet för skript som laddas ned från Internet. Inställningen RemoteSigned på Processnivå skulle behöva göras i en genväg till PowerShell.exe eller (som vi gör nedan) i registret värden som styr uppförandet av PowerShell-skript. Detta möjliggör enkel dubbelklick-till-körfunktionalitet för alla skript du skriver medan du lägger upp ett starkare hinder mot oavsiktligt utförande av (potentiellt skadliga) skript från externa källor. Vi vill göra det här här eftersom det är mycket lättare att dubbelklicka på ett skript än vad det generellt är att ringa det manuellt från en interaktiv session.

För att ställa in CurrentUser och LocalMachine-policyn som i skärmbilden ovan, kör följande kommandon från en förhöjd PowerShell-session:

Set-ExecutionPolicy Begränsad Set-ExecutionPolicy Obegränsat -Scope CurrentUser

För att tillämpa RemoteSigned-policyen på skript körs från Explorer måste vi ändra ett värde inuti en av de registernycklar vi tittade på tidigare. Detta är särskilt viktigt eftersom standardkonfigurationen beroende på din PowerShell- eller Windows-version kan vara att omgå alla ExecutionPolicy-inställningar utom AllSigned. För att se vad den nuvarande konfigurationen är för din dator kan du köra det här kommandot (se till att HKCR PSDrive är mappad först):

Get-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command | Välj-Objekt "(Standard)"

Din standardkonfiguration kommer antagligen att vara en av följande två strängar, eller något som är ganska lika:

(Se på Windows 7 SP1 x64, med PowerShell 2.0)

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

(Se på Windows 8.1 x64, med PowerShell 4.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "om ((Get-ExecutionPolicy) -En AllSigned ') Set-ExecutionPolicy -Scope Process Bypass; &'% 1 '"

Den första är inte så illa, eftersom allt det gör är att utföra manuset under befintliga ExecutionPolicy-inställningar. Det kan göras bättre genom att tillämpa strängare restriktioner för en mer olyckshändig åtgärd, men det var inte ursprungligen tänkt att utlösas med ett dubbelklick ändå, och standardpolicyen är vanligtvis begränsad. Det andra alternativet är dock en full förbikoppling av vad ExecutionPolicy du sannolikt kommer att ha på plats - även begränsad. Eftersom bypassen kommer att tillämpas i processomfånget påverkar det bara de sessioner som startas när skript körs från Explorer. Detta innebär dock att du kan sluta starta skript som du annars skulle kunna förvänta dig (och vill) att din policy förbjuder.

För att ställa in Processnivån ExecutionPolicy för skript som startats från Explorer, i linje med skärmdumpen ovan, måste du ändra samma registervärde som vi just frågat. Du kan göra det manuellt i Regedit, genom att ändra det till det här:

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

Du kan också ändra inställningen från PowerShell om du föredrar det. Kom ihåg att göra detta från en förhöjd session, med HKCR PSDrive mappad.

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

Kör PowerShell-skript som administratör.

Precis som det är en dålig idé att helt och hållet stänga av UAC, är det också dåligt säkerhetspraxis att köra skript eller program med förhöjda behörigheter om du inte behöver dem att utföra operationer som kräver administratörsåtkomst. Så det är inte rekommenderat att bygga UAC-snabbmeddelandet till standardåtgärden för PowerShell-skript. Vi kan dock lägga till ett nytt snabbmenyalternativ så att vi enkelt kan köra skript i förhöjda sessioner när vi behöver. Det här liknar den metod som används för att lägga till "Öppna med anteckningsblock" i snabbmenyn för alla filer - men här kommer vi bara att rikta in sig på PowerShell-skript. Vi ska också bära över några tekniker som användes i föregående artikel där vi använde en batchfil istället för registerhackar för att starta vårt PowerShell-skript.

För att göra detta i Regedit, gå tillbaka till Shell-tangenten på:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Där skapar du en ny undernyckel. Kalla det "Kör med PowerShell (Admin)". Under det, skapa en annan undernyckel som heter "Command". Ange sedan "(Standard)" -värdet under Kommando till det här:

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

Att göra detsamma i PowerShell behöver faktiskt tre rader den här gången. En för varje ny nyckel och en för att ställa in "(Standard)" -värdet för Command. Glöm inte höjden och HKCR-kartläggningen.

Nytt objekt "HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Kör med PowerShell (Admin)" Nytt objekt "HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Kör med PowerShell (Admin) \ Kommando" Set-ItemProperty " HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Kör med PowerShell (Admin) \ Command "(Standard)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" &  Start-Process PowerShell.exe -ArgumentList "-ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Verb RunAs ""

Observera också skillnaderna mellan strängen som sätts in via PowerShell och det verkliga värdet som går in i registret. I synnerhet måste vi sammanfoga hela saken i enkla citat och dubbla upp de interna citaten, för att undvika fel i kommandotolkning.

Nu ska du ha en ny kontextmenyuppgift för PowerShell-skript, kallad "Run with PowerShell (Admin)".

Det nya alternativet kommer att hälla två på varandra följande PowerShell-instanser. Den första är bara en launcher för den andra, som använder Start-Process med parametern "Verb RunAs "för att begära höjning för den nya sessionen. Därifrån ska ditt skript kunna köra med administratörsbehörigheter efter att du klickat på UAC-prompten.

Finputsning.

Det finns bara några få tweaks till detta som kan hjälpa till att göra livet lite enklare än. För en, hur är det att bli av med Notepad-funktionen helt? Kopiera bara "(Standard)" -värdet från kommandotangenten under Redigera (nedan), till samma plats under Öppna.

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

Eller du kan använda den här delen av PowerShell (med Admin & HKCR förstås):

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

En enda mindre irritation är konsolen vana att försvinnas när ett manus är färdigt. När det händer har vi ingen chans att granska skriptutmatningen för fel eller annan användbar information. Detta kan tas om hand genom att en paus i slutet av varje av dina skript förstås. Alternativt kan vi ändra "(Standard)" -värdena för våra kommandotangenter för att inkludera parametern "-NoExit". Nedan finns de modifierade värdena.

(Utan administratörsbehörighet)

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

(Med administratörsbehörighet)

\ N "" \ "\ Verb RunAs "

Och givetvis kommer vi att ge dig dem i PowerShell-kommandon också. Senast påminnelse: Elevation & HKCR!

(Icke-Admin)

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command "(Standard)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-NoExit" "-ExecutionPolicy" "RemoteSigned" " -filen ""% 1 ""

(Administration)

Set-ItemProperty 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Kör med PowerShell (Admin) \ Command "(Standard)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" Och Start-Process PowerShell.exe -ArgumentList "-NoExit -ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Verb RunAs ""

Tar det för en snurrning.

För att testa detta ska vi använda ett skript som kan visa oss Execution Policy-inställningarna på plats och om skriptet lanserades med administratörsbehörigheter eller ej. Skriptet kommer att kallas "MyScript.ps1" och lagras i "D: \ Script Lab" på vårt provsystem. Koden är nedan, för referens.

om (([Säkerhet.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()). IsInRole ([Security.Principal.WindowsBuiltInRole] "Administratör")) Skrivutskrift 'Kör som administratör!' else Write-Output 'Running Limited!' Get-ExecutionPolicy -List

Med funktionen "Kör med PowerShell":

Genom att använda "Kör med PowerShell (Admin)" -åtgärden, efter att ha klickat igenom UAC:

För att visa ExecutionPolicy i åtgärd vid Processens omfattning kan vi få Windows att tänka på att filen kom från Internet med den här PowerShell-koden:

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

Lyckligtvis hade vi -NoExit aktiverat. Annars skulle det felet ha blinkat på, och vi skulle inte ha vetat!

Zone.Identifier kan tas bort med följande:

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

Användbara referenser:

Running PowerShell-skript från en batchfil - Daniel Schroeders Programmeringsblogg
Kontrollera efter administratörsbehörigheter i PowerShell - Hej, Scripting Guy! blogg