По умолчанию оболочка windows powershell не загружает команды из текущего расположения

Обновлено: 06.07.2024

Оболочка Windows PowerShell построена с использованием интерактивного интерфейса командной строки (CLI). Одна из основных задач интерфейса CLI – предоставить пользователям возможность запускать программы. Однако я не раз сталкивался с такими вопросами как: «Необходимо запустить такую-то утилиту командной строки в оболочке PowerShell. Я безуспешно пытался различными способами заключить параметры в кавычки. Как заставить программу корректно работать в оболочке PowerShell?»

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

Однако в оболочке PowerShell задача немного усложняется, поскольку синтаксический анализатор командной строки здесь сложнее, чем в оболочке Cmd.exe. Команда Echo в оболочке PowerShell на самом деле является псевдонимом команды Write-Host, поэтому вы не можете задействовать ее в оболочке PowerShell для просмотра полной командной строки, как в оболочке Cmd.exe. В оболочке PowerShell отсутствует встроенный механизм просмотра полной командной строки для исполняемого файла.

Чтобы обойти данное ограничение, я написал короткую программу для командной строки, ShowArgs.exe. Цель этой программы — вывести на экран переданные ей параметры командной строки без анализа или интерпретации. Заменив ShowArgs.exe программу, которую вы пытаетесь запустить (но сохраняя параметры вашей программы), вы сможете увидеть именно те параметры командной строки, которые будет использовать оболочка PowerShell.

Используя приложение ShowArgs.exe (доступно для загрузки на нашем сайте), я покажу, как справляться с наиболее распространенными проблемами типа «как правильно заключить выражение в кавычки» при запуске исполняемых файлов в оболочке PowerShell. Для примеров, приведенных в этой статье, я создал каталог с именем C:\Sample Tools и скопировал файл ShowArgs.exe в него.

Запуск исполняемых файлов в оболочке PowerShell

Для запуска исполняемого файла в оболочке PowerShell достаточно просто указать его имя. Точно так же запускаются исполняемые файлы в оболочке Cmd.exe. На экране 1 приведены два примера запуска приложения ShowArgs.exe напрямую в оболочке PowerShell. На экране 1 для запуска приложения ShowArgs.exe требуется префикс «.\», так как оболочка PowerShell по умолчанию не запускает исполняемые файлы из текущего каталога.

Экран 1. Запуск исполняемого файла в PowerShell

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

Экран 2. Использование оператора вызова в некоторых случаях не является обязательным

Однако вы не можете использовать оператор & для вызова командной строки целиком. На экране 3 показана эта распространенная ошибка. Первая команда на экране 3 завершается с ошибкой, потому что строка, заключенная в кавычки, после оператора вызова не является именем файла (о чем и сообщает система). Вторая команда на экране 3 исправляет эту ошибку. В этой команде в кавычки помещается только имя исполняемого файла, а параметры выносятся в конец команды.

Экран 3. Общие ошибки при использовании оператора вызова

Как показано на экране 4, вы можете сохранить результаты выполнения исполняемого файла в переменную. Первая команда на экране запускает файл Find.exe с параметром «/?» и сохраняет результат в переменную $findHelp. Вторая команда показывает, что переменная содержит массив, а последняя выводит на экран содержимое массива. Если программа возвращает только одну строку, переменная будет содержать отдельную строку, а не массив.

Экран 4. Сохранение результатов выполнения исполняемого файла в переменную

Командная строка исполняемого файла: заключение параметров в кавычки

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

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

Инструкция 1. В случаях, когда вы указываете параметр непосредственно в командной строке и этот параметр содержит пробелы, необходимо только добавить кавычки. Например:

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

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

Инструкция 2. Если в качестве параметра исполняемого файла вы хотите передать переменную, то можете просто поместить переменную в командную строку с исполняемым файлом. Ниже приведен пример:

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

Инструкция 3. Если параметр использует аргумент, связанный с параметром (то есть параметр и его аргумент должны писаться слитно, без разделения пробелом), вы можете заключить в кавычки параметр целиком, вместе с его аргументом. Для тех, кто не понимает разницы между параметром и аргументом, поясню, что параметр – это выражение, которое указывается после команды и управляет ее поведением, в то время как аргумент предоставляет дополнительную информацию о параметре. Вы также можете заключить в кавычки лишь аргумент параметра. Например, следующие команды эквивалентны друг другу:

Аналогичная ситуация возникает, если между параметром и аргументом находится разделительный символ, например двоеточие (:) или знак равенства (=). Другими словами, следующие две команды эквивалентны:

Следующие две команды также эквивалентны:

Как и в предыдущих примерах, добавление дополнительных кавычек не обязательно.

Инструкция 4. Если вы используете переменную в качестве аргумента параметра, не требуется добавлять дополнительные кавычки, даже если содержимое переменной включает пробелы. Например, все перечисленные ниже команды будут работать корректно:

Инструкция 5. Если параметр начинается с дефиса (-), аргумент параметра связан с параметром (не отделен пробелом) и аргумент параметра хранится в переменной, необходимо либо поставить перед дефисом в начале параметра знак обратной кавычки (`) либо взять в кавычки параметр целиком или только его связанный аргумент. Например, следующая команда не будет работать корректно:

Вместо нее необходимо использовать одну из команд:

Это правило применяется, когда параметр и аргумент либо связаны напрямую (например, -name$name) или через символ (такой как: или =), стоящий между ними. Однако оно неприменимо, если аргумент параметра не хранится в переменной. Например, следующие две команды эквивалентны:

Если вы не знаете наверняка, командную строку какого вида оболочка PowerShell будет использовать, замените имя исполняемого файла приложением ShowArgs.exe, и вы увидите именно те параметры командной строки, которые оболочка PowerShell будет использовать для запуска исполняемого файла.

Получение кода завершения исполняемого файла

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

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

Если требуется сформировать командную строку, зависящую от логических операторов, вам может потребоваться дополнительная гибкость. Например, рассмотрим сценарий Test.ps1 в листинге 1.

Если вы запустите сценарий Test1.ps1 с параметром -Test, оболочка PowerShell выполнит команду:

Однако на самом деле необходимо, чтобы оболочка PowerShell выполнила команду:

Другими словами, мы хотим, чтобы оболочка PowerShell интерпретировала параметр $params как командную строку целиком, а не как отдельный строковый параметр исполняемого файла.

Одно решение заключается в использовании команды Start-Process (см. листинг 2). У команды Start-Process есть параметр -ArgumentList, который представляет собой массив параметров командной строки. Оболочка PowerShell автоматически не расставляет кавычки для этих параметров, так что вам придется вставить кавычки там, где нужно.

У использования команды Start-Process есть ряд недостатков:

Если вы хотите перехватить выходные данные исполняемого файла, необходимо задействовать параметр -RedirectStandardOutput. Сценарий Test3.ps1 в листинге 3 иллюстрирует этот подход. Данный сценарий создает временный файл, запускает исполняемый файл (перенаправляя выходные данные во временный файл) и возвращает выходные данные с помощью команды Get-Content.
Команда Start-Process не обновляет переменную $LASTEXITCODE.

Чтобы добавить еще немного гибкости, вы можете задействовать функцию Start-Executable, описанную в листинге 4. Функция Start-Executable не использует временный файл и обновляет переменную $LASTEXITCODE. Параметр -ArgumentList данной функции работает аналогично параметру -ArgumentList команды Start-Process.

Автор: Scott Sutherland

По умолчанию PowerShell сконфигурирован на запрет выполнения скриптов в системах на базе ОС Windows. Подобные настройки могут затруднять работу админов, пентестеров и разработчиков, и в этой статье я расскажу о 15 способах обхода execution policy без использования прав локального администратора. Полагаю, что есть техники, которые не будут упомянуты из-за моей забывчивости или элементарного незнания, однако, надеюсь, нижеприведенный список будет хорошим стартом для тех, кто нуждается в нем.

Что такое PowerShell Execution Policy?

Execution policy определяет, какие типы скриптов могут быть запущены (если вообще могут) в системе. По умолчанию значение параметра выставлено как «Restricted», что запрещает запуск любых скриптов. Однако следует понимать, что настройка Execution Policy никогда не относилась к управлению безопасностью, а служила лишь для того, чтобы администраторы случайно не могли вывести систему из строя. Именно поэтому существует множество техник, чтобы обойти эти настройки, включая некоторые, предоставленные компанией Microsoft. Более подробно о Execution Policy и других настройках безопасности в PowerShell рекомендую почитать блог Карлоса Переса.

Зачем нужно обходить Execution Policy?

Встроен в Window.
Может вызывать Windows API.
Может запускать команды без записи на диск.
Может избегать обнаружения антивирусами.
Уже помечен как «достоверный» и находится в большинстве белых списков.
Используется при написании многих утилит безопасности с открытым исходным кодом.

Как посмотреть настройки Execution Policy

PS C:\> Get-ExecutionPolicy

Рисунок 1: Результат выполнения команды в системе, где установлен запрет на запуск скриптов

Важно отметить, что Execution Policy может устанавливаться на различных уровнях системы. Чтобы посмотреть список уровней, используйте команду ниже (за более подробной информацией обращайтесь к соответствующей странице TechNet).

Get-ExecutionPolicy -List | Format-Table –AutoSize

Рисунок 2: Настройки Execution Policy на различных системных уровнях

Настройка тестовой среды

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

При запуске скрипта в системе со стандартными настройками Execution Policy выводится следующая ошибка:

Рисунок 3: Ошибка, выводимая при запуске тестового скрипта в среде, где настрое запрет на запуск скриптов

Если ваша текущая политика разрешает запуск скриптов, поставить запрет (в целях тестирования) можно при помощи команды Set-ExecutionPolicy Restricted, запущенной из консоли администратора PowerShell. Ну, хорошо, достаточно пустой болтовни. Перейдем непосредственно к методам обхода запрета, установленного в Execution Policy.

1. Копирование скрипта непосредственно в интерактивную консоль PowerShell

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

Рисунок 4: Запуск скрипта при помощи копирования в интерактивную консоль

2. Отправка содержимого скрипта в стандартный поток ввода PowerShell

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

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

Рисунок 5: Вывод содержимого скрипта в стандартный поток ввода

3. Чтение скрипта из файла и перенаправление содержимого в стандартный поток ввода PowerShell

Используйте стандартную команду «type» или PowerShell команду «Get-Content» для чтения содержимого скрипта с диска и перенаправьте полученный результат в стандартный поток ввода. Техника не влечет за собой изменения настроек, однако требует записи на диск. Чтобы избежать записи на диск, можно использовать сетевой общий ресурс (network share).

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

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

Рисунок 6: Использование команды Get-Content

Пример 2: Использование команды Type

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

Рисунок 7: Использование команды Type

4. Загрузка скрипта из сети и запуск при помощи Invoke Expression

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

Рисунок 8: Загрузка скрипта из интернета и запуск при помощи Invoke Expression

5. Использование параметра Command

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

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

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

Рисунок 9: Запуск скрипта при помощи полной версии параметра

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

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

Можно объединить вышеуказанные команды в пакетные файлы и поместить их в автозагрузку для увеличения уровня привилегий.

6. Использование параметра EncodeCommand

Метод схож с предыдущей техникой, но здесь все скрипты закодированы в строку Unicode. Кодирование скрипта позволяет избежать ошибок, возникающих при использовании параметра «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

Рисунок 10: Полный вариант команды

Пример 2: Сокращенный параметр

powershell.exe -Enc
VwByAGkAdABlAC0ASABvAHMAdAAgACcATQB5ACAAdgBvAGkAYwBlACAA
aQBzACAAbQB5ACAAcABhAHMAcwBwAG8AcgB0ACwAIAB2AGUAcgBpAGYAeQAgAG0AZQAuACcA

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

Техника, найденная мной в блоге Obscuresec, используется через интерактивную консоль или в сочетании с параметром «Command». Главная особенность метода в том, что его можно использовать для запуска команд на удаленных системах, где разрешен запуск скриптов PowerShell. Техника не влечет за собой изменения настроек и не требует записи на диск.

Рисунок 11: Использование команды Invoke-Command

Команда ниже, созданная по мотивам блога Obscuresec, может использоваться для переноса настроек execution policy с удаленной машины на локальную.

invoke-command -computername Server01 -scriptblock | set-executionpolicy -force

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

Как и в предыдущем случае, техника используется через интерактивную консоль или в сочетании с параметром «Command». Метод не влечет за собой изменения настроек и не требует записи на диск. Ниже показано несколько наиболее распространенных способов использования команды Invoke-Expression для обхода execution policy.

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

Get-Content .\runme.ps1 | Invoke-Expression

Рисунок 12: Полный вариант команды Get-Content

Пример 2: Сокращенный вариант Get-Content

GC .\runme.ps1 | iex

9. Использование флага Bypass

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

Рисунок 13: Использование флага Bypass

10. Использование флага Unrestricted

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

Рисунок 14: Использование флага Unrestricted

11. Использование флага Remote-Signed

Создайте скрипт. Затем подпишите его, используя руководство, написанное Карлосом Пересом. Теперь запустите скрипт, используя команду ниже:

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

12. Запрет ExecutionPolicy путем выгрузки Authorization Manager

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"))>

Рисунок 15: Отключение Authorization Manager в текущей сессии

13. Установка Excution Policy для уровня Process

В начале статьи было сказано, что execution policy может быть применена к различным уровням (включая уровень process, на которым у вас есть контроль). Используя эту технику, execution policy может быть установлена в статус unrestricted во время сессии. Кроме того, метод не влечет за собой изменения в настройках и не требует записи на диск. Я нашел эту технику в блоге r007break.

Set-ExecutionPolicy Bypass -Scope Process

Рисунок 16: Установка статуса Unrestricted для уровня Process

14. Установка статуса Unrestricted для уровня CurrentUser при помощи команды

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

Set-Executionpolicy -Scope CurrentUser -ExecutionPolicy UnRestricted

Рисунок 17: Установка статуса Unrestricted для уровня CurrentUser

15. Установка статуса Unrestricted для уровня CurrentUser через реестр

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

Рисунок 18: Выставление статуса для execution policy через реестр

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

Я написал простой командный файл в виде сценария PowerShell, и при его запуске возникают ошибки.

Он находится в каталоге сценариев на моем пути. Это ошибка, которую я получаю:

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

Я заглянул в справку, но она мне не помогла.

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

Попробуйте ввести это:

Это укажет PowerShell разрешить запуск локальных (то есть на локальном диске) неподписанных сценариев.

Затем попробуйте снова выполнить свой сценарий.

Вы должны запустить Powershell с правами администратора, по крайней мере, под Windows 8! И вы также должны запустить сценарий PowerShell с правами администратора под Windows 7. Это довольно устрашающий ответ. Во-первых, он навсегда изменяет уровень безопасности Powershell по умолчанию, возможно, нежелательным (и небезопасным) образом. С другой стороны, он не может даже адекватно объяснить, что подписанные удаленные сценарии и неподписанные локальные сценарии - но не неподписанные удаленные сценарии, которые Chocolatey иногда требует - ему будут предоставлены права исполнения. Большинство пользователей, вероятно, захотят это и это вместо этого. Хотя беспокойство Сесила по поводу некоторых слабых мест в ответе справедливо, я хотел указать на несколько вещей. 1) Две его ссылки открывают для меня одну и ту же страницу. 2) Если вы хотите, чтобы сценарии просто запускались, установка политики выполнения, вероятно, все еще способ, и, возможно, не связанный с OP: 3) кажется, что лучшая политика - для сценариев запуска, укажите политику выполнения и область действия в командной строке запустив сценарий, и для входа в систему установите необходимую конфигурацию сеанса. Если вы хотите обеспечить высокий уровень безопасности во время сеанса Windows, но ограниченный для входа в систему, вам следует уточнить порядок выполнения сценариев. Для однократных попыток я считаю наиболее полезным ответ Ankur ниже, который определяет временное исключение для работающего экземпляра PowerShell.

Вам нужно запустить Set-ExecutionPolicy :

Какое значение ExecutionPolicy по умолчанию, которое Windows устанавливает для новой установки?

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

Вышеупомянутая команда работала у меня, даже когда произошла следующая ошибка:

Также стоит знать, что вам может потребоваться включить .\ перед именем скрипта. Например:

Команда set-executionpolicy unrestricted позволит любому сценарию, который вы создаете, запускаться от имени вошедшего в систему пользователя. Перед выходом из системы обязательно установите для параметра «Executionpolicy» значение «подписано» с помощью команды set-executionpolicy signed .

set-executionpolicy signed дает Cannot bind parameter 'ExecutionPolicy' и т. Д.

В Windows 10: щелкните изменить свойство безопасности myfile.ps1 и измените «разрешить доступ», щелкнув правой кнопкой мыши / свойства на myfile.ps1.

Мы можем обойти политику выполнения красивым способом (внутри командной строки):

Или внутри powershell:

Мне удалось обойти эту ошибку, вызвав PowerShell следующим образом:

То есть я добавил -executionpolicy bypass к способу вызова скрипта.

Это работало с пакетом обновления 1 для Windows 7. Я новичок в PowerShell, поэтому могут быть предостережения, о которых я не знаю.

[Edit 2017-06-26] Я без проблем продолжал использовать эту технику в других системах, включая Windows 10 и Windows 2012 R2.

Вот что я сейчас использую. Это предохраняет меня от случайного запуска скрипта, щелкнув по нему. Когда я запускаю его в планировщике, я добавляю один аргумент: «планировщик», и это обходит приглашение.

Это также приостанавливает окно в конце, чтобы я мог видеть вывод PowerShell.

03.06.2020

PowerShell, Windows 10, Windows Server 2016

Комментариев пока нет

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

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

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

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

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

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

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

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

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

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

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

Set-ExecutionPolicy RemoteSigned –Force

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

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

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

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

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass –Force

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

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

Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy Restricted –Force

Откройте ветку реестра 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.

Т.е. вы можете распространить нужные настройки политики исполнения скриптов через реестр с помощью Group Policy Preferences.

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

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

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

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

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

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

Аналогичным образом можно настроить Execution Policy на отдельном компьютере с помощью локального редактора GPO – gpedit.msc.

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

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

Читайте также: