Мониторинг изменений ролей

Практика мониторинга AD с использованием WMI

.

Получение информации о роли FSMO

Для обеспечения надежной работы сложных сетей архитекторами Windows было предусмотрено пять ролей, которые могут принять на себя один или несколько контроллеров домена AD. Логика и техника кодирования для мониторинга FSMO сходна с той, что использовалась для мониторинга групп AD; отличие заключается в том, что получить информацию о FSMO не так просто, как о группах AD. Для получения сведений о ролях FSMO необходимо опросить три контекста именования AD, а для этого требуется выполнить настройку WMI на уровне пространства имен rootdirectoryLDAP. Провайдер AD получает сведения из контекста именования по умолчанию, то есть контекста именования домена Windows, в котором размещен опрашиваемый контроллер домена. Вместе с тем, атрибуты, содержащие сведения о FSMO, распределены между тремя контекстами именования AD, так что для мониторинга всех трех ролей FSMO необходимо также обратиться к контекстам именования конфигурации и схемы.

В приведенной ниже таблице 1 перечислены роли FSMO, их размещение в контекстах именования и другая важная информация. Роли FSMO хранятся в различных классах объектов AD, WMI-формы которых приведены в столбце WMI Class таблицы 1. Роль FSMO всегда хранится в атрибуте fSMORoleOwner, которому соответствует свойство с названием ds_fSMORoleOwner. Для администраторов, предпочитающих применять ADSI (Active Directory Service Interfaces) вместо WMI, в статье TechNet (http://www.microsoft.com/technet/community/scriptcenter/compmgmt/scrcm24.mspx) представлен сценарий, иллюстрирующий использование ADSI для получения информации о ролях FSMO путем выполнения запроса к объектам LDAP, перечисленным в столбце «Имя DN» объекта AD в таблице 1. Приведенный в TechNet сценарий сначала определяет мастера схемы FSMO, затем мастера именования домена (Domain Naming Master), эмулятор PDC, затем мастера RID и, наконец, мастера инфраструктуры. При внимательном анализе кода сценария можно заметить, что все роли FSMO хранятся в атрибуте fSMORoleOwner, содержащем отличительное имя (DN) контроллера домена, выполняющего эти роли. Отличительное имя DN изменяется, когда кто-то передает роль FSMO другому контроллеру домена. Таким образом, для мониторинга изменения ролей FSMO достаточно отслеживать изменения DN, хранящиеся в атрибуте FSMORoleOwner. Вы можете получить ту же информацию, которую получает предлагаемый в TechNet сценарий, использующий для этого WMI. Таким образом, задача сводится к тому, чтобы получить доступ к контекстам именования конфигурации и схемы, которые содержат, соответственно, роль мастера именования домена (т.е. объект LDAP crossRefContainer) и роль мастера схемы Schema Master (объект LDAP dMD).

Чтобы с помощью WMI разрешить доступ к объекту LDAP crossRefContainer в контексте именования конфигурации и к объекту dMD LDAP в NC схемы, необходимо сначала создать в пространстве имен rootdirectoryLDAP экземпляры классов WMI DN_Class и DSClass_To_DNInstance. Класс DN_Class инкапсулирует DN контекста именования, который поддерживает роль FSMO. Класс DSClass_To_DNInstance ассоциируется с классом WMI, представляющим объект, который требуется найти в контексте именования AD с помощью экземпляра этого контекста.

Можно создать экземпляры этих классов, используя формат управляемых объектов MOF (Managed Object Format - встроенный формат файлов WMI для описания классов, экземпляров классов в репозитарии WMI). Пример такого файла MOF представлен в листинге 1. Как видно из фрагмента A, для обнаружения (доступа) к экземпляру WMI ds_crossRefContainer в контексте именования конфигурации, необходимо сначала создать экземпляр класса DN_Class, определяющий контекст именования, затем создать экземпляр класса DSClass_To_DNInstance и определить его свойства следующим образом:

• свойство DSClass представляет собой имя экземпляра класса ds_crossRefContainer
• свойство RootDNForSearchAndQuery представляет собой присвоенный путь WMI экземпляра WMI, представляющего NC конфигурации. Экземпляр, представляюший NC конфигурации создается на основе только что описанного класса DN_Class

Как видно из листинга 1, фрагмент B, для создания и инициализации файла MOF используется тот же процесс, что и для класса ds_dMD, экземпляр которого содержится в контексте именования схемы AD.

Чтобы выполнить мониторинг ролей FSMO, необходимо загрузить файл MOF в репозитарий Common Information Model (CIM) - это можно сделать с помощью утилиты WMI MofComp. MofComp выполняет синтаксический разбор содержащихся в файле MOF предложений и добавляет эти классы и экземпляры классов в репозитарий CIM. Для загрузки в репозитарий CIM кода, представленного в листинге 1, нужно выполнить следующую команду

MofComp ForestFSMO.mof

Обратите внимание, что при этом не требуется указывать в командной строке пространство имен WMI rootdirectoryLDAP для загрузки содержащихся в файле MOF описаний в нужное место репозитария CIM. Файл MOF явным образом определяет пространство имен в предложении #pragma namespace, так что указывать пространство имен в командной строке не требуется.

Я разработал сценарий мониторинга ролей FSMO, FSMOMonitor.wsf. В Листинге 2 представлены фрагменты сценария FSMOMonitor.wsf, в которых реализована логика мониторинга ролей FSMO в домене AD. Логика и структура кода, осуществляющего мониторинг, подобны тем, которые применялись для мониторинга групп, поэтому вместо повторения всех аспектов работы сценария здесь будут рассматриваться в основном различия в подходах.

Одним из основных отличий является число запросов событий, которые выдает сценарий. Вместо единственного запроса, который позволял получить всю необходимую информацию о группах, в сценарии FSMOMonitor.wsf выполняется пять запросов событий WQL для каждой из ролей FSMO. Все используемые запросы WQL имеют одинаковую структуру. Для обнаружения изменений, характеризующих смену роли FSMO, которые могут произойти с исследуемым объектом AD, запрос WQL сравнивает свойство текущего экземпляра объекта TargetInstance.DS_fSMORoleOwner с предыдущим сохраненным значением PreviousInstance.DS_fSMORoleOwner. Ниже приводится пять запросов WQL, которые используются для обнаружения смены ролей FSMO.

Роль PDC Emulator FSMO: Select * From __InstanceModificationEvent Within 10 Where TargetInstance ISA 'ds_domaindns' And PreviousInstance.DS_fSMORoleOwner <> TargetInstance.DS_fSMORoleOwner" Роль Infrastructure Master FSMO: Select * From __InstanceModificationEvent Within 10 Where TargetInstance ISA 'ds_infrastructureupdate' And PreviousInstance.DS_fSMORoleOwner <> TargetInstance.DS_fSMORoleOwner" Роль RID Master FSMO: Select * From __InstanceModificationEvent Within 10 Where TargetInstance ISA 'ds_ridmanager' And PreviousInstance.DS_fSMORoleOwner <> TargetInstance.DS_fSMORoleOwner" Роль Domain Naming Master FSMO: Select * From __InstanceModificationEvent Within 10 Where TargetInstance ISA 'ds_crossrefcontainer' And PreviousInstance.DS_fSMORoleOwner <> TargetInstance.DS_fSMORoleOwner" Роль Schema Master FSMO: Select * From __InstanceModificationEvent Within 10 Where TargetInstance ISA 'ds_dmd' And PreviousInstance.DS_fSMORoleOwner <> TargetInstance.DS_fSMORoleOwner"

После установки соединения WMI сценарий выполняет пять запросов событий WQL, которые представлены во фрагменте B листинга 2. Обратите внимание, что каждый из запросов использует объект контекста WMI, поскольку для обнаружения всех событий WMI применяется одна и та же процедура. Контекст сохраняется в созданных ранее объектах SWbemNamedValueSet, для каждой из пяти ролей FSMO создается собственный объект. Более подробные сведения об объекте SWbemNamedValueSet содержатся в статье базы знаний Microsoft MSDN, которую можно найти по ссылке http://msdn.microsoft.com/library/en-us/wmisdk/wmi/swbemnamedvalueset.asp. Перед выполнением запросов событий WQL в сценарии выполняется инициализация объектов SWbemNamedValueSet соответствующими ролям FSMO значениями. Процедура обработки событий WMI почти аналогична процедуре обработки изменений групп AD, за исключением того, что сначала для определения, к какой из рассматриваемых ролей FSMO относится событие, выполняется определение контекста WMI - этому в листинге 2 соответствует фрагмент кода С. Далее сценарий выводит сообщение о том, с которой из ролей FSMO произошли изменения.

От слов к делу

В этой статье было показано, как можно использовать три новых провайдера WMI для мониторинга AD и решения задач системного администрирования. Возможно, Microsoft добавит средства непосредственного мониторинга AD в будущих выпусках операционных систем, но на сегодня провайдеры WMI AD являются единственным способом решения этой задачи. Точно так же можно отслеживать создание и удаление учетных записей пользователей. С помощью этих технологий мониторинга AD можно, например, настроить среду Microsoft Exchange Server с двумя лесами таким образом, что в одном из лесов выполняется регистрация учетных записей пользователей, а в другом для зарегистрированного пользователя автоматически создается почтовый ящик. Далее можно настроить взаимодействие таким образом, чтобы при удалении пользовательской учетной записи в исходном лесу выполнялось автоматическое удаление почтового ящика. Эта задача потребует написания дополнительных сценариев WMI и ADSI, но рассмотренные сценарии мониторинга обеспечивают достаточную основу для разработки подобных административных сценариев.

---

Листинг 1. ForestFSMO.mof

#pragma namespace("\.Rootdirectoryldap")

BEGIN CALLOUT A
Instance of DN_Class
    {
    DN = "LDAP://CN=Configuration,DC= LissWare,DC=Net";
    };

Instance of DSClass_To_DNInstance
    {
    DSClass = "ds_crossRefContainer";
    RootDNForSearchAndQuery =
          "DN_Class.DN="LDAP://CN=Configuration,DC= LissWare,DC=Net"";
    };
END CALLOUT A

BEGIN CALLOUT B
Instance of DN_Class
   {
   DN = "LDAP://CN=Schema,CN=Configuration,DC= LissWare,DC=Net";
    };

Instance of DSClass_To_DNInstance
   {
   DSClass = "ds_dMD";
   RootDNForSearchAndQuery =
         "DN_Class.DN="LDAP://CN=Schema,CN=Configuration,DC=LissWare,DC=Net"";
   };
END CALLOUT B

---

Листинг 2. Извлечение из FSMOMonitor.wsf

  
BEGIN CALLOUT A