Применение WMI для мониторинга AD

. Одним из важных аспектов подобного мониторинга является поиск изменений критических параметров Active Directory (AD). Это первая из двух статей серии, в которой будет показано, как применять возможности мониторинга, имеющиеся в Windows Management Instrumentation (WMI), для отслеживания изменений, вносимых в AD. В данной публикации будет рассказано, как можно отслеживать изменения в группах AD.

Провайдеры AD WMI

В состав операционной системы Windows 2000 Server и более поздних версий включены три провайдера AD WMI: Microsoft|DSLDAPClassProvider|V1.0, Microsoft|DSLDAPInstanceProvider|V1.0 и Microsoft|DSLDAPClassAssociationsProvider|V1.0. Эти провайдеры предоставляют WMI-клиентам (т.е. приложениям, использующим управляющую информацию WMI) доступ к AD. Клиентами WMI могут быть Windows Script Host (WSH), приложения Windows .NET Framework, системы управления уровня предприятия или любые другие COM-совместимые приложения. Три перечисленных выше провайдера WMI можно найти в пространстве имен rootdirectoryLDAP репозитария информационной модели CIM (Common Information Model).

Для работы с провайдерами AD WMI очень важно понимать схему AD, поскольку в данном случае WMI отражает логическую структуру этой схемы. Тем читателям, которые слабо представляют себе, что такое схема AD, рекомендую более подробно ознакомиться с вопросом, обратившись к статье «Займемся схемами AD» (http://old.osp.ru/win2000/worknt/90nt03.htm).

Первый из трех новых провайдеров WMI, Microsoft|DSLDAPClassProvider|V1.0, отображает классы AD, определенные в схеме AD, в соответствующие классы WMI. Данный компонент называется провайдером классов (class provider), поскольку он обеспечивает только предоставление классов для WMI. Второй провайдер, Microsoft|DSLDAPInstanceProvider|V1.0, отвечает за отображение экземпляров объектов AD. Экземпляр является актуальным представлением объекта, созданного в соответствии с критериями, определяемыми классом. Например, при создании в AD нового пользователя провайдер Microsoft|DSLDAPInstanceProvider|V1.0 отображает экземпляр этого пользователя на соответствующий экземпляр пользователя WMI. Таким образом, между двумя этими провайдерами WMI имеется четкое разграничение ролей: один из них отображает классы AD на классы WMI, а другой обеспечивает соответствие между экземплярами AD и экземплярами WMI. Отображение классов является динамическим процессом, это означает, что при каждом обращении клиента WMI к пространству имен rootdirectoryLDAP провайдер классов вновь динамически создает внутри этого пространства набор доступных классов. Таким образом, если вы расширяете схему AD, то результирующий набор новых классов будет автоматически отображен в пространстве имен rootdirectoryLDAP.

Третий из перечисленных выше провайдеров – Microsoft|DSLDAPClassAssociationsProvider|V1.0 – предназначен для отображения отношений, существующих между контейнерами AD (такими как контейнер домена или контейнер организационного подразделения (OU)) и объектами, содержащимися в этих контейнерах (ими могут быть такие объекты как OU, компьютеры, пользователи или группы). Аналогично тому, как связаны между собой провайдер классов и провайдер экземпляров, провайдер отношений связан с обоими этими провайдерами, поскольку он отображает отношения между экземплярами объектов. Все три провайдера функционируют как интерфейс между стандартами WMI и стандартами AD. Итак, мы выяснили назначение каждого из провайдеров, а теперь рассмотрим, как реализовано представление AD через WMI.

Что такое представление WMI AD

В ходе процесса отображения AD на WMI, который задает соответствие между классами и экземплярами AD и элементами пространства имен rootdirectoryLDAP репозитария CIM, провайдеры AD используют определенные правила именования для того, чтобы сохранить связи, существующие между классами и экземплярами AD. Рассмотрим, например, такой класс AD как User. В соответствии со схемой AD, класс AD User создается из иерархии классов, начиная с корневого класса, называемого Top, как показано на Рисунке 1. Для формирования класса User в схеме AD определяется несколько подклассов. Процесс создания подклассов называется образованием (derivation) классов, а родительский класс в этом случае называют суперклассом. Сначала из родительского класса Top формируется класс Person. Затем из класса Person создается класс organizationalPerson, из которого, в свою очередь, образуется класс Users. При этом каждый подкласс наследует от суперкласса соответствующий набор атрибутов AD.

Класс User определяется в AD как структурный, что позволяет создавать из него экземпляры пользовательских объектов. Однако классы Top, Person и organizationalPerson являются абстрактными; они могут использоваться только в качестве родительских шаблонов при создании соответствующих им подклассов, создавать экземпляры в абстрактных классах нельзя. Как отмечалось ранее, классы AD отображаются на равнозначные им классы в пространстве имен rootdirectoryLDAP. В случае абстрактного класса эквивалентный ему абстрактный класс WMI, будет всегда использовать в отображаемом LDAP-имени данного класса AD префикс ds_. Например, для класса AD с именем organizationalPerson эквивалентный класс WMI будет иметь имя ds_organizationalPerson. Поскольку этот класс AD является абстрактным, соответствующий класс WMI также будет абстрактным, и у него будет установлен квалификатор abstract. Квалификатор представляет собой атрибут определения класса WMI. Для просмотра квалификаторов можно воспользоваться программой WMI CIM Studio, доступной по адресу: http://download.microsoft.com/download/.netstandardserver/install/v1.1/nt5xp/en-us/wmitools.exe. Запустите программу, выберите класс, щелкните правой кнопкой в окне, отображающем свойства класса, и выберите пункт Object Qualifiers.

Если класс AD является структурным (например, класс User), то он будет отображаться на два класса WMI:

• Один класс с именем, начинающимся с префикса ads_, реализованный как абстрактный класс WMI (квалификатор abstract установлен). Например, класс User будет отображаться на абстрактный класс WMI ads_user.
• Один класс с именем, начинающимся с префикса ds_, реализованный как динамический класс экземпляров (dynamic instance class). Например, класс User будет отображаться на динамический класс WMI ds_user. Динамический класс имеет квалификатор provider, который определяет провайдера, поддерживающего данный класс (в нашем случае им является провайдер Microsoft|DSLDAPInstanceProvider|V1.0).

 

На Рисунке 2 представлены квалификаторы класса ads_user. Как можно заметить, наличие других квалификаторов, отображающих информацию AD, определяется в схеме и используется при создании определения класса user (например, governsID, lDAPDisplayName, objectClassCategory). Аналогичным образом, с помощью квалификаторов синтаксис AD отображается на синтаксис WMI. В таблице 1 показано отображение синтаксиса, а также то, как параметры AD при необходимости преобразуются в пригодные для использования в WMI величины. В результате, как показано на Рисунке 3, при использовании корректного синтаксиса и преобразований величин, WMI работает с классами и экземплярами AD так же, как с классами и экземплярами WMI. Единственным исключением является имеющийся в Active Directory объект RootDSE. LDAP-объект RootDSE доступен из любого экземпляра AD, представляемого WMI-классом RootDSE, поскольку между их именами имеется полное соответствие.

 

При создании объекта пользователя AD он всегда создается внутри какого-либо контейнера. По умолчанию для объектов этого типа служит контейнер Users, но вы можете использовать любой другой поддерживаемый контейнер, такой как OU или домен. В схеме AD контейнеры, которые могут содержать внутри себя пользовательские объекты, создаются с атрибутами possSuperiors и systemPossSuperiors в определении класса AD User. Данные атрибуты (используются их отображаемые LDAP имена) ссылаются на отображающие и поддерживаемые контейнеры класса AD. Например, в атрибуте systemPossSuperiors вместе с классом User можно найти класс domainDNS для контейнера Domain и класс builtinDomain для контейнера Builtin. Между классом User и поддерживаемыми контейнерами имеется связь, но поскольку в репозитории CIM никаких контейнеров нет, WMI отображает эти связи путем реализации ассоциаций. Ассоциация представляет собой связь, существующую между двумя или более классами, которая формируется путем создания экземпляра класса Association. Провайдеры AD WMI реализуют ее с помощью класса ассоциаций ds_LDAP_Class_Containment.

По завершении создания пользовательских объектов их экземпляры размещаются в существующем контейнере. При этом между объектами и их контейнерами существуют те же самые отношения, но уже на уровне экземпляров, а не классов. В WMI эти отношения на уровне экземпляров отображаются с помощью класса ассоциаций ds_LDAP_Instance_Containment.

Каждый экземпляр WMI, отображающий объект AD, использует путь ADSI (Active Directory Service Interfaces) к данному объекту. Путь ADSI отображается в определении класса WMI с помощью свойства ADSIPath. Например, для объекта с именем "LISSOIR Alain", размещенного в контейнере Users домена AD, имеющего имя LissWare.Net, свойство ADSIPath будет иметь следующее значение: LDAP://CN=LISSOIR Alain,CN=Users,DC=LissWare,DC=Net.

Все изложенное выше, относящееся к классу User и его WMI-эквивалентам, справедливо и для любого другого класса, определенного в схеме AD – логика везде одинакова. Теперь, когда вы получили представление о том, как классы и объекты представляются внутри WMI, давайте рассмотрим, как можно использовать WMI для получения информации и проведения мониторинга данных AD.

Отслеживание состава групп в AD

Всем известно, что контроль членства в группах AD является очень важной задачей. С точки зрения безопасности одни группы являются более критичными, чем другие. Например, администраторы не хотят постоянно следить за составом группы Enterprise Admins только для того, чтобы выявить, не добавился ли в нее новый член. В этом случае с помощью провайдера WMI AD и запроса события, написанного на языке WQL (WMI Query Language), можно организовать через WMI получение соответствующего уведомления, после того как в интересующую нас группу (например, в Enterprise Admins) были внесены какие-либо изменения. Подобным образом можно организовать наблюдение за любым объектом AD; все, что для этого нужно – выбрать класс WMI, соответствующий классу AD того объекта, состояние которого предполагается отслеживать. Отсюда становится понятно, почему так важно понимать механизм отображения AD на WMI.

В приведенном ниже фрагменте кода приведен пример простого запроса события на языке WQL, который можно использовать для наблюдения за группой Enterprise Admins в AD:

Select * From
  __InstanceModificationEvent
  Within 10
  Where TargetInstance ISA
  'ds_group' AND
  TargetInstance.ds_name=
  'Enterprise Admins'

Показанный выше WQL-запрос требует не позже, чем через 10 секунд, выслать уведомление о любых изменениях, внесенных в экземпляр группы Enterprise Admins. Этот запрос используется в разработанном мною сценарии, предназначенном для мониторинга групп в Windows. Данный сценарий приведен в Листинге 1. В сценарии данный запрос используется совместно с параметрами командной строки, где определяется та группа, изменения в которой предполагается отслеживать. При приеме уведомления от WMI сценарий отсылает почтовое уведомление HTML. Этот сценарий – пример использования провайдеров AD WMI и возможностей мониторинга, имеющихся в WMI. Он должен запускаться в административном контексте безопасности, при этом названия групп, мониторинг которых предполагается осуществлять, должны быть перечислены в командной строке и разделяться пробелами. Синтаксис запуска выглядит так:

GroupMonitor.wsf "GroupName1"
 ["GroupName2"] ["GroupNameN"]
 [/Machine:value] [/User:value]
 [/Password:value]

Здесь параметры GroupName1 – GroupNameN определяют список групп, подлежащих мониторингу. Ключ /Machine описывает имя контроллера домена, к которому необходимо подключиться к WMI (по умолчанию используется значение localhost). Ключи /User и /Password задают, соответственно, имя и пароль того пользователя, от имени которого устанавливается WMI-соединение. Допустим, требуется организовать мониторинг групп Enterprise Admins и Domain Admins для DC с именем ServerA.LissWare.Net, тогда соответствующая команда запуска будет выглядеть следующим образом:

GroupMonitor.Wsf "Enterprise
  Admins" "Domain Admins"
  /Machine:"ServerA.LissWare.Net"

Здесь может использоваться любой сервер, который является частью леса AD. Таким образом, если мы выбираем DC, то изменение групп будет фиксироваться либо тогда, когда это имело место на данном сервере, либо тогда, когда изменения были внесены на другом контроллере, входящем в тот же домен, что и выбранный сервер при репликации данных на него. Для того чтобы определить, какой именно DC стал источником изменений групп, необходимо проанализировать репликацию метаданных AD, но, к сожалению, доступ к этой информации невозможно получить через WMI. Вообще говоря, данные об источнике изменений объектов AD могут предоставлять некоторые утилиты, например repadmin.exe (входит в состав пакета Windows Support Tools). Однако вопросы аудита метаданных AD выходят за рамки данной статьи, поэтому давайте вернемся к обсуждаемому примеру сценария и рассмотрим, как работает в нем интерфейс WMI.

Мониторинг групп с помощью сценария

Как показано во фрагменте с меткой A (Листинг 1), сценарий мониторинга изменений групп начинается с определения параметров командной строки. Далее подключаются несколько вспомогательных функций, которые выполняют некоторые специфические задачи в ходе выполнения сценария и вызываются по ссылкам, обозначенным меткой B. К ним относятся:

• Функция GenerateHTML(), которая формирует в HTML-виде представление данных, содержащихся в экземпляре объекта WMI.
• Функция PauseScript(), которая приостанавливает выполнение сценария, выводя на экран всплывающее сообщение.
• Функция SendMessage(), которая с помощью инструкций Collaboration Data Objects (CDO) формирует и отсылает SMTP-сообщение в заданный почтовый ящик.
• Функция TinyErrorHandler(), обрабатывающая ошибки выполнения сценария.

Далее (фрагмент с меткой С) создается несколько объектов WMI. С их помощью выполняется WMI-подключение к пространству имен rootdirectoryLDAP и формируется WQL-запрос для работы с событиями. По умолчанию сценарий создает из COM-объекта WMI SWbemDateTime объект objWMIdateTime. Этот COM-объект, который имеется только в ОС Windows Server 2003 и Windows XP, преобразует информацию о дате и времени из формата DMTF (Distributed Management Task Force) в читаемый строковый формат. Более подробное описание формата DTMF доступно по адресу: http://msdn.microsoft.com/library/en-us/wmisdk/wmi/date_and_time_format.asp. Поэтому, если предполагается запускать данный сценарий на системах Windows 2000, необходимо внести изменения в показанную ниже строку: