В нашей организации без тотального аудита изменений членства в группах 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 я не видел, по слухам он был таким же.