powershell политика запуска скриптов

Настройка политики запуска скриптов (Execution Policy) PowerShell

По-умолчанию настройки Windows запрещают запуск скриптов PowerShell. Это необходимо для предотвращения запуска вредоносного кода на PowerShell. Настройки политик запуска PowerShell скриптов определяются в Execution Policy. В этой статье мы рассмотрим доступные политики запуска PS скриптов, как изменить Execution Policy и настроить политики использования PowerShell скриптов на компьютерах в домене.

Выполнение PowerShell скриптов запрещено для данной системы

При попытке выполнить PowerShell скрипт (файл с расширением PS1) на чистой Windows 10, появляется ошибка:

Текущее значение политики выполнения скриптов PowerShell на компьютере можно получить командой:

Доступны следующие значения PowerShell Execution Policy:

Как разрешить запуск скриптов PowerShell с помощью Execution Policy?

Чтобы изменить текущее значение политики запуска PowerShell скриптов, используется командлет Set-ExecutionPolicy.

Например, разрешим запуск локальных скриптов:

Подтвердите изменение политики запуска PS1 скриптов, нажав Y или A.

Чтобы запрос не появлялся, можно использовать параметр Force.

Set-ExecutionPolicy RemoteSigned –Force

Если вы установили значение политики PowerShell Execution Policy в Unrestricted, то при запуске удаленных скриптов из сетевых каталогов по UNC пути, скачанных из интернета файлов, все равно будет появляться предупреждение:

Также следует различать различные области действия политик выполнения скриптов PowerShell (scopes):

Область применения политики можно указать с помощью параметр Scope командлета Set-ExecutionPolicy. Например:

Проверим текущие настройки ExecutionPolicy для всех областей:

Значение политики выполнения, которые вы задаете с помощью командлета Set-ExecutionPolicy для областей CurrentUser и LocalMachine, хранятся в реестре. Например, выполните командлет:

Откройте ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell и проверьте значение REG_SZ параметра ExecutionPolicy. Оно изменилось на Restricted (допустимые значения параметра Restricted, AllSigned, RemoteSigned, Bypass, Unrestricted и Undefined).

Аналогичные настройки для области CurrentUser находятся в разделе реестра пользователя HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.

Отметим, что чаще всего в корпоративной среде используется ExecutionPolicy со значением AllSigned на уровне LocalMachine. Это обеспечивает максимальный баланс между безопасностью и удобством. Для личного пользования на компьютере можно использовать RemoteSigned. Ну а Bypass политику лучше использовать только для запуска отдельных задач (например для запуска скриптов через GPO или заданий планировщика).

Настройка PowerShell Execution Policy с помощью групповых политик

Вы можете настроить политику выполнения PowerShel скриптов на серверах или компьютерах домена с помощью групповых политик.

После настройки политики выполнения через GPO вы не сможете изменить настройки политики выполнения скриптов вручную. При попытке изменить настройки Execution Policy на компьютере, на который применяется такая GPO, появится ошибка:

Способы обхода политики PowerShell Execution

Есть несколько трюков, которые могут помочь вам, когда нужно запустить на компьютере PowerShell скрипт, не изменяя настройки политики выполнения. Например, я хочу запустить простой PS1 скрипт, который поверяет, что запущен с правами администратора.

Можно с помощью Get-Content получить содержимое скрипта и перенаправить его в стандартныq поток ввода консоли PS.

Источник

Set-Execution Policy

Sets the PowerShell execution policies for Windows computers.

Syntax

Description

The Set-ExecutionPolicy cmdlet changes PowerShell execution policies for Windows computers. For more information, see about_Execution_Policies.

Beginning in PowerShell 6.0 for non-Windows computers, the default execution policy is Unrestricted and can’t be changed. The Set-ExecutionPolicy cmdlet is available, but PowerShell displays a console message that it’s not supported.

An execution policy is part of the PowerShell security strategy. Execution policies determine whether you can load configuration files, such as your PowerShell profile, or run scripts. And, whether scripts must be digitally signed before they are run.

