Audit Collector Service — проблемы с отчетом usage_-_sensitive_security_groups_changes

В нашей организации без тотального аудита изменений членства в группах Active Directory — как без рук. Так как мы используем ПО Microsoft, напрашивался выбор в качестве «аудитора» SCOM 2012 Audit Collector Service. Мы установили роль отчетов, подняли ACS и раскидали его «пересыльщиков» по контроллерам домена. Просмотрели отчет по изменению членства в группах (usage_-_sensitive_security_groups_changes) и ахнули:

В строке с «Member Added» корректно была указана группа и дата. А вот поля Changed By и Member User могут одновременно содержать логин оператора (администратора), могут логин пользователя, а могут только название домена. Мы сделали заявку в Microsoft о том, что отчет некорректный и получили следующий ответ: «В рамках компетенции Службы профессиональной технической поддержки могут разрешаться только проблемы «Break-Fix», связанные с продуктами Майкрософт (взаимодействие со сторонним ПО и оборудованием, вопросы «Advisory» и «How to» может быть рассмотрено только в рамках Премьер-поддержки или на ресурсе TechNet).» На возмущение и вопрос «а некорректный отчет это разве не поломка?», мне ответить не сумели.

И эти люди запрещают мне ковыряться в носу утверждают, что их техническая поддержка виртуальных сред на голову выше таковой от VMware. Ну-ну.

В адрес технической поддержки Microsoft было произнесено много непечатных слов, после чего мы решили разобраться в проблеме самостоятельно. Сразу скажу, что если бы не коллега с отличным знанием SQL, у меня ничего бы не вышло.

Мы посмотрели на отчет и выяснили, что данные он берет из представления dvAll5 в базе аудит-коллектора. Взглянув в представление, и сопоставив его с SQL-запросом отчета, мы нашли ошибку. В отчете пользователь Changed by и Member user брались из поля Primaryuser. Исправив для столбца Member user поле на Clientuser, мы получили другой отчет:

В поле Changed By имеется значение n/a, в поле Member User — пользователь-оператор. Кроме того, в одну группу мы добавляли трех пользователей, а отобразилась только одна запись. Причем этот косяк относится и к стандартному отчету usage_-_sensitive_security_groups_changes, так как SQL-запрос настроен на исключение повторяющихся событий.

Также я обратил внимание на строки «Group Changed». Найдя в журнале безопасности соответствующие события, я узнал, что при аудите групп AD создается два события: событие «Group Changed» и подробное событие с изменением. Зачем стандартный отчет собирает оба события и отражает их — мне также неведомо.

На время в формате AM/PM без 6-часового смещения тоже неудобно смотреть.

Сказав еще несколько непечатных слов, мы решили заняться тестированием. Как выяснилось, отчет берет данные из представления dvAll5, находящегося в базе аудит-коллектора. Соответственно, я взял список операций и их кодов отсюда и составил следующую таблицу для нового отчета:

* В данном поле хранится Distinguished Name пользователя (учетная запись, добавляемая в группу). Соответственно, перед выводом необходимо переработать данную строку.

Microsoft, это у меня одного так криво представление собирается, или ваши программисты накосячили?

Конец у сказки хороший: по данной таблице был сделан новый отчет, удовлетворяющий всем нашим требованиям.

Отчет со SCOM 2007 R2 я не видел, по слухам он был таким же.

Запись опубликована в рубрике Microsoft, SCOM, SQL. Добавьте в закладки постоянную ссылку.

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *