SCOM 2007 R2 - Аудит изменений доменных групп безопасности

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

Для решения этой задачи воспользуемся возможностями SCOM и на примере доменной группы “Domain Admins” создадим правила, которые будут отслеживать события, регистрируемые в журнале “Security” на контроллерах домена в момент добавления и удаления пользователей в эту доменную группу безопасности.

В консоли SCOM “Operations Console” перейдём на закладку “Authoring” и вызовем мастер создания правил через меню “Create a new rule…”

На шаге “Select a Rule Type” выберем “Alert Generating Rules” > “Event Based” > “NT Event Log (Alert)” и обязательно выберем Management Pack в котором будет создано это правило (по объективным причинам использовать “Default Management Pack” не рекомендуется)

На шаге “Rule Name and Description” введём имя нашего правила и при желании его краткое описание. Имя желательно вводить исходя из смыслового назначения правила так, чтобы в дальнейшем при необходимости это правило можно было легко найти среди более десятка тысяч других правил с помощью фильтра. В качестве объекта нацеливания “Rule Target” в данном случае можно будет выбрать предопределенный класс “Windows Domain Controller”, так как ловить события аудита доменных групп безопасности нам имеет смысл лишь на контроллерах домена. Правило оставляем включённым.

Если же у нас по какой-то причине существует потребность следить лишь за каким-то конкретным сервером, например просто рядовым сервером, то в качестве класса можно выбрать например “Windows Server Operating System” и правило создать выключенным, чтобы в последствии включить его только для этого конкретного сервера с помощью переопределения (Override).

На следующем шаге “Event Log Name” выбираем имя интересующего нас журнала “Security”

На шаге “Build Event Expression” нам нужно задать условия по которым мы будем отлавливать нужные нам события. В параметр “Event ID” введём идентификатор события. Наш пример подразумевает что в качестве контроллеров домена используются сервера с Windows Server 2008 R2 и поэтому в качестве идентификатора события, которое регистрируется в журнале безопасности в момент добавления учетной записи пользователя в доменную группу безопасности мы будем использовать – 4728. Вот пример данных доступных внутри самого события

Нужно учитывать, что событие с таким кодом регистрируется при изменении любой глобальной группы безопасности и поэтому нам нужно добавить условие, которое будет отбирать лишь те события, в которых в качестве третьего параметра присутствует название интересующей нас группы – “Domain Admins” 

В конечном итоге получится так:

Как мы видим на позапрошлом скриншоте в событии в параметре 5 хранится SID группы безопасности, членство которой изменилось … и я по началу, подумав что использовать маску SID предопределённых групп будет правильней, чем просто имя группы - пустился в упражнения с регулярными выражениями и подстановочными знаками, так как доподлинно известно что SID группы “Domain Admins” в любом домене имеет вид S-1-5-21-%ID домена%-512. С удивлением для себя обнаружил что разное обращение к параметрам события выдает разные результаты:

$Data/Params/Param[5]$ – возвращает имя а не оригинальное значение SID
$Data/EventData/DataItem/EventData/Data[5]$ – возвращает исходное значение SID

К сожалению мне так и не удалось постичь логику заполнения параметров Expression и заставить этот механизм работать так, чтобы в условии отбора участвовало не преобразованное значение имени группы а его SID да ещё чтобы всё это и укладывалось в какой-нибудь wildcard типа S-1-5-21-%-512… видимо я не так много выпил зелёного чая в позе лотоса как наверное это делали разработчики когда ваяли это “чудо”.

Идём далее…На шаге “Configure Alerts” задаём имя события которое будет появляться на консоли SCOM и с этим же заголовком мы будем получать оповещения например в почту. В описание включаем второй параметр события в виде $Data/Params/Param[2]$ который вернёт нам имя пользователя преобразованное из SID добавленного в группу безопасности а также третий параметр $Data/Params/Param[3]$ в котором будет название изменившейся группы…ну и добавляем параметр $Data/EventDescription$ который вернёт нам основное содержимое описания из тела события. Приоритет и вес алерта выставляем “по вкусу”.

На этом создание закончено. Перед тем как тестировать новое правило дождёмся когда на контроллерах домена в логе SCOM появятся события с кодом 1200, 1201 и 1210 говорящие о том, что новая версия MP с нашими изменениями получена и применилась к конфигурации.

После этого можно попробовать изменить состав группы доменных администраторов и убедиться в том что на SCOM регистрируется соответствующее уведомление. Например такой вот достаточно наглядный и информативный вид будет иметь письмо с уведомлением в нашем случае:

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

Дополнительные источники информации:

• Kevin Holman's System Center Blog > Authoring rules for Windows 2008 events, and how to cheat
• Kevin Holman's System Center Blog > Using Event Description as criteria for a rule
• Kevin Holman's System Center Blog > Using OpsMgr for intrusion detection and security hardening
• Jonathan Almquist on Operations Manager > Using Expressions and Wildcards to create groups, author rules and monitors, create console views and notification subscriptions, and in the Command Shell
• KB243330 - Well-known security identifiers in Windows operating systems