Heb je ooit een PowerShell-script gedownload, het uitgevoerd en de beruchte foutmelding hieronder tegengekomen? Zo ja, dan heb je de cmdlet Set-ExecutionPolicy en deze tutorial nodig!
In deze post ga je leren over PowerShell-uitvoeringsbeleid en hoe je ze beheert met de cmdlet Set-ExecutionPolicy. Tegen het einde van deze post weet je niet alleen hoe je scripts moet uitvoeren, maar ook hoe je uitvoeringsbeleid moet gebruiken!
Deze tutorial is geschreven met Windows PowerShell in gedachten, en alle demonstraties zijn uitgevoerd met Windows PowerShell. Uitvoeringsbeleid is niet uniek voor Windows PowerShell, en ze werken zeer vergelijkbaar in PowerShell 6+. Maar als je met PowerShell 6+ werkt, kun je kleine verschillen in gedrag vinden.
Wat is een uitvoeringsbeleid?
Als je ooit de hierboven beschreven fout bent tegengekomen, heb je te maken gehad met een uitvoeringsbeleid. PowerShell-uitvoeringsbeleid is een beveiligingsmechanisme om je systeem te beschermen tegen het uitvoeren van schadelijke scripts. Uitvoeringsbeleid voorkomt niet dat je PowerShell-code in de console kunt uitvoeren als een shell maar script-uitvoering.
Microsoft zegt dat een uitvoeringsbeleid technisch gezien geen “beveiligings”maatregel is maar meer een poort die je kunt openen en sluiten. Uiteindelijk kun je een gedefinieerd uitvoeringsbeleid gemakkelijk omzeilen, zoals je later zult leren.
Uitvoeringsbeleid is gebaseerd op vertrouwen. Als je een script vertrouwt, is de kans groot dat het niet schadelijk is. Uitvoeringsbeleid voorkomt doorgaans niet de uitvoering van alle scripts. Hun primaire doel (vooral wanneer strikter geconfigureerd) is ervoor te zorgen dat je ervan overtuigd bent dat het script dat je uitvoert, cryptografisch is ondertekend met een certificaat.
Uitvoeringsbeleidsbereiken
Zoals je hebt geleerd, beperken uitvoeringsbeleidsregels de uitvoering van scripts, maar PowerShell kan scripts uitvoeren in veel verschillende contexten. PowerShell voert scripts uit onder de ingelogde gebruikerscontext of de wereldwijde machinale context, via geplande taken die worden uitgevoerd als SYSTEM of binnen het bereik van een enkele geopende PowerShell-console.
Om al deze contexten tegemoet te komen, heeft PowerShell vijf verschillende contexten of bereiken waarin je een uitvoeringsbeleid kunt definiëren.
- MachinePolicy – Dit bereik is beperkt tot een enkele computer. Het beïnvloedt alle gebruikers die zich aanmelden op die computer, en het wordt ingesteld door een Active Directory-groepsbeleidsobject. Wanneer gedefinieerd, heeft het voorrang op alle andere bereiken.
- LocalMachine. Dit is de standaardscope die alle computergebruikers beïnvloedt en wordt opgeslagen in de register subkey HKEY_LOCAL_MACHINE. Wanneer u een uitvoeringsbeleid instelt met
Set-ExecutionPolicy, is deze scope standaard.
Het uitvoeringsbeleid voor LocalMachine wordt opgeslagen in de register sleutel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.
- UserPolicy – De UserPolicy-scope heeft alleen invloed op een enkele gebruiker op een computer, en wordt ingesteld door een Active Directory-groepsbeleidsobject. U kunt dit beleid niet wijzigen met
Set-ExecutionPolicy. - CurrentUser. De CurrentUser-beleidsscope stelt het uitvoeringsbeleid alleen in voor de huidige gebruiker en wordt opgeslagen onder de registerhive HKEY_CURRENT_USER. U kunt dit beleid niet wijzigen met
Set-ExecutionPolicy.
Het uitvoeringsbeleid voor CurrentUser wordt opgeslagen in de register sleutel HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.
- Process – Deze scope definieert het uitvoeringsbeleid voor een enkele PowerShell-sessie voor een enkele gebruiker. De Process-uitvoeringsbeleidsscope is het meest gedetailleerde uitvoeringsbeleid dat u kunt definiëren. In tegenstelling tot andere uitvoeringsbeleidsregels wordt dit beleid opgeslagen in een omgevingsvariabele genaamd
PSExecutionPolicyPreferencein plaats van in het register.
Soorten Uitvoeringsbeleid
Uitvoeringsbeleid heeft verschillende “beveiligingsniveaus”. Deze niveaus bepalen hoe strikt het uitvoeringsbeleid is. Bijvoorbeeld, je kunt een uitvoeringsbeleid hebben dat in feite niets doet; het is uitgeschakeld, maar aan de andere kant kan een uitvoeringsbeleid de uitvoering van scripts volledig uitschakelen.
Laten we elk van de manieren bekijken waarop je het beveiligingsniveau van een uitvoeringsbeleid kunt configureren, van minst restrictief tot meest restrictief.
Onbeperkt
Het minst restrictieve beleid is er een dat helemaal geen invloed heeft; het is Onbeperkt. Onbeperkte uitvoeringsbeleiden zijn in feite uitgeschakeld. Gebruikers kunnen alle scripts uitvoeren, ongeacht het vertrouwen wanneer een uitvoeringsbeleid Onbeperkt is.
Passeren
Net als het Onbeperkt type, blokkeert een uitvoeringsbeleid dat is ingesteld op Passeren, niets.
Hoewel Passeren en Onbeperkt een vergelijkbaar effect hebben, is het type uitvoeringsbeleid Passeren technisch gezien geen type. Het slaat een gedefinieerd uitvoeringsbeleid volledig over.
Niet gedefinieerd
Hoewel niet veel gebruikt, kun je in feite een uitvoeringsbeleid verwijderen door het in te stellen op Niet gedefinieerd. Wanneer je een uitvoeringsbeleid instelt op Niet gedefinieerd, verwijdert PowerShell volledig alle toegewezen uitvoeringsbeleiden van de toegewezen scope.
Op niet-Windows computers is het uitvoeringsbeleid altijd ingesteld op Onbeperkt en kan niet worden gewijzigd.
Wanneer alle scopes zijn ingesteld op Niet gedefinieerd, behandelt PowerShell in feite alle scopes als Beperkt.
RemoteSigned
Zoals je eerder hebt gelezen, gaan uitvoeringsbeleidsregels allemaal over vertrouwen dat wordt verdiend via een digitale handtekening op scripts. PowerShell houdt ook rekening met de herkomst van dat script. Is het gemaakt op je lokale computer of door een willekeurig persoon op internet?
Scripts die ergens anders zijn gemaakt dan op je lokale computer, moeten niet inherent vertrouwd worden. Daarom biedt PowerShell het RemoteSigned uitvoeringsbeleid. Het RemoteSigned uitvoeringsbeleid dwingt af dat alle scripts die ergens anders dan op je lokale computer zijn geschreven, cryptografisch ondertekend moeten zijn.
Je kunt dit uitvoeringsbeleid enigszins overschrijven voor bestanden die van internet zijn gedownload met behulp van het
Unblock-Filecmdlet. Krijg later meer informatie over dit gedrag in de sectie Hoe het RemoteSigned-beleid werkt.
Voor Windows Server is RemoteSigned toegewezen als het standaardbeleid.
AllSigned
Als je ervoor wilt zorgen dat alle PowerShell-scripts cryptografisch zijn ondertekend, stel dan het uitvoeringsbeleid in op AllSigned. Net als bij RemoteSigned, gaat dit uitvoeringsbeleid nog een stap verder en dwingt af dat alle scripts zijn ondertekend voordat ze worden uitgevoerd.
Zelfs als je het AllSigned-uitvoeringsbeleid hebt ingesteld, kun je de uitvoeringsbeleidsregel nog steeds omzeilen, zoals je later zult leren.
Restricted
De meest beperkende uitvoeringsbeleid is Beperkt. Wanneer een uitvoeringsbeleid is ingesteld op Beperkt, kunnen absoluut geen scripts worden uitgevoerd, ongeacht of ze vertrouwd zijn of niet. Dit beleid schakelt scriptuitvoering in feite volledig uit.
Bovendien zorgt het Beperkte type ervoor dat PowerShell-opmaak- en configuratiebestanden (PS1XML), module-scriptbestanden (PSM1) en PowerShell-profielen niet kunnen worden uitgevoerd.
Alle Windows-clients zijn standaard ingesteld op een Beperkt uitvoeringsbeleid.
Technisch gezien definieert Microsoft een zevende uitvoeringsbeleid genaamd Standaard, maar het type is in feite een andere aanduiding voor RemoteSigned (Windows Server) en Beperkt (Windows-clients).
Hoe het RemoteSigned-beleid werkt
Een bijzonder scenario om op te merken is hoe het RemoteSigned uitvoeringsbeleid werkt. Dit uitvoeringsbeleid (zoals je hebt geleerd) voorkomt dat scripts worden uitgevoerd die ergens anders dan op je lokale computer zijn gemaakt.
Maar hoe weet PowerShell dat het script elders is gemaakt? Gegevensstromen.
Begrip en bevraging van NTFS-gegevensstromen
Telkens wanneer je een bestand maakt op een NTFS-bestandssysteem, past NTFS een alternatieve gegevensstroom (ADS) attribuut toe op het bestand. Een ADS heeft twee bestandsattributen: $Data en zone.Identifier. PowerShell gebruikt het attribuut zone.Identifier om te identificeren of een PowerShell-scriptbestand elders is gemaakt.
In tegenstelling tot andere attributen zoals Gecomprimeerd of Alleen Lezen, zijn ADS-attributen verborgen in de Bestandsverkenner. Maar door PowerShell te gebruiken, kunt u deze gegevensstromen inspecteren.
Voer het Get-Item cmdlet uit met het pad naar het script en de parameter Stream zoals hieronder weergegeven. In dit voorbeeld is Hello World.ps1 lokaal geschreven. Let op dat het enige attribuut dat aan de Stream-eigenschap is toegewezen, $DATA is. Er is geen ADS-attribuut.
Voer nu dezelfde opdracht uit op een script dat van internet is gedownload. Let op dat Get-Item nu een ander object retourneert met een Stream van Zone.Identifier.
Zodra u weet dat een bestand een ADS heeft, kunt u de Get-Content-opdracht gebruiken om de zone te ontdekken. De zone geeft aan waar het bestand vandaan komt.
Get-Content retourneert een waarde van ZoneId die de zone vertegenwoordigt waar het bestand vandaan komt.
Mogelijke zone-waarden zijn:
Uitvoeringsbeleid Voorrang
Zoals hierboven besproken, bestaan er tegelijkertijd veel verschillende uitvoeringsbeleiden. Al deze uitvoeringsbeleiden bepalen samen de instellingen van uw huidige sessie. Wanneer u meerdere uitvoeringsbeleiden heeft, moet er prioriteit zijn.
Beleidsprioriteit is de volgorde waarin PowerShell verschillende beleiden toepast die op verschillende niveaus zijn ingesteld. Sommige uitvoeringsbeleiden hebben een hogere prioriteit dan andere.
Wanneer je Get-ExecutionPolicy -List uitvoert, vind je alle momenteel geldende uitvoeringsbeleidsregels, gerangschikt van laagste naar hoogste prioriteit. Bijvoorbeeld, aangezien MachinePolicy een lagere prioriteit heeft, zullen de beleidsregels van LocalMachine en CurrentUser deze overschrijven.
Werken met uitvoeringsbeleidsregels
Genoeg inzicht in de achtergrond van uitvoeringsbeleidsregels, laten we nu ingaan op hoe je ermee werkt! Om te werken met de uitvoeringsbeleidsregels van PowerShell, heb je twee commando’s tot je beschikking: Get-ExecutionPolicy om momenteel gedefinieerde beleidsregels te ontdekken en Set-ExecutionPolicy om nieuwe beleidsregels in te stellen.
Huidig toegewezen beleidsregels ophalen
Voordat je uitvoeringsbeleidsregels kunt gaan wijzigen, moet je weten waar je mee werkt. Hiervoor heb je het commando Get-ExecutionPolicy. Dit commando geeft alle momenteel toegewezen beleidsregels op een computer weer.
Wanneer je het commando Get-ExecutionPolicy rechtstreeks uitvoert in een PowerShell-console zonder parameters, wordt het uitvoeringsbeleid weergegeven dat is ingesteld voor je huidige PowerShell-sessie.
Om het uitvoeringsbeleid in te zien dat is ingesteld voor een bepaalde scope, geef je de Scope-parameter op met de naam van de scope waarvoor je de resultaten wilt zien.
Om alle scopes en hun uitvoeringsbeleidsregels te bekijken, gebruik je de List-parameter zoals hieronder weergegeven.
Uitvoeringsbeleidsregels wijzigen
Zodra je weet welke uitvoeringsbeleidsregels momenteel zijn toegewezen, kun je ze ook wijzigen. Om het beleid op een enkele computer te wijzigen, heb je het Set-ExecutionPolicy-commando tot je beschikking. Maar als je in een organisatie zit, wil je beleidsregels in bulk wijzigen. In dat geval heb je altijd Group Policy tot je beschikking als je je in een Active Directory-domein bevindt.
Gebruik van Set-ExecutionPolicy
Laten we eerst kijken hoe je beleidsregels kunt wijzigen met het Set-ExecutionPolicy-commando. Open PowerShell als beheerder.
Voer nu het Set-ExecutionPolicy-commando uit met een enkele parameter (ExecutionPolicy) en geef de naam van het uitvoeringsbeleid op.
PowerShell zal dan vragen of je het uitvoeringsbeleid wilt wijzigen. Als je dat wilt, typ dan Y of A en druk op Enter.
Sommige PowerShell-commando’s moeten meerdere andere taken uitvoeren om te kunnen werken. Als je in het bovenstaande voorbeeld Y invoert, kan PowerShell je vragen om door te gaan voor elke stap. Als je A invoert, gaat het door voor alle volgende stappen.
Uitvoeren van Set-ExecutionPolicy zonder prompts
Standaard, wanneer u Set-ExecutionPolicy uitvoert, zal het u vragen of u de uitvoeringsbeleid wilt wijzigen. U kunt deze prompt overslaan door de Force parameter toe te voegen aan uw opdracht. Door de Force parameter te gebruiken, worden alle bevestigingsprompts onderdrukt.
Uitvoeringsbeleid van PowerShell instellen via het register
Aangezien de meeste uitvoeringsbeleiden in het register worden opgeslagen (met uitzondering van Process), kunt u ook beleiden rechtstreeks via het register wijzigen.
Om uitvoeringsbeleiden via het register te wijzigen:
- Open de Windows Register-editor (regedit) of uw keuze van registerbewerkingstool.
2. Navigeer naar de registersleutel van het uitvoeringsbeleidbereik dat u wilt wijzigen.
LocalMachine – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
CurrentUser – HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
3. Klik met de rechtermuisknop op de registersleutel en maak een nieuwe tekenreekswaarde genaamd ExecutionPolicy.
4. Dubbelklik op de nieuw gemaakte tekenreekswaarde ExecutionPolicy en voer de gewenste naam van het uitvoeringsbeleid in (Restricted, RemoteSigned, AllSigned, Unrestricted, of Undefined).
5. Creëer een andere tekenreekswaarde met dezelfde sleutel genaamd Path. De tekenreekswaarde Path vertegenwoordigt het pad naar de PowerShell-engine. Zorg ervoor dat de waarde van Path is ingesteld op C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe, wat verwijst naar de Windows PowerShell-engine.
De uitvoeringsbeleid van CurrentUser overschrijft een beleid van LocalMachine. Als u een beleid van CurrentUser hebt ingesteld in het register en probeert het uitvoeringsbeleid te wijzigen via Set-ExecutionPolicy, dat standaard het beleid instelt op het niveau van LocalMachine, zal PowerShell een fout retourneren zoals hieronder weergegeven.
Het instellen van het PowerShell-uitvoeringsbeleid via het groepsbeleid
Als u zich in een organisatie met Active Directory bevindt, wilt u niet naar alle Windows-machines gaan en het Set-ExecutionPolicy-cmdlet uitvoeren. In plaats daarvan kunt u beleidsregels in bulk beheren met groepsbeleid.
Om uitvoeringsbeleid te beheren via GPO:
Maak het Group Policy Object
- Open de Group Policy Management-toepassing op een domeincontroller of op uw domeingejoinde werkstation.
2. Breid Domains uit —> <uw Active Directory-forest> —> Group Policy Objects.
3. Klik met de rechtermuisknop op Group Policy Objects en klik op New.
4. Geef je GPO een naam. In deze handleiding wordt de GPO genoemd PowerShell Uitvoeringsbeleid.
5. Klik met de rechtermuisknop op de nieuw gemaakte GPO en klik op Bewerken.
6. Ga naar Computerconfiguratie\Beleid\Beheersjablonen\Windows-onderdelen\Windows PowerShell.
7. Open de instelling in het rechter venster, open de Schakel Script Uitvoering in instelling.
8. In het vak Schakel Script Uitvoering in, selecteer de optie Ingeschakeld. U kunt nu een van de onderstaande opties kiezen:
9. Wijzig nu het Uitvoeringsbeleid naar het gewenste beleid.
- Alleen ondertekende scripts toestaan – Hiermee worden alle scripts uitgevoerd wanneer ze zijn ondertekend door een vertrouwde uitgever.
- Lokale scripts en op afstand ondertekende scripts toestaan – Hiermee worden lokale scripts uitgevoerd, maar moeten scripts die van internet worden gedownload, zijn ondertekend door een vertrouwde uitgever.
- Alle scripts toestaan – Hiermee worden alle scripts uitgevoerd.
Wijs het Groepsbeleidsobject toe
Zodra de GPO is gemaakt, is het tijd om deze toe te wijzen aan je doelcomputers. Om dit te doen, moet je de GPO toewijzen aan een Organizational Unit (OU) van Active Directory.
Als je in plaats van het maken van een nieuwe GPO een bestaande GPO hebt bewerkt, is die GPO waarschijnlijk al toegewezen aan een OU.
- In Group Policy Management, navigeer naar de gewenste OU door te gaan naar Domeinen —> <jouw Active Directory bos> —> <Jouw OU>.
2. Klik met de rechtermuisknop op de OU en selecteer Een bestaande GPO koppelen…
3. Selecteer de zojuist aangemaakte GPO (PowerShell Uitvoeringsbeleid) en klik op OK.
Je zou nu de GPO toegewezen aan de OU moeten zien zoals hieronder weergegeven.
Op dit punt kun je ofwel wachten op het gedefinieerde Group Policy vernieuwingsinterval of de gpupdate opdracht uitvoeren op een doelcomputer om een vernieuwing af te dwingen.
Beperken van Lokale Beleidswijzigingen
Zodra een GPO van kracht is die het uitvoeringsbeleid wijzigt, kunnen lokale gebruikers het beleid niet langer wijzigen via de lokale PowerShell-console. Als ze het proberen, zullen ze een foutmelding ontvangen, zoals hieronder weergegeven.
Volledig omzeilen van het Uitvoeringsbeleid
Zoals eerder vermeld, is een uitvoeringsbeleid niet per se bedoeld als een beveiligingsmaatregel. Waarom niet? Omdat je het volledig kunt omzeilen als je dat wilt op een paar verschillende manieren.
Het gebruik van de -ExecutionPolicy Bypass Parameter
In tegenstelling tot andere uitvoeringsbeleidsregels wordt het beleid Bypass meestal niet ingesteld in de PowerShell-console, maar doorgegeven aan de engine powershell.exe die als beheerder wordt uitgevoerd.
Bijvoorbeeld, om een script genaamd Hello World.ps1 volledig over te slaan bij het uitvoeren van elk uitvoeringsbeleid, roept u powershell.exe aan, gebruikt u de parameter Bypass en geeft u het bestandspad op zoals hieronder weergegeven.
Het lezen van scripts en het uitvoeren van rauwe code
U kunt ook elk uitvoeringsbeleid omzeilen door eerst de inhoud van een script te lezen en die inhoud rechtstreeks aan de PowerShell-engine door te geven. Op deze manier worden elk commando afzonderlijk uitgevoerd en niet als één geheel script tegelijk.
Zoals u hieronder kunt zien, is het uitvoeringsbeleid ingesteld op Beperkt, maar door het script te lezen en door te geven aan powershell.exe, werkt het toch.
Deze aanpak lijkt op het openen van een script in een PowerShell-editor zoals PowerShell ISE of Visual Studio Code, een regel selecteren en op F8 drukken.
Conclusie
U zou nu alles moeten weten over PowerShell-uitvoeringsbeleidsregels. Ook al zijn ze technisch gezien geen beveiligingsmaatregel, u moet ze toch beheren in uw organisatie volgens de organisatorische beleidsregels.