Не работают динамические правила Windows 10 AppLocker для групп пользователей
] Я пытаюсь создать правила динамической блокировки приложений с помощью AppLocker. настройка заключается в том, что у меня есть предопределенные правила AppLocker (например, Разрешить группе пользователей Windows 'Chrome' доступ к 'chrome.exe' (не фактическое имя группы или фактический путь)), а затем назначить пользователей группам при входе в систему с с помощью службы Windows.
Сначала это работало нормально, но через некоторое время прекратилось (сам AppLocker работал, но особые правила для групп пользователей не применялись - другими словами, все было заблокировано). Я протестировал все политики, объединенные с помощью командлетов PowerShell, и в соответствии с ними пользователю, принадлежащему к группе пользователей Chrome , должен быть разрешен доступ к chrome.exe , но на самом деле я бы заблокировал приложение
Затем я попытался создать пользовательское правило, разрешающее chrome.exe , которое работало нормально, и как только я удалил его (групповое правило все еще существует), меня снова заблокируют. Или даже просто изменив существующую политику группы пользователей, чтобы она указывала на конкретного пользователя, она заработала, а затем вернувшись обратно, чтобы указать, что группа пользователей больше не работает.
Забавный момент - после нескольких перезапусков виртуальной машины она снова заработала, а на следующий день, когда я захотел продемонстрировать ее коллеге, у меня снова возникла та же проблема, которая снова была решена путем многократных перезапусков виртуальной машины.
Очевидная возможная проблема может заключаться в том, действительно ли пользователь принадлежит к группе? и ответ - да: каждый раз, когда политика не работает, я заходил в lusrmgr и проверял это.
Для дополнительного контекста - виртуальная машина размещена в Azure, работает под управлением Windows 10 с несколькими сеансами 21H1, AppLocker настраивается на уровне локального компьютера (нет общедоменных политик или чего-либо в этом роде).
Причина, по которой это не удается, когда вы полагаетесь на автоматическое применение этого правила, заключается в том, что пользователи добавляются в группы после того, как они вошли в систему.
Когда вы добавляете пользователя в группу, его новое членство в группе не вступает в силу до следующего входа в систему (пока его учетная запись остается в этой группе). При входе в систему токен Kerberos пользователя создается на основе комбинации идентификатора безопасности его учетной записи и идентификаторов безопасности всех групп, в которые он входит. Всякий раз, когда для пользователя проверяются какие-либо групповые операции (ACL, политики AppLocker и т. Д.), Фактически проверяется их токен Kerberos.
Может быть несколько разных решений, в зависимости от множества факторов в вашей среде. Возможны два решения:
- Использование групп безопасности на основе домена для назначения пользователям доступа к приложениям. Они будут присутствовать до того, как они войдут в систему, и их токен Kerberos будет завершен. Это был бы гораздо лучший подход, чем «решение» ниже.
- Если вы не можете использовать доменные группы, вы можете запустить сценарий после того, как служба Windows добавит пользователя в группу. Чтобы вручную обновить токен Kerberos пользователя с изменениями членства в группах после входа в систему и без необходимости повторного выхода из системы / входа в систему, выполните команду
klist purge. Это заставит их токен Kerberos быть регенерирован, и затем он будет включать их новое членство в группе.На этом этапе ваши динамические политики AppLocker будут работать.
klist: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/klist