Share via

Опрос изменений с помощью элемента управления DirSync

  • Статья

Элемент управления синхронизацией каталогов Active Directory (DirSync) — это расширение сервера LDAP, которое позволяет приложению выполнять поиск секции каталога для объектов, которые изменились с момента предыдущего состояния.

Используйте элемент управления DirSync через ADSI, указав предпочтения поиска ADS_SEARCHPREF_DIRSYNC при использовании IDirectorySearch. Дополнительные сведения и пример кода см. в разделе "Пример кода с помощью ADS_SEARCHPREF_DIRSYNC". Вы также можете выполнить поиск DirSync с помощью API LDAP. Ниже описана реализация ADSI, большинство из которых также относится к использованию ПРОТОКОЛА LDAP напрямую, за исключением того, что описано в конце этого раздела.

При выполнении поиска DirSync вы передаете элемент данных для конкретного поставщика (cookie), который определяет состояние каталога во время предыдущего поиска DirSync. Для первого поиска передается пустой файл cookie, а поиск возвращает все объекты, соответствующие фильтру. Поиск также возвращает допустимый файл cookie. Сохраните файл cookie в том же хранилище, которое выполняется синхронизация с сервером Active Directory. При последующих поисках получите файл cookie из хранилища и передайте его с запросом на поиск. Результаты поиска теперь включают только объекты и атрибуты, которые изменились с момента предыдущего состояния, определяемого файлом cookie. Поиск также возвращает новый файл cookie для хранения для следующего поиска.

В следующей таблице перечислены параметры поиска, которые может указывать запрос на поиск клиента.

Параметр Описание
База поиска База поиска DirSync должна быть корнем секции каталога, которая может быть секцией домена, секцией конфигурации или секцией схемы.
Область Область поиска DirSync должен быть ADS_SCOPE_SUBTREE, то есть весь поддерев секции. Помните, что для поиска секции домена поддерев содержит головы, но не содержимое секций конфигурации и схемы. Для опроса изменений в меньшей область используйте метод USNChanged вместо DirSync.
Фильтр Можно указать любой допустимый фильтр поиска. Для первоначального поиска с файлом cookie null результаты включают все объекты, соответствующие фильтру. Для последующих поисков с допустимым файлом cookie результаты поиска включают данные только для объектов, которые соответствуют фильтру и изменились после того, как состояние, указанное файлом cookie. Дополнительные сведения о фильтрах поиска см. в разделе "Создание фильтра запросов".
Атрибуты Вы можете указать список атрибутов, возвращаемых при изменении. Для каждого объекта начальные результаты включают все запрошенные атрибуты, заданные в объекте. Последующие результаты поиска включают только указанные атрибуты, которые изменились. Без изменений атрибуты не включаются в результаты поиска. В реализации ADSI результаты поиска всегда включают objectGUID и instanceType каждого объекта. Кроме того, указанный список атрибутов выступает в качестве дополнительного фильтра: начальные результаты поиска включают только объекты, имеющие по крайней мере один из указанных наборов атрибутов; последующие поиски включают только объекты, в которых изменено одно или несколько атрибутов (значения добавлены или удалены).

 

