Как запустить PS скрипт средствами групповой политики?

Question

[shupike]

Нужно создать (пока отдельную) групповую политику для отдельных рабочих станций в домене, для простоты применил ее только к одному OU, в котором находится только один ноутбук. Нужно при запуске системы запускать PowerShell-скрипт. Сначала попробовал просто разместить скрипт на файловом сервере и дать ссылку на этот скрипт в Computer configuration->Policies->Windows Settings->Scripts (Startup/Shutdown). Но в этом случае просто ничего не происходит, но скрипт можно запустить вручную, Get-ExecutionPolicy в положении Unrestricted. Решил попробовать по-другому - копирую сначала скрипт в локальную папку на конечной рабочей станции: Computer configuration->Preferences->Windows Settings->Files, это работает, при включении ноутбука формируется локальная папка, туда копируется с сервера скрипт. Но по-прежнему не могу запустить скрипт средствами политики.

Comments

[сергей кузьмин]

от кого запускаться должен ? до или после или без интерактивной ?

[shupike]

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

[сергей кузьмин]

shupike, почитайте использует ли оно у вас там s4u.
эта мерзость может все испортить

[Alexey Dmitriev]

Для развертывания ПО есть родной функционал в GPO. Если чего-то нет в MSI, проще переупаковать в MSI

[Dewz]

shupike Вкладка "Безопасность" - "Прошедшие проверку": Чтение и выполнение + Чтение на файле.ps1 стоит?

[сергей кузьмин]

Alexey Dmitriev,
MSI это trutedinstaller это про ACL

S4U это другое это про логин токен https://k5wiki.kerberos.org/wiki/Projects/Services4User

Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol:

Collectively, these two extensions enable an application service to obtain a Kerberos service ticket on behalf of a user. The resulting service ticket can be used for:

The requesting service's own information.

Access control local to the service's machine, impersonating the user.

Requests to some other service, impersonating the user.

переведите если непонятно поарглийски - литературно это сказать трудно
https://learn.microsoft.com/ru-ru/openspecs/window...

думаю Token Impersonation не будет работать на удаленной ноде

[Alexey Dmitriev]

сергей кузьмин, мой комментарий был автору вопроса - как альтернатива повершелл скрипту для установки ПО

[сергей кузьмин]

Alexey Dmitriev, прошу прощения. пытался применить shock storytelling.

Шок-сторителлинг (shock storytelling) - это техника повествования, направленная на умышленное создание сильной эмоциональной реакции у читателя или зрителя, часто через изображение шокирующих или неожиданных событий, образов или деталей. Цель - вызвать удивление, возмущение, страх или другие сильные чувства, чтобы сделать историю более запоминающейся и воздействующей.

[shupike]

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

[shupike]

Dewz, да

[shupike]

В итоге все получилось- финальная версия вот так выглядит:
User configuration->Policies->Windows settings->Scripts (Logon/Logoff)->вкладка PowerShell scripts:
Script name: \\share.domain.ru\Scripts$\MyPSScript.ps 1
Script parameters: -Noninteractive -ExecutionPolicy Bypass -Noprofile

Это работает для любой доменной учетки, настроенной на рабочей станции, входящей в групповую политику (помещенной в соответствующий OU). Теперь бы еще дорисовать разовое распространение этой политики - чтобы после развертывания ПО через скрипт второй раз все это не происходило при входе в систему. Сам скрипт, к сожалению, не проверяет, установлено ли ПО на данной рабочей станции. Что самое простое можно придумать?

Answer 1

[Роман Безруков]

можно политикой создать Scheduled Task, в которой запускать ваш скрипт, попутно проверять какой-нибудь флаг (например, папку/файл, который создается после установки ПО), чтобы избежать лишних установок

Comments

[сергей кузьмин]

Роман Безруков как раз полнировщий то и может оказаться нерабочим из за Services4UserSelf Services4User2Proxy и его лечге сломать чем починить

[Роман Безруков]

сергей кузьмин, ну хз...мы не знаем наверняка и можем только гадать

[сергей кузьмин]

Роман Безруков это тонкое место - зависит от множества настроек любая неточность и все.
Bottom line
"red-flag for any principal-based automation on legacy Windows NT platforms."
many parts of the system (accounts, services, network settings, domain controllers) have to align

<Principals>
    <Principal id="Author">
      <UserId>S-1-5-20</UserId>
      <LogonType>S4U</LogonType>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>

Strict AD configuration: S4U requires precisely configured Service Principal Name (SPN) , account flags (TRUSTED_TO_AUTH_FOR_DELEGATION), and delegation ACLs—errors lead to authentication failures or broken automation pipelines
.

Service Ticket limits: Large Kerberos Privileged Attribute Certificates (due to many group memberships) can exceed token sizes, causing unexpected failures
.

Upset DC behavior: Recent Windows updates have altered Kerberos Key Distribution Center validations for S4U2Self/S4U2Proxy that may break apps until patched across DCs
.

Kerberos cryptotype and clock issues: Mismatched encryption support or unsynchronized clocks can make service tickets refuse to decrypt, halting automation

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

[shupike]

Прошу прощения, а как настроить в политике создание задачи в Task Scheduler? Это в каком разделе на уровне компьютера?

[Роман Безруков]

shupike, побуду Гуглом - например, тут

[shupike]

Прошу прощения - забегался. На чем остановился в итоге - решил загружать на конечную рабочую станцию нужный PowerShell-скрипт, в политике для этой станции создаю scheduled task на уровне пользователя, там в actions пишу разовый запуск powershell.exe и в качестве аргументов -Noninteractive -ExecutionPolicy Bypass –Noprofile -file C:\script\PSscript.ps1, condition ставлю на вход пользователя в систему. Это работает без вопросов. Но есть нюанс - сначала происходит аплоад скрипта на станцию, а потом сразу же вызывается планировщик с этой задачей. Если скрипта еще нет на месте, все остановится. Можно ли придумать условие выполнения задачи в планировщике, чтобы выполнялась проверка - на месте ли скрипт? Второй вариант - разместить скрипт прямо на контроллере домена в NETLOGON, указав на этот сетевой путь в планировщике задач. Но так не срабатывает - даже если попытаться вручную запустить скрипт из сетевого расположения. PowerShell запрашивает вариант запуска скрипта - не пойму, как разрешить все по умолчанию. Включил параметр в этой политике - Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell->Turn on script execution (Allow all scripts). Но все равно по сети скрипт не запускается из планировщика.

Answer 2

[MaxKozlov]

Читали ?
Script not running on startup for GPO

Ключевые моменты: "Forget about the Startup Script in "Computer Configuration" because the script you set there is executed by the System even before anyone is logged in."
то есть доступ к шаре должен быть у компа, а не юзера

ну и "Logon scripts don't run for five minutes after a user logs on to a Windows 8.1-based computer"
то есть минут через 5 только может запуститься.

Ну и эвент логи, обычно, отражают что происходит

Answer 3

[darkrin]

просто подпишите его делов-то, это и секурнее и проще