Опрос изменений с помощью контрола 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 одного контроллера домена на другом. Однако возможно, что результаты поиска из нового DC могут включать изменения, зарегистрированные старым DC. В некоторых случаях новый DC может возвращать все объекты и атрибуты, как при полной синхронизации. Клиент должен просто сделать базу данных согласованной с отчетными результатами поиска для любого заданного вызова DirSync, то есть обрабатывать все добавочные результаты, как если бы они были последним состоянием. Не имеет значения, видели ли вы изменения раньше или даже возвращаетесь к предыдущему состоянию, так как повторяющиеся постепенные синхронизации приведут к согласованности.
Возможно также, что другой контроллер домена отклонит файл cookie, возвращённый исходным контроллером домена. Поиск создает ошибку LDAP на сервере, такую как "0000203D: LdapErr: DSID-xxxxx, комментарий: ошибка при обработке элемента управления, данные 0", а клиентское приложение может выдать ошибку, такую как "System.DirectoryServices.Protocols.DirectoryOperationException: произошла ошибка протокола." Это может произойти, например, если файл cookie старше, и его внутреннее содержимое должно отличаться при обработке сервером LDAP, работающем на другой версии Windows. Файл cookie является непрозрачной структурой и не гарантирует структурной согласованности всех версий ОС Windows. Клиентское приложение должно обработать этот случай и повторить попытку с полной синхронизацией, если эта ошибка обнаружена.
При переименовании или перемещении объекта его дочерние объекты, если таковые имеются, не включаются в результаты поиска, даже если различающиеся имена дочерних объектов изменились. Аналогичным образом, когда наследуемый ACE изменяется в дескрипторе безопасности объекта, дочерние объекты объекта не включаются в результаты поиска, даже если дескрипторы безопасности дочерних объектов изменились.
Используйте атрибут objectGUID для идентификации отслеживаемых объектов. objectGUID каждого объекта остаются неизменными независимо от места перемещения объекта в лесу.
Помните, что результаты поиска DirSync указывают состояние объектов на реплике раздела каталога на момент поиска. Это означает, что изменения, внесенные на другие контроллеры домена, не будут включены, если они не были реплицированы в целевой контроллер домена. Это также означает, что атрибуты объекта могут измениться несколько раз после предыдущего поиска DirSync, но поиск будет отображать только окончательное состояние, а не последовательность изменений.
В реализации ADSI приложение должно обрабатывать файл cookie как непрозрачный и не делать никаких предположений о своей внутренней организации или ценности.
Помните, что клиент хранит файлы cookie, длину файла cookie и DNS-имя контроллера домена в том же хранилище, которое содержит синхронизированные данные объекта. Это гарантирует, что файлы cookie и другие параметры остаются в синхронизации с данными объекта, если хранилище когда-либо восстанавливается из резервной копии.
Чтобы получить атрибут parentGUID, созданный для контроля DirSync, также необходимо запросить атрибут name.
Чтобы использовать элемент управления DirSync, вызывающий объект должен иметь право 'получить изменения каталога', назначенное на корень наблюдаемого раздела. По умолчанию это право назначается учетным записям администратора и LocalSystem на контроллерах домена. Вызывающий объект также должен иметь право на доступ к DS-Replication-Get-Changes расширенному элементу управления. Дополнительные сведения о реализации механизма отслеживания изменений для приложений, которые должны выполняться под учетной записью, не обладающей этим правом, см. в разделе Опрос изменений с помощью USNChanged. Дополнительные сведения о привилегиях см. в Привилегии.
Получение удаленных объектов с помощью поиска DirSync
Результаты поиска ADS_SEARCHPREF_DIRSYNC автоматически включают удаленные объекты (гробницы), соответствующие указанному фильтру поиска. Однако фильтр поиска, который будет соответствовать объекту в реальном времени, может не соответствовать объекту после удаления. Это связано с тем, что могилы сохраняют только подмножество атрибутов, присутствующих на исходном объекте. Например, обычно для пользовательских объектов используется следующий фильтр.
(&(objectClass=user)(objectCategory=person))
Атрибут objectCategory удаляется при удалении объекта, поэтому приведенный выше фильтр не будет соответствовать каким-либо объектам tombstone. И наоборот, атрибут objectClass сохраняется на объектах tombstone, поэтому фильтр "(objectClass=user)" будет соответствовать удаленным пользовательским объектам.
Список атрибутов, указанный с помощью поиска DirSync, также выступает в качестве фильтра; Результаты поиска включают только объекты, в которых один или несколько указанных атрибутов изменились с момента предыдущего поиска DirSync. Если список атрибутов не содержит никаких атрибутов, которые хранятся на могилах, результаты поиска не будут включать насадки. Для этого запросите все атрибуты, указав список атрибутов NULL; или можно запросить атрибут isDeleted, чтобы задать значение TRUE на всех могилах. Атрибуты Tombstone имеют битовый набор 0x8 в атрибуте searchFlags определения атрибутаSchema.
Дополнительные сведения см. в разделе извлечение удаленных объектов.
Реализация 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 возвращать расширенную форму отличительного имени, включающую objectGUID и objectSID для объектов безопасности, таких как пользователи, группы и компьютеры. Элемент управления LDAP_SERVER_SHOW_DELETED_OID приводит к тому, что результаты поиска включают данные для удаленных объектов. Помните, что эти элементы управления автоматически включены в реализацию ADSI.