Кроме того, помните, что:

  • Для добавочного поиска рекомендуется привязать к одному контроллеру домена (DC), используемому в предыдущем поиске, то есть контроллеру домена, создавщему файл cookie. Если тот же контроллер домена недоступен, подождите, пока оно не будет, или привязать его к новому контроллеру домена и выполнить полную синхронизацию. Сохраните DNS-имя контроллера домена в дополнительном хранилище с помощью файла cookie.

    Файл cookie, созданный одним контроллером домена, можно передать другому контроллеру домена, в котором размещен реплика одного раздела каталога. Нет шансов, что клиент пропустит изменения с помощью файла cookie из одного контроллера домена на другом контроллере домена. Однако возможно, что результаты поиска из нового контроллера домена могут включать изменения старого контроллера домена; В некоторых случаях новый контроллер домена может возвращать все объекты и атрибуты, как с полной синхронизацией. Клиент должен просто сделать базу данных согласованной с отчетными результатами поиска для любого заданного вызова DirSync, то есть обрабатывать все добавочные результаты, как если бы они были последним состоянием. Это не имеет значения, если вы видели изменение до или даже вернелись к предыдущему состоянию, так как повторяющиеся добавочные синхронизации будут конвергироваться на согласованность.

  • Кроме того, другой контроллер домена отклоняет файл cookie, возвращенный из исходного контроллера домена. Поиск создает ошибку LDAP на сервере, например "0000203D: LdapErr: DSID-xxxxx, комментарий: элемент управления обработкой ошибок, данные 0", а клиентское приложение может создать ошибку, например System.DirectoryServices.Protocols.DirectoryOperationException: произошла ошибка протокола". Это может произойти, например, если файл cookie старше, а внутреннее содержимое файла cookie должно отличаться при обработке сервером LDAP под управлением другой версии Windows. Файл cookie является непрозрачной структурой и не гарантирует структурной согласованности всех версий ОС Windows. Клиентское приложение должно обработать этот случай и повторить попытку с полной синхронизацией, если эта ошибка обнаружена.

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

  • Используйте атрибут objectGUID для идентификации отслеживаемых объектов. ОбъектGUID каждого объекта остается неизменным независимо от места перемещения объекта в лесу.

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

  • В реализации ADSI приложение должно обрабатывать файл cookie как непрозрачный и не делать никаких предположений о своей внутренней организации или ценности.

  • Помните, что клиент хранит файлы cookie, длину файла cookie и DNS-имя контроллера домена в том же хранилище, которое содержит синхронизированные данные объекта. Это гарантирует, что файлы cookie и другие параметры остаются в синхронизации с данными объекта, если хранилище когда-либо восстанавливается из резервной копии.

  • Чтобы получить атрибут parentGUID, созданный для элемента управления DirSync, также необходимо запросить атрибут имени.

Чтобы использовать элемент управления DirSync, вызывающий объект должен иметь право на получение изменений каталога, назначенного корень отслеживаемой секции. По умолчанию это право назначается учетным записям Администратор istrator и LocalSystem на контроллерах домена. Вызывающий объект также должен иметь право на расширенный контроль доступа ds-Replication-Get-Changes . Дополнительные сведения о реализации механизма отслеживания изменений для приложений, которые должны выполняться под учетной записью, которая не имеет этого права, см. в разделе "Опрос изменений с помощью USNChanged". Дополнительные сведения о привилегиях см. в разделе "Привилегии".

Результаты поиска ADS_SEARCHPREF_DIRSYNC автоматически включают удаленные объекты (tombstones), соответствующие указанному фильтру поиска. Однако фильтр поиска, который будет соответствовать объекту в реальном времени, может не соответствовать объекту после удаления. Это связано с тем, что могилы сохраняют только подмножество атрибутов, присутствующих на исходном объекте. Например, обычно для пользовательских объектов используется следующий фильтр.

(&(objectClass=user)(objectCategory=person))

Атрибут objectCategory удаляется при удалении объекта, поэтому приведенный выше фильтр не будет соответствовать каким-либо объектам из камней. И наоборот, атрибут objectClass сохраняется в объектах tombstone, поэтому фильтр "(objectClass=user)" будет соответствовать удаленным пользовательским объектам.

Список атрибутов, указанный с помощью поиска DirSync, также выступает в качестве фильтра; Результаты поиска включают только объекты, в которых один или несколько указанных атрибутов изменились с момента предыдущего поиска DirSync. Если список атрибутов не содержит никаких атрибутов, которые хранятся на могилах, результаты поиска не будут включать насадки. Для этого запросите все атрибуты, указав список атрибутов NULL; или вы можете запросить атрибут isDeleted , присвойте значение TRUE для всех камней. Атрибуты Tombstone имеют 0x8 битовый набор в атрибуте searchFlags определения attributeSchema.

Дополнительные сведения см. в разделе "Извлечение удаленных объектов".

Реализация ldap элемента управления DirSync

Вы также можете выполнить поиск DirSync с помощью API LDAP с элементом управления LDAP_SERVER_DIRSYNC_OID . При использовании API LDAP также укажите элементы управления LDAP_SERVER_EXTENDED_DN_OID и LDAP_SERVER_SHOW_DELETED_OID . Элемент управления LDAP_SERVER_EXTENDED_DN_OID заставляет поиск LDAP возвращать расширенную форму различающегося имени, включающую объектGUID и objectSID для объектов субъекта безопасности, таких как пользователи, группы и компьютеры. Элемент управления LDAP_SERVER_SHOW_DELETED_OID приводит к тому, что результаты поиска включают данные для удаленных объектов. Помните, что эти элементы управления автоматически включены в реализацию ADSI.