Как узнать, какой процент компьютеров подчиняется SRP?
Понедельник, 22 - Сентябрь - 2014 20 комментариев
Внедряя Software Restriction Policies (SRP) в очередной компании, регулярно требуется отвечать на вопрос «а как далеко мы продвинулись?» Работая со сравнительно разветвлённой структурой Active Directory, никогда не получится ответить «с наскоку», требуется некий механизм объективного контроля (назовём его SRP Compliance Report). У вас нет SCCM? Не беда, такой контроль можно осуществлять с помощью встроенного механизма Group Policy.
Наличие или отсутствие Политик ограничения программ (SRP) легко можно определить конфигурацией определённых значений в ключе реестра HKLM\Software\Policy\Microsoft\Windows\Safer\CodeIdentifiers:
- REG_DWORD DefaultLevel
- Значение 0x00000000 показывает, что задействованы «белые списки»;
- Значение 0x00040000 показывает, что задействованы «чёрные списки»;
- Отсутствие значения равнозначно отсутствию политик вообще;
- REG_DWORD TransparentEnabled
- Значение 0x00000002 показывает, что DLL-модули проверяются на соответствие политике;
- Значение 0x00000001 показывает, что DLL-модули не проверяются;
- REG_DWORD PolicyScope
- Значение 0x00000000 показывает, что действию политики подвержены все пользователи;
- Значение 0x00000001 показывает, что локальные администраторы не ограничиваются;
В относительно большой компании наверняка имеется несколько сотрудников технической поддержки и администраторов. Не все они будут готовы выполнять правила работы с политикой SRP, а кто-то вообще найдёт для себя наличие ограничений неприемлемым. Будучи зажатыми политикой, они могут изыскивать методы её обхода, либо вообще саботировать рабочий процесс. Поэтому я принял в качестве допустимого положение, когда полноценно политика внедряется только на серверах, а на большинстве рабочих станций администраторы могут работать без ограничений. Для себя я определил три уровня соответствия компьютера политике SRP:
- Полное соответствие. Политика работает в режиме «белых списков», включена проверка DLL-модулей, конфигурация применена на всех пользователей без исключения;
- Частичное соответствие. Политика работает в режиме «белых списков», включена проверка DLL-модулей, ограничения не распространяются на администраторов;
- Несоответствие. Любая комбинация параметров, не подпадающая под первые два пункта.
Сохранять отчёты соответствия можно в качестве файлов на файл-сервере. Для этого я создал специальную папку, например, \\FileServer\Data\Reports\SRP, в которую членам групп Domain Computers и Domain Controllers разрешил Запись:
Для проверки на соответствие удобно применять механизм Group Policy Preferences, заставляя его выполнять определённые действия при определённых условиях. В моём случае, на файл-сервере политика создаёт пустой файл с названием, состоящим из кода соответствия и имени компьютера:
Политика «Company Compliance Reports» подстыковывается на самый верхний уровень иерархии Active Directory таким образом, чтобы охватить учётные записи всех членов домена. Компьютеры будут обновлять свои отчёты в цикле применения Group Policy (по умолчанию — каждые полтора часа):
Остаётся только один неотрегулированный момент: как смена статуса компьютера будет отражаться в отчёте? Для этого нужно добавить ещё пару условий в политику:
- Если компьютер полностью соответствует политике (Fully Compliant)
- Создать файл Fully_Compliant_%ComputerName%
- Удалить файл Partially_Compliant_%ComputerName%
- Удалить файл Non-Compliant_%ComputerName%
- Если компьютер частично соответствует политике (Partially Compliant)
- Удалить файл Fully_Compliant_%ComputerName%
- Создать файл Partially_Compliant_%ComputerName%
- Удалить файл Non-Compliant_%ComputerName%
- Если компьютер не соответствует политике (Non-Compliant)
- Удалить файл Fully_Compliant_%ComputerName%
- Удалить файл Partially_Compliant_%ComputerName%
- Создать файл Non-Compliant_%ComputerName%
Как видно из снимка экрана, подобные отчёты соответствия можно делать не только для SRP, но и для определения наличия некоторых программ .)
Peter Gubarevich 
Уважаемый Пётр, а как быть с аудитом если политика распространяется на пользователей а не на компьютеры? Запись в регистр в этом случае пишется в раздел HKEY Current USER. У меня так и не вышло добиться создания файла Fully_Compliant. Всё время создавался файл non_compliant. Ка будто он не видит эти ключи в регистре. Но они то есть! Если смотреть на компьютере локально.
В политике я использую раздел User Configuration. Значит действие происходит из под пользователя, но хозяева файлов с названием non_compliant всё ровно компьютеры.
Dear Andrey,
Для себя я ставил задачу отслеживать только компьютеры, так как политику уровня пользователей не применяю. С другой стороны, для того, чтобы успешно задействовать политику пользователей, политика компьютера тоже должна быть включена и сконфигурирована. Если у вас такого нет, то политика пользователей полноценно не применяется. Это раз.
Второе: для службы клиента групповой политики ключ HKCU — это профиль SYSTEM. Возможно, поэтому детект не происходит так, как вы ожидали. Делайте для HKLM.
Спасибо за ответ.
Почему вы считаете что успешного задействования SRP обязательно настраивать политику компьютера?
Я к примеру сделал так: в политике уровня пользователей настроил SRP. В область распространение политики(Scope) добавил Domain Users. Для инженеров сделал специальных пользователей которые убраны из группы Domain Users. Тем самым эти пользователи не попадают под действие SRP и инженеры успешно ставят софт используя Run As.
Так как политика распространяется на пользователей а не на компьютер, соответствующие ключи появляются не в ветке HKLM а в ветке HKCU. Я это проверял.
Off topic.
То есть когда на компьютере запускается служба обработки политик то все действия происходят от пользователя SYSTEM? Как то странно. У меня к примеру есть политики для принудительного отображения иконки My Computer на рабочем столе. Я реализовал это через ключ в регистре. Политика применяется к группе пользователей, изменения естественно делаются в ветке user configuration а регистры меняются в ветке HKCU.
При включении пользовательской политики компьютерная неявно включается сама. И. если её не настраивать, мешает работе. Как мешает? Например, по умолчанию в ней включена обработка LNK-файлов. С одной стороны, это хорошо, ибо LNK тоже бывали зловредные. С другой стороны, тогда потребуется добавлять в политику пути вида %Desktop%\*.LNK: Unrestricted. Я предпочитаю убирать LNK из обработки вообще. Но для этого потребуется создать и компьютерную политику тоже!
Я бы реализовывал работу инженеров иначе. Они применяют RunAs для административных учётных записей? Тогда на рабочих станциях не ограничивайте администраторов вообще. Сильно проще работать получится, не нужно политику останавливать/запускать.
Нет, ну преференции исполняются от лица пользователя, это так. Я коллекционирую на файловом сервере файлы %ComputerName%_%UserName%.txt, это позволяет быстро находить имя рабочей станции, когда пользователь звонит «подключитесь, у меня тут непонятная табличка на экране». Но почему тогда не получается конкретно у вас, я не знаю, надо смотреть детально.
Вы говорите о том что политика SRP для компьютеров всё ровно включается. В голове у меня это как-то не укладывается. Как это можно проверить? В смысле включилась она или нет, как настроена и т.д. Обычно, как вы и учили, это видно через регистры. Но в моём случае в ветке HKLM эти ключи не присутствуют, что говорит о том что политика на уровне компьютера не включена.
Да, эти специальные пользователи для инженеров являются администраторами на компьютерах пользователей. Добавлены в группу Administrators. В то же время на них не действует политика SRP. Хотя если брать в расчёт ваше утверждение что на уровне компьютера SRP неявно включается сама, то на них SRP всё же действует. Правда не понимаю каким образом.
Возвращаясь к сабжу. В моём случае ключи отображающие настройки и состояние SRP расположены в ветке HKCU я это проверял. Может проблема заключается в том что сервис выполняющий обработку политик не имеет прав на просмотр этих ключей, тем самым скрипт который проверяет на наличие данных ключей не имея к ним доступа считает что их нету тем самым выполняются условия на создания файла с названием Тon_compliant. Честно говоря не представляю какие ещё могут быть причины.
Да, компьютерная политика неявно включается. Часть настроек SRP суммируется по всем политикам, часть — перезаписывается. Например, правила путей суммируются, а вот общие параметры — перезаписываются методом «кто последний, тот и прав» (LSDOU). Типичный пример граблей: если вы убирали .LNK из списка обрабатываемых расширений в пользовательской политике, компьютерная его неявно добавляет. И ярлыки блокируются. И администратор удивляется. Ощем, проверяйте внимательнее.
Для больших компаний, где за каждым администратором отдельно не побегаешь, но можешь выдать им две учётки (для обычной работы и административную), я сейчас применяю модель политики «блокируются только пользователи». Это существенно облегчает внедрение политики. Соответственно, в политике не нужно делать особых исключений (а тем более выводить кого-то из группы Domain Users) или путей.
Показывайте параметры, как ещё можно узнать, что там не так?
Всё таки как-то странно. Компьютерная политика неявно включается, но узнать мы этого не можем так как отсутствуют ключи в регистрах. Мы можем увидеть только последствия этого в виде блокировки например .LNK. Но а ка тогда вообще можно реализовать SRP основанную на пользовательских политиках, если компьютерная политика всегда будет мешать?
Про суммирование понятно.
Что вы подразумеваете под «блокируются только пользователи». SRP настроенный в ветке user configuration?
Как по другому дать инженерам права на установку софта? Раздать им флешки с reg файлами TurnOff_SRP TurnOn_SRP? Мне кажется гораздо целесообразнее делать следующим образом. Распространять на группу пользователей. Удобным считаю брать Domain Users так как по умолчанию туда добавляются все и не надо будет следить за принадлежностью к группе. Инженерам и админам делать две учётки. Одну из которых убирать из Domain Users и добавлять в локальную группу Administrators на компьютерах пользователей..
Параметры политики сбора информации:
1. Не проверял отсутствие ключей в реестре, так как всегда в первую очередь делаю компьютерную политику. Если нужно, пользовательская её расширит, добавляя дополнительные пути/хэши/сертификаты. Но не уменьшит. Считаю, Baseline по-любому следует реализовывать компьютерной политикой. Компьютер должен быть защищён по умолчанию, любые послабления добавляются, дополняя Baseline. По своей практике скажу, что могу иметь дополнительную политику для большого департамента, страны или дочерней компании, но она всё равно будет компьютерной. Её и дополняю согласно нуждам департамента. Возможно, это также связано с тем, что конфигурация пользователей присутствует только в доменах. Защищая домашний компьютер, по-любому придётся применить компьютерную конфигурацию. Ничего плохого в этом нет.
2. В базовой конфигурации SRP присутствует параметр Enforcement. Его вторая секция позволяет выбрать, будет ли политика действовать вообще на всех-всех-всех, либо только на стандартных пользователей. Для рабочих станций вполне можно выбрать «применяться только для стандартных пользователей». Этот параметр присутствует во обеих ветках. Но настройка Baseline на уровне компьютера позволит избежать многих костылей и нестандартных проблем.
3. Применение этого параметра даёт инженерам вполне логичные права на установку программ. Если они выполнят программу через RunAs или полностью зайдут Администратором, ограничений не будет. Из встроенной группы Domain Users убирать не требуется и не следует. А флешки у ИТ-персонала следует отобрать и заблокировать политиками.
Мой выбор на пользовательский SRP пал не случайно. Проблема была именно в области применения SRP(Enforcement). Изначально я тоже пытался настроить компьютерный SRP, но выяснилось что в понятии «All users except local administrators» , local administrators — это именно локальные пользователи созданные непосредственно на этих компьютерах. Доменные пользователи, добавленные на целевом ПК в группу локальных администраторов, продолжают находится в поле действии SRP. И не я один с этим столкнулся. Во многих форумах люди описывали эту проблему.
Например тут: https://social.technet.microsoft.com/Forums/windowsserver/en-US/d81d5b44-1809-4aad-954e-722c99d6bf26/srp-all-users-except-local-administrators-is-not-working?forum=winserverGP
Поправте меня если я не прав.
Это не так. У меня нигде так нет. Например, рижские ИТ-инженеры входят в доменную группу Workstation Admins Riga, которая политикой добавляется в локальную Administrators для рижских рабочих станций. И всё корректно отрабатывает.
Подозреваю, у вас включён UAC. Смело ликвидируйте.
Спасибо за наводку. Не знал про UAC. А какую конкретно опцию или несколько опций, нужно изменить в UAC чтобы SRP не действовал на локальных админов?
К слову UAC не так уж и бесполезен особенно если пользователь сидит не с правами админа(хотя если SRP распространять на всех пользователей то сидеть под правами админа пропадает всякий смысл). Как к примеру заставить Programms and Features запустится с правами адмиина если выключен UAC? Если убрать UAC полностью то инженеру придётся практически всегда перелогиниватся своей учёткой.
Я выключаю три опции:
— Detect application installation
— Run all Admins in approval mode <<< вот оно
— Virtualize File and Registry writes
Если Programs and Features — единственная причина, то пусть лучше перелогинивается. В этом случае, он будет вводить свой пароль за пределами территории стороннего пользователя, это хорошо. Для минимизации количества сценариев, когда требуется полностью логониться, старайтесь автоматизировать/скриптовать установку и ликвидацию программ. Число сценариев "если пользователь сидит с правами админа" должно быть сведено до нуля. Также напомню, что права администратора позволяют мгновенно отключить SRP, установить любую программу (в том числе руткит), выключить любой сервис и антивирус.
Всё же не совсем с вами соглашусь. Преимущество в пользовательском SRP есть.
Run all Admins in approval mode — очень удобная вещь. Которая позволяет не перелогиниваясь выполнять большинство админских и инженерских дел на компьютере пользователя. В купе с пользовательским SRP(Enforcement: All users), по той схеме что я описывал выше с распространением на Domain Users и исключением из неё отдельных учёток, получается довольно удобная схема. К тому же, наличие вторых учёток у админов и инженеров, которые имеют администраторские права на свои компы и компы пользователей и которые не попадают под действие SRP, позволяет им НЕ сидеть с правами админа на своих же компах использую свою основную учётку. Используя вторые учётки они делают всё что надо не перелогиниваясь. Это очень удобно и служит одним из мотиваторов перехода на такую схему работы.
У нас пока что не сильно распространена система удалённой установки/удаления софта. А также отсутствует централизованный патч-менеджмент. Ещё один плюс для использования выше описанной схемы.
Вы писали: «В этом случае, он будет вводить свой пароль за пределами территории стороннего пользователя, это хорошо.»
А что плохого в том чтобы делать это на территории пользователя?
Если таки вам удобно — не вопрос. Мне UAC доставляет сразу множество неудобств, поэтому так.
Рабочую среду пользователя (профиль) следует считать заведомо заражённой, а введение административного пароля — легко перехватываемым событием. Вообще, если пользователь обладает неограниченным физическим доступом к своей рабочей станции (может её раскрутить или загрузиться со своей флешки), то всю рабочую станцию следует считать поражённой и опасной.
Возвращаясь к сказанному вами выше: «С другой стороны, для того, чтобы успешно задействовать политику пользователей, политика компьютера тоже должна быть включена и сконфигурирована. Если у вас такого нет, то политика пользователей полноценно не применяется»
Получается что в моём случае SRP не применяется полноценно? В чём это выражается и как это можно проверить?
Выражается только в том, что она пересекается с неявно создаваемой дефолтной политикой компьютера. Пожелаете убрать, например, тип файла .MDB из обработки — не сможете, ибо неявная политика продолжит его применять. Больше проблем нет.
Таков мой практический опыт. Может, что-то неправильно применял, поэтому сфантазировал? Проверяйте.
Как то всё это странно. Убрал .EXE из SRP политики. Сделал проверку регистров на целевом компьютере. Параметр ExecutableTypes не содержал .EXE. И действительно, SRP продолжал блокировать .EXE файлы.
Как же тогда с .LNK? Из политики он естественно убран, и по этой же логике должен блокироваться мистическим компьютерным SRP, но этого не происходит. Уличная магия какая-то.
Не могу сказать. Дальше вникать в это не хотелось бы, ибо принял для себя другую модель.
Пётр что должно быть в Example.txt?
Ничего, ноль байт. Похоже, я забыл описать, как он создаётся.
На том компьютере, где он лежит, шедулится задача на исполнение каждые пять минут:
cmd.exe /c echo 2> D:\Reports\Template.txt
Путь уже подставите самостоятельно. А чтобы не копилось много старых файлов, шедулится скрипт на ежесуточное исполнение:
$RetentionDepth = 30
$DataFolder = D:\Reports\SRP
if (($RetentionDepth -ge 1) -and ($RetentionDepth -le 3650) -and (Test-Path $DataFolder)) {
$EventHorizon = (Get-Date).AddDays(-$RetentionDepth)
Get-ChildItem $DataFolder -recurse -force | ?{$_.LastWriteTime -lt $EventHorizon} | del -recurse -force
}