The Set-ExecutionPolicy cmdlet’s default scope is LocalMachine, which affects everyone who uses the computer. To change the execution policy for LocalMachine, start PowerShell with Run as Administrator.

Examples

Example 1: Set an execution policy

This example shows how to set the execution policy for the local computer.

The Set-ExecutionPolicy cmdlet uses the ExecutionPolicy parameter to specify the RemoteSigned policy. The Scope parameter specifies the default scope value, LocalMachine. To view the execution policy settings, use the Get-ExecutionPolicy cmdlet with the List parameter.

Example 2: Set an execution policy that conflicts with a Group Policy

This command attempts to set the LocalMachine scope’s execution policy to Restricted. LocalMachine is more restrictive, but isn’t the effective policy because it conflicts with a Group Policy. The Restricted policy is written to the registry hive HKEY_LOCAL_MACHINE.

The Set-ExecutionPolicy cmdlet uses the ExecutionPolicy parameter to specify the Restricted policy. The Scope parameter specifies the default scope value, LocalMachine. The Get-ChildItem cmdlet uses the Path parameter with the HKLM provider to specify registry location.

Example 3: Apply the execution policy from a remote computer to a local computer

This command gets the execution policy object from a remote computer and sets the policy on the local computer. Get-ExecutionPolicy sends a Microsoft.PowerShell.ExecutionPolicy object down the pipeline. Set-ExecutionPolicy accepts pipeline input and doesn’t require the ExecutionPolicy parameter.

Example 4: Set the scope for an execution policy

This example shows how to set an execution policy for a specified scope, CurrentUser. The CurrentUser scope only affects the user who sets this scope.

Set-ExecutionPolicy uses the ExecutionPolicy parameter to specify the AllSigned policy. The Scope parameter specifies the CurrentUser. To view the execution policy settings, use the Get-ExecutionPolicy cmdlet with the List parameter.

The effective execution policy for the user becomes AllSigned.

Example 5: Remove the execution policy for the current user

This example shows how use the Undefined execution policy to remove an execution policy for a specified scope.

Set-ExecutionPolicy uses the ExecutionPolicy parameter to specify the Undefined policy. The Scope parameter specifies the CurrentUser. To view the execution policy settings, use the Get-ExecutionPolicy cmdlet with the List parameter.

Example 6: Set the execution policy for the current PowerShell session

The Set-ExecutionPolicy uses the ExecutionPolicy parameter to specify the AllSigned policy. The Scope parameter specifies the value Process. To view the execution policy settings, use the Get-ExecutionPolicy cmdlet with the List parameter.

Example 7: Unblock a script to run it without changing the execution policy

This example shows how the RemoteSigned execution policy prevents you from running unsigned scripts.

A best practice is to read the script’s code and verify it’s safe before using the Unblock-File cmdlet. The Unblock-File cmdlet unblocks scripts so they can run, but doesn’t change the execution policy.

The Set-ExecutionPolicy uses the ExecutionPolicy parameter to specify the RemoteSigned policy. The policy is set for the default scope, LocalMachine.

The Get-ExecutionPolicy cmdlet shows that RemoteSigned is the effective execution policy for the current PowerShell session.

The Start-ActivityTracker.ps1 script is executed from the current directory. The script is blocked by RemoteSigned because the script isn’t digitally signed.

For this example, the script’s code was reviewed and verified as safe to run. The Unblock-File cmdlet uses the Path parameter to unblock the script.

To verify that Unblock-File didn’t change the execution policy, Get-ExecutionPolicy displays the effective execution policy, RemoteSigned.

The script, Start-ActivityTracker.ps1 is executed from the current directory. The script begins to run because it was unblocked by the Unblock-File cmdlet.

Parameters

Prompts you for confirmation before running the cmdlet.

Specifies the execution policy. If there are no Group Policies and each scope’s execution policy is set to Undefined, then Restricted becomes the effective policy for all users.

The acceptable execution policy values are as follows:

Suppresses all the confirmation prompts. Use caution with this parameter to avoid unexpected results.

Specifies the scope that is affected by an execution policy. The default scope is LocalMachine.

The effective execution policy is determined by the order of precedence as follows:

Execution policies for the CurrentUser scope are written to the registry hive HKEY_LOCAL_USER.

Execution policies for the LocalMachine scope are written to the registry hive HKEY_LOCAL_MACHINE.

Shows what would happen if the cmdlet runs. The cmdlet is not run.

Inputs

Microsoft.PowerShell.ExecutionPolicy, System.String

Outputs

None

Set-ExecutionPolicy doesn’t return any output.

Notes

Set-ExecutionPolicy doesn’t change the MachinePolicy and UserPolicy scopes because they are set by Group Policies.

Set-ExecutionPolicy doesn’t override a Group Policy, even if the user preference is more restrictive than the policy.

If the Group Policy Turn on Script Execution is enabled for the computer or user, the user preference is saved, but it is not effective. PowerShell displays a message that explains the conflict.

Источник

Запуск PowerShell скриптов с помощью GPO

В современных операционных системах (Windows 10 / Windows Server 2016) вы можете настраивать запуск логон/логоф скриптов на PowerShell напрямую из редактора GPO.

Запустите консоль управления доменными политиками — GPMC.msc (Group Policy Management сonsole), создайте новую политику и назначьте ее на нужный контейнер с пользователями или компьютерами (можно использовать WMI фильтры GPO для более тонкого нацеливания политики). Перейдите в режим редактирования политики.

Вы должны выбрать раздел GPO для запуска PowerShell скрипта в зависимости от того, когда вы хотите выполнить ваш скрипт.

Запуск PowerShell скрипта при загрузке компьютера с помощью групповой политики

Допустим, нам нужно запускать PowerShell скрипт при загрузке Windows. Для этого нужно выбрать Startup и в открывшемся окне перейди на вкладку PowerShell Scripts.

Теперь нужно скопировать файл с вашим PowerShell скриптом на контроллер домена. Нажмите на кнопку Show Files и перетяните файл с PowerShell скриптом (расширение ps1) в открывшееся окно проводника (консоль автоматически откроет каталог \\yourdomain\SysVol\yourdomain\Policies\<Здесь_GUID_вашей_GPO>\Machine\Scripts\Startup вашей политики в каталоге SysVol на ближайшем контроллере домена).

Теперь нужно нажать кнопку Add и добавить скопированный файл скрипта ps1 в список запускаемых политикой PowerShell скриптов.

Если вы запускаете несколько PowerShell скриптов через GPO, вы можете управлять порядком из запуска с помощью кнопок Up/Down.

Если вам не подходит не один из предложенных сценариев настройки политики запуска PowerShell скриптов, вы можете запускать PowerShell скрипты в режиме Bypass (скрипты не блокируются, предупреждения не появляются).

dp0 при запуске на клиенте автоматически преобразуются в UNC путь до каталога со скриптом на SYSVOL.

В данном случае вы принудительно разрешили запуск любого (даже ненадежного) скрипта PowerShell с помощью параметра Bypass.

Источник

Политика выполнения скриптов PowerShell

При разработке PowerShell особое внимание было уделено безопасности. Одной из мер безопасности является наличие политики выполнения (Execution Policy), которая определяет, могут ли скрипты PowerShell выполняться в системе, и если могут, то какие именно.

Для примера возьмем чистую Windows 10, откроем консоль PowerShell и попробуем выполнить простой скрипт. Попытка завершится ошибкой, поскольку, как видно из сообщения, выполнение скриптов в системе запрещено.

Это сработала политика выполнения, и если мы все же хотим выполнить скрипт, то ее необходимо изменить. Выбрать можно одно из следующих значений:

• Restricted — в системе запрещено выполнение любых скриптов, допускается только выполнение отдельных команд. Это политика по умолчанию для клиентских ОС Windows;
• AllSigned — разрешено выполнение только скриптов, имеющих цифровую подпись от доверенного издателя;
• RemoteSigned — для удаленных скриптов требуется наличие цифровой подписи, локальные скрипты выполняются без ограничений. Удаленными считаются скрипты, полученные из удаленных источников (загруженные из интернета, полученные по электронной почте и т.п.), локальными — скрипты, созданные на локальном компьютере. Это политика по умолчанию для серверных ОС Windows;
• Unrestricted — разрешено выполнение любых скриптов, как локальных так и удаленных. При выполнении удаленного скрипта без цифровой подписи будет выдано предупреждение. Это дефолтная и единственно возможная политика для всех ОС, отличных от Windows;
• Bypass — разрешено выполнение любых скриптов, никакие предупреждения и запросы не выводятся;
• Default — сбрасывает политику на значение по умолчанию. Для серверов это RemoteSigned, для клиентов Restricted;
• Undefined — не определено. В случае, если значение политики не определено, то применяется политика Restricted.

Теоретически все понятно, проверим на практике. Для просмотра параметров политики используется командлет Get-ExecutionPolicy, а для изменения Set-ExecutionPolicy.

Для начала выведем действующую политику выполнения командой:

Как и ожидалось, текущая политика Restricted. Разрешим выполнение скриптов, установив для политики значение Unrestricted:

И еще попробуем запустить скрипт. На сей раз он выполнился без ошибок.

Политика Unrestricted разрешает выполнение любых скриптов, но у нее все же есть ограничения. Для проверки я подготовил два скрипта, локальный localscript.ps1 и удаленный remotescript.ps1. Сначала запустим локальный, он выполнится без проблем. А вот при запуске удаленного скрипта PowerShell выдаст предупреждение и потребует подтвердить его запуск. При ручном выполнении это не является большой проблемой, а вот в случае автоматического запуска (напр. из планировщика) скрипт может не отработать.

Теперь изменим политику на Bypass и еще раз запустим удаленный скрипт. На сей раз он просто выполнился, безо всяких сообщений и подтверждений. Bypass удобно использовать в ситуациях, когда скрипт должен гарантированно отработать, причем автоматически, без вмешательства пользователя.

Следующим пунктом нашего меню идет политика RemoteSigned. Она является наиболее сбалансированной как с точки зрения безопасности, так и удобства использования, поэтому на серверах включена по умолчанию. Установим для политики значение RemoteSigned и проверим ее действие. Локальный скрипт снова выполняется без проблем, а удаленный выдает ошибку, поскольку у него нет подписи.

У вас может возникнуть вопрос, как именно PowerShell различает локальные и удаленные скрипты. Тут все просто. При загрузке файла приложение (напр. браузер) добавляет файл идентификатор зоны (ZoneId), который и определяет, откуда был взят файл. Идентификатор хранится в альтернативном потоке и имеет значение от 0 до 4:

• Локальный компьютер (0)
• Местная сеть (1)
• Надежные сайты (2)
• Интернет (3)
• Опасные сайты (4)

Если файл имеет ZoneId 3 или 4, то PowerShell считает его удаленным. А если на компьютере включена конфигурация усиленной безопасности Internet Explorer, то файлы, взятые из локальной сети, тоже могут считаться удаленными.

Как выполнить удаленный скрипт? Во первых его можно разблокировать (превратить в локальный), для этого есть специальный командлет Unblock-File. Хотя если просто открыть скрипт на локальном компьютере и внести в него изменения, то он тоже станет локальным.

Ну и во вторых удаленный скрипт можно подписать. Подписывание скриптов — это тема отдельной статьи, поэтому вдаваться в подробности не будем. Просто подпишем его уже имеющимся сертификатом, проверим подпись и выполним. На сей раз успешно.

Переходим к политике AllSigned. Это наиболее жесткая политика, требующая подписывания всех без исключения скриптов, как удаленных так и локальных. И даже с подписанными скриптами она работает не так, как RemoteSigned. Для примера сменим политику на AllSigned и снова запустим подписанный скрипт. В этот раз для его выполнения потребуется подтверждение, т.к. PowerShell посчитал подпись недоверенной.

Области применения

Политика выполнения имеет свою область действия (scope). Всего есть 5 областей:

Вывести значение политики для всех областей можно командой:

Получается, что при установке политики без указания области изменяется значение LocalMachine. Если же требуется указать конкретную область действия, то сделать это можно с помощью параметра Scope командлета Set-ExecutionPolicy. Для примера установим для области СurrentUser политику Bypass:

Затем проверим значение политики в текущем сеансе и убедимся в том, что оно изменилось на Bypass.

Теперь установим политику Unrestricted для области Process:

Еще раз проверим текущую политику, теперь она имеет значение Unrestricted. Т.е. более ″конкретная″ политика всегда имеет больший приоритет.

Для областей UserPolicy и MachinePolicy значение политики задаются через GPO. За настройку отвечает параметр Turn on Script Execution (Включить выполнение сценариев), находящийся в разделе Administrative Templates\Windows Components\Windows PowerShell. Для UserPolicy он находится в конфигурации пользователя (User Configuration), для MachinePolicy — в конфигурации компьютера (Computer Configuration). Политика, применяемая к компьютеру, имеет приоритет перед политикой пользователя.

Для установки политики надо включить параметр и выбрать одно из трех значений:

• Allow only signed scripts (Разрешать только подписанные сценарии) — политика AllSigned;
• Allow local scripts and remote signed scripts (разрешать локальные и удаленные подписанные сценарии) — политика RemoteSigned;
• Allow all scripts (Разрешать все сценарии) — политика Unrestricted.

Политика Bypass считается небезопасной и ее нельзя установить через групповые политики.

Для примера установим для MachinePolicy политику RemoteSigned и проверим результат. Как видите, политика, назначенная через GPO, имеет больший приоритет и переопределяет все остальные политики.

Более того, при использовании GPO становится невозможным переназначить политики вручную. При попытке изменения выдается предупреждение, а текущая политика остается без изменений.

А что будет, если ни для одной области политика не определена, т.е. везде стоит значение Undefined? В этом случае все просто, выполнение всех скриптов запрещается, а текущая политика принимает значение Restricted.

Обход политики

Можно ли как то запустить скрип в обход политики выполнения, не изменяя ее значение? В принципе можно, есть несколько способов.

К примеру для того, чтобы выполнить скрипт, достаточно открыть его в проводнике, кликнуть правой клавишей мыши и выбрать пункт Выполнить с помощью PowewrShell (Run with PowerShell). Это запускает оболочку PowerShell c политикой Bypass. При этом политика применяется только для выполнения конкретного скрипта, значение политики в реестре не изменяется.

Этот способ называется ″Run with PowerShell″ и у него есть некоторые ограничения. Скрипты, запущенные таким образом, не могут взаимодействовать с пользователем (выводить сообщения на экран, требовать ввода данных и т.п.). Скрипт просто запускается, выполняется и немедленно закрывается.

Собственно говоря, предыдущий способ использует запуск PowerShell с указанием требуемой политики. Сделать это можно из командной строки, например для запуска скрипта можно попробовать такую команду:

Теоретически эта команда должна выполнить скрипт, не смотря на текущую политику. Так написано в официальной документации Microsoft. На практике же этот способ работает не всегда, например на одном из проверенных мной компьютеров я получил ошибку. При этом из проводника скрипт успешно выполнился.

Еще один вариант — это попробовать изменить политику выполнения для области Process. Эта операция не вносит изменений в реестр и не требует прав администратора. Но в том случае, если для назначения политики выполнения используются групповые политики, этот способ не сработает.

Ну и наконец можно просто считать содержимое скрипта и выполнить его в виде команды. Например так:

Источник