Abfragen von Änderungen mithilfe des DirSync-Steuerelements

  • Artikel

Das Active Directory Directory-Synchronisierungssteuerelement (DirSync) ist eine LDAP-Servererweiterung, die es einer Anwendung ermöglicht, eine Verzeichnispartition nach Objekten zu durchsuchen, die sich seit einem vorherigen Zustand geändert haben.

Verwenden Sie das DirSync-Steuerelement über ADSI, indem Sie die ADS_SEARCHPREF_DIRSYNC Sucheinstellung angeben, wenn Sie IDirectorySearch verwenden. Weitere Informationen und ein Codebeispiel finden Sie unter Beispielcode mit ADS_SEARCHPREF_DIRSYNC. Sie können auch eine DirSync-Suche mithilfe der LDAP-API ausführen. Im Folgenden wird die ADSI-Implementierung beschrieben, von der die meisten auch für die direkte Verwendung von LDAP gelten, außer wie am Ende dieses Themas erläutert.

Wenn Sie eine DirSync-Suche ausführen, übergeben Sie ein anbieterspezifisches Datenelement (Cookie), das den Verzeichnisstatus zum Zeitpunkt der vorherigen DirSync-Suche identifiziert. Bei der ersten Suche übergeben Sie ein NULL-Cookie, und die Suche gibt alle Objekte zurück, die dem Filter entsprechen. Die Suche gibt auch ein gültiges Cookie zurück. Speichern Sie das Cookie im selben Speicher, den Sie mit dem Active Directory-Server synchronisieren. Rufen Sie bei nachfolgenden Suchvorgängen das Cookie aus dem Speicher ab, und übergeben Sie es mit der Suchanforderung. Die Suchergebnisse enthalten jetzt nur die Objekte und Attribute, die sich seit dem vorherigen Zustand geändert haben, der durch das Cookie identifiziert wurde. Die Suche gibt auch ein neues Cookie zurück, das für die nächste Suche gespeichert werden soll.

In der folgenden Tabelle sind Suchparameter aufgeführt, die von der Clientsuchanforderung angegeben werden können.

Parameter BESCHREIBUNG
Basis der Suche Die Basis einer DirSync-Suche muss der Stamm einer Verzeichnispartition sein, wobei es sich um eine Domänenpartition, die Konfigurationspartition oder die Schemapartition handeln kann.
`Scope` Der Bereich einer DirSync-Suche muss ADS_SCOPE_SUBTREE sein, d. h. die gesamte Teilstruktur der Partition. Beachten Sie, dass die Unterstruktur für eine Suche nach einer Domänenpartition die Köpfe, aber nicht den Inhalt der Konfigurations- und Schemapartitionen enthält. Um Änderungen in einem kleineren Bereich abzufragen, verwenden Sie die USNChanged-Technik anstelle von DirSync.
Filter Sie können einen beliebigen gültigen Suchfilter angeben. Bei einer ersten Suche mit einem NULL-Cookie enthalten die Ergebnisse alle Objekte, die mit dem Filter übereinstimmen. Für nachfolgende Suchvorgänge mit einem gültigen Cookie enthalten die Suchergebnisse nur Daten für Objekte, die dem Filter entsprechen und sich seit dem vom Cookie angegebenen Zustand geändert haben. Weitere Informationen zu Suchfiltern finden Sie unter Erstellen eines Abfragefilters.
Attribute Sie können eine Liste von Attributen angeben, die bei einer Änderung zurückgegeben werden sollen. Für jedes Objekt enthalten die anfänglichen Ergebnisse alle angeforderten Attribute, die für das Objekt festgelegt sind. Nachfolgende Suchergebnisse enthalten nur die angegebenen Attribute, die sich geändert haben. Unveränderte Attribute sind nicht in den Suchergebnissen enthalten. In der ADSI-Implementierung enthalten die Suchergebnisse immer die objectGUID und instanceType jedes Objekts. Außerdem fungiert die angegebene Attributliste als zusätzlicher Filter: Die ersten Suchergebnisse enthalten nur Objekte, für die mindestens eines der angegebenen Attribute festgelegt ist. nachfolgende Suchvorgänge umfassen nur Objekte, für die mindestens ein Attribut geändert wurde (Werte, die hinzugefügt oder gelöscht wurden).

 

Beachten Sie außerdem Folgendes:

  • Bei inkrementellen Suchvorgängen empfiehlt es sich, an denselben Domänencontroller (DC) zu binden, der in der vorherigen Suche verwendet wurde, d. h. an den DC, der das Cookie generiert hat. Wenn derselbe DC nicht verfügbar ist, warten Sie entweder, bis er ist, oder binden Sie an einen neuen DC, und führen Sie eine vollständige Synchronisierung durch. Speichern Sie den DNS-Namen des DC im sekundären Speicher mit dem Cookie.

    Sie können ein von einem DC generiertes Cookie an einen anderen DC übergeben, der ein Replikat derselben Verzeichnispartition hostet. Es besteht keine Chance, dass ein Client Änderungen durch die Verwendung eines Cookies von einem DC auf einem anderen DC verpasst. Es ist jedoch möglich, dass die Suchergebnisse aus dem neuen DC gemeldete Änderungen durch den alten DC enthalten; in einigen Fällen gibt der neue DC möglicherweise alle Objekte und Attribute zurück, wie bei einer vollständigen Synchronisierung. Der Client sollte nur seine Datenbank mit den gemeldeten Suchergebnissen für einen bestimmten DirSync-Aufruf konsistent machen, d. h. alle inkrementellen Ergebnisse so behandeln, als ob sie der neueste Zustand wären. Es spielt keine Rolle, ob Sie die Änderung bereits gesehen haben oder sogar zu einem vorherigen Zustand zurückkehren, da wiederholte inkrementelle Synchronisierungen auf Konsistenz konvergieren.

  • Es ist auch möglich, dass der andere DC das vom ursprünglichen DC zurückgegebene Cookie ablehnt. Die Suche generiert einen LDAP-Fehler auf dem Server wie "0000203D: LdapErr: DSID-xxxxxxxx, kommentar: Fehlerverarbeitungssteuerung, Daten 0", und die Clientanwendung generiert möglicherweise einen Fehler wie "System.DirectoryServices.Protocols.DirectoryOperationException: Ein Protokollfehler aufgetreten". Dies kann beispielsweise vorkommen, wenn das Cookie älter ist und der interne Inhalt des Cookies sich bei der Verarbeitung durch einen LDAP-Server mit einer anderen Version von Windows unterscheiden soll. Das Cookie ist eine undurchsichtige Struktur und ist nicht garantiert, dass es für alle Windows-Betriebssystemversionen strukturell konsistent ist. Die Clientanwendung sollte diesen Fall behandeln und mit einer vollständigen Synchronisierung wiederholen, wenn dieser Fehler auftritt.

  • Wenn ein Objekt umbenannt oder verschoben wird, werden seine untergeordneten Objekte , falls vorhanden, nicht in den Suchergebnissen enthalten, auch wenn sich die namen der untergeordneten Objekte geändert haben. Wenn ein vererbbarer ACE in einem Objektsicherheitsdeskriptor geändert wird, werden die untergeordneten Objekte des Objekts nicht in die Suchergebnisse einbezogen, obwohl sich die Sicherheitsbeschreibungen der untergeordneten Objekte geändert haben.

  • Verwenden Sie das objectGUID-Attribut , um die nachverfolgten Objekte zu identifizieren. Die objectGUID jedes Objekts bleibt unverändert, unabhängig davon, wohin das Objekt innerhalb der Gesamtstruktur verschoben wird.

  • Beachten Sie, dass die Suchergebnisse einer DirSync-Suche den Zustand der Objekte auf einem Replikat der Verzeichnispartition zum Zeitpunkt der Suche angeben. Dies bedeutet, dass Änderungen, die an anderen DCs vorgenommen werden, nicht enthalten sind, wenn sie nicht in den Ziel-DC repliziert wurden. Dies bedeutet auch, dass sich die Attribute eines Objekts seit der vorherigen DirSync-Suche möglicherweise mehrmals geändert haben, aber die Suche zeigt nur den endgültigen Zustand an, nicht die Reihenfolge der Änderungen.

  • In der ADSI-Implementierung muss die Anwendung das Cookie als undurchsichtig behandeln und keine Annahmen über den internen organization oder Wert treffen.

  • Beachten Sie, dass der Client das Cookie, die Cookielänge und den DNS-Namen des DC im selben Speicher speichert, der die synchronisierten Objektdaten enthält. Dadurch wird sichergestellt, dass das Cookie und andere Parameter mit den Objektdaten synchronisiert bleiben, wenn der Speicher jemals aus einer Sicherung wiederhergestellt wird.

  • Zum Abrufen des parentGUID-Attributs , das für das DirSync-Steuerelement erstellt wird, ist es auch erforderlich, das name-Attribut anzufordern.

Um das DirSync-Steuerelement verwenden zu können, muss dem Aufrufer das Recht "Verzeichnis änderungen abrufen" im Stammverzeichnis der zu überwachenden Partition zugewiesen sein. Standardmäßig wird dieses Recht den Konten Administrator und LocalSystem auf Domänencontrollern zugewiesen. Der Aufrufer muss auch über das erweiterte Ds-Replication-Get-Changes-Steuerungsrecht verfügen. Weitere Informationen zum Implementieren eines Änderungsnachverfolgungsmechanismus für Anwendungen, die unter einem Konto ausgeführt werden müssen, das nicht über dieses Recht verfügt, finden Sie unter Abfragen nach Änderungen mithilfe von USNChanged. Weitere Informationen zu Berechtigungen finden Sie unter Berechtigungen.

Die ADS_SEARCHPREF_DIRSYNC Suchergebnisse enthalten automatisch gelöschte Objekte (Tombstones), die dem angegebenen Suchfilter entsprechen. Ein Suchfilter, der mit einem Objekt übereinstimmt, wenn es live ist, stimmt jedoch möglicherweise nicht mit dem Objekt überein, nachdem es gelöscht wurde. Dies liegt daran, dass Tombstones nur eine Teilmenge der Attribute beibehalten, die für das ursprüngliche Objekt vorhanden sind. Beispielsweise verwenden Sie in der Regel den folgenden Filter für Benutzerobjekte.

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

Das objectCategory-Attribut wird entfernt, wenn ein Objekt gelöscht wird, sodass der obige Filter nicht mit tombstone-Objekten übereinstimmt. Umgekehrt wird das objectClass-Attribut für Tombstone-Objekte beibehalten, sodass ein Filter von "(objectClass=user)" mit gelöschten Benutzerobjekten übereinstimmt.

Die Attributliste, die Sie mit einer DirSync-Suche angeben, fungiert auch als Filter. Suchergebnisse enthalten nur Objekte, für die sich mindestens eines der angegebenen Attribute seit der vorherigen DirSync-Suche geändert hat. Wenn die Attributliste keine Attribute enthält, die auf Tombstones beibehalten werden, enthalten die Suchergebnisse keine Grabsteine. Um dies zu behandeln, fordern Sie alle Attribute an, indem Sie eine NULL-Attributliste angeben. Oder Sie können das attribut isDeleted anfordern, das für alle Tombstones auf TRUE festgelegt ist. Tombstone-Attribute haben das 0x8 Bit im searchFlags-Attribut der attributSchema-Definition festgelegt.

Weitere Informationen finden Sie unter Abrufen gelöschter Objekte.

LDAP-Implementierung des DirSync-Steuerelements

Sie können auch eine DirSync-Suche ausführen, indem Sie die LDAP-API mit dem LDAP_SERVER_DIRSYNC_OID-Steuerelement verwenden. Wenn Sie die LDAP-API verwenden, geben Sie auch die steuerelemente LDAP_SERVER_EXTENDED_DN_OID und LDAP_SERVER_SHOW_DELETED_OID an. Das LDAP_SERVER_EXTENDED_DN_OID-Steuerelement bewirkt, dass eine LDAP-Suche eine erweiterte Form des distinguished Name zurückgibt, die die objectGUID und objectSID für Sicherheitsprinzipalobjekte wie Benutzer, Gruppen und Computer enthält. Das LDAP_SERVER_SHOW_DELETED_OID-Steuerelement bewirkt, dass die Suchergebnisse Daten für gelöschte Objekte enthalten. Beachten Sie, dass diese Steuerelemente automatisch in die ADSI-Implementierung einbezogen werden.