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

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

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

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

image

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

image

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

image

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

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

image

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

image

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

image

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

image

Как мы видим на позапрошлом скриншоте в событии в параметре 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$ который вернёт нам основное содержимое описания из тела события. Приоритет и вес алерта выставляем “по вкусу”.

image

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

image

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

image

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

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

Всего комментариев: 2 Комментировать

  1. Алексей Максимов /

    События регистрируемые при изменении доменной группы Administrators:

    A member was added to a security-enabled local group EventID# 4732
    A member was removed from a security-enabled local group EventID# 4733

  2. Александр /

    добрый день!
    А подскажите — в скоме установлен ACS который и так собирает все EVENT с Домен контроллеров. А как выудить инфу из ACS? например, чтоб приходило уведомление на почту по Event ID 4740?
    пробую через группы не получается.

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