SCCM,Application,Powershell – software restriction policy


Все начиналось с простого: потребовалось раскатать на пользователей сертификат. С помощью групповых политик на пользователей можно распространить только корневые сертификаты. Этот вариант отпал. Т.к. под раздачу попадали древние компьютеры с Windows XP, то пришлось протестировать несколько других различных способов. Оказалось, например, что certutil на разных версиях ОС имеет разные наборы ключей, и от этого варианта пришлось отказаться. Powershell подошел, но с оговоркой – пришлось тестировать под версией 2, которая работает на Windows XP. После танцев с бубном (как беден Powershell стрых версий!) скрипт был отлажен на тестовой машине. Для его исполнения решили использовать SCCM. Сделали приложение, сделали распространение на коллекцию пользователей и … началось – мониторинг закраснел ошибками выполнения скрипта. Причем код ошибки вообще ни о чём не говорил. В логах на клиенте информации тоже не больше (собственно те же неведомые коды). Пришлось подключиться к сессии пользователя удаленно, запустить командную строку, перейти в подпапку ccmcache, где лежало приложение и вручную запустить скрипт. Результат подивил:

File script.ps1 cannot be loaded because its operation is blocked by software restriction

policies, such as those created by using Group Policy…

Да — software restriction policies!!! Как внутри Powershell срабатывает SRP?! Включил логирование SRP – в логе всё чисто и прекрасно – никаких блокировок нет. Вот оно – чудо! J Скопировали скрипт из подпапки ccmcache в произвольную папку – работает!!! Во истину чудо! Тут коллега предложил отключить на проблемном компьютере все GPO – и проблема исчезла – скрипт сработал из подпапки ccmcache!

Собственно, подозрения были только на одну политику, которая включала AppLocker в режиме аудита. Добавили эту политику – проблема появилась. Вы можете понять, как режим аудита AppLocker может приводить к активной блокировке скрипта в Powershell, который при этом пишет ошибку SRP?!

Т.к. на Windows XP скрипт отрабатывал прекрасно, как вы понимаете, а проблемы мы ловили на Windows 7, то мне пришла в голову мысль: а не запустить ли скрипт под второй версией Powershell? Запустил. Результат опять удивил: ошибка была, но другая!

AuthorizationManager check failed.

CategoryInfo: Not Specified: (:) [], ParentContainsErrorRecordException

FullyQualifiedErrorId: RuntimeException

Теперь AuthorizationManager. Уже лучше J. Поиск по этому кодовому слову привёл к объяснению проблемы. Оно столь прекрасно, что приведу цитату полностью:

We got a response from MS:

Cause

Unfortunately the issue is caused by a design limitation. For AppLocker to work the mechanisms (AiGetFullImagePath function) are querying the full path of the folder structure up to where the allowed for the user application or script is stored, thus breaking up with access denied inside an internal kernel function (GetFinalPathNameByHandleW) when the user does not have at least the desired read access at some point on the folder structure chain and because it is not directly denied by the AppLocker policy no error is presented directly on the screen and only in the event logs is logged.

Resolution

To resolve the issue the administrator must give the users at least the desired read permissions to user, who have to run these applications or scripts, for all the folder on the chain from the root of the partition up to the folder where the script or application resides.

Unfortunately this is not possible in the SCCM portion of our scenario because the CCM Executive is resetting the permissions for the users on the ccmcache folder, under which the scripts, which are being run in the user context, are stored and executed, thus presenting an issue for such scenarios.

Our SCCM product group has been informed of this behavior. This information is being discussed and reviewed for future updates. Unfortunately, I will not be able to give you any timeline for a patch resolving this scenario.

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

Тупик!

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

Обходной путь нашёлся. Не сразу, но нашёлся. Т.к. скрипт выполняется в контексте пользователя, то скопировать его в другое место мы не можем: системные папки недоступны, а пользовательские – как только будет включена политика активной блокировки вместо аудита для AppLocker, скрипт будет заблокирован – так и должно быть для пользователей. Тем не менее не всё так безнадёжно. Вместо запуска powershell.exe –File script.ps1, что у нас вызывало ошибку, можно выполнять powershell.exe –Command «команда». Вот только «команда» должна включать в себя всё содержимое файла скрипта. Легко! Делаем так «Get-Content .\import.ps1 | Invoke-Expression» и … обламываемся: Invoke-Expression понимает только строку, но не множество строк. Попробуем иначе: «$a = Get-Content .\import.ps1; $ExecutionContext.InvokeCommand.NewScriptBlock($a)» – и опять та же ошибка: множество строк не принимается в NewScriptBlock. Опять тупик! Тут поиск выдал ещё один способ: «$a =Get-Command .\import.ps1;Invoke-Command -ScriptBlock $a.ScriptBlock» – на тестовой машине сработало! Но на реальной с политикой аудита AppLocker в свойстве $a.ScriptBlock оказалось пусто! «Защита» и тут сработала! Тем не менее объект создался и в его свойстве ScriptContents было содержимое скрипта. И в одну строку! – значит преобразование в скрипт должно сработать. И оно срабатывает:

powershell -noprofile -command "$a =Get-Command .\import.ps1;$b=[scriptblock]::Create($a.ScriptContents);Invoke-Command -ScriptBlock $b"

Эту строку надо указать в SCCM в настройках развертывания приложения для запуска процесса установки.

Сам скрипт импорта сертификата Powershell — импорт сертификата.

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

Реклама

комментария 2

  1. Где скрипт раскатывания-то, Илья? :-)

  2. […] SCCM,Application,Powershell – software restriction policy […]

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: