Änderungsbenachrichtigungen in Active Directory Domain Services

Active Directory Domain Services stellen einen Mechanismus bereit, mit dem sich eine Clientanwendung bei einem Domänencontroller registrieren kann, um Änderungsbenachrichtigungen zu empfangen. Dazu gibt der Client das LDAP-Änderungsbenachrichtigungssteuerelement in einem asynchronen LDAP-Suchvorgang an. Der Client gibt auch die folgenden Suchparameter an.

Parameter	BESCHREIBUNG
`Scope`	Geben Sie entweder LDAP_SCOPE_BASE an, um nur das Objekt zu überwachen, oder LDAP_SCOPE_ONELEVEL , um die unmittelbaren untergeordneten Elemente des Objekts zu überwachen, ohne das Objekt selbst einzuschliessen. Geben Sie keine LDAP_SCOPE_SUBTREE an. Obwohl der Unterstrukturbereich unterstützt wird, wenn das Basisobjekt der Stamm eines Benennungskontexts ist, kann sich seine Verwendung erheblich auf die Serverleistung auswirken, da jedes Mal, wenn ein Objekt im Namenskontext geändert wird, eine LDAP-Suchergebnismeldung generiert wird. Sie können keine LDAP_SCOPE_SUBTREE für eine beliebige Teilstruktur angeben.
Filter	Geben Sie einen Suchfilter von "(objectclass=*)" an. Dies bedeutet, dass Sie Benachrichtigungen über Änderungen an einem Beliebigen Objekt im angegebenen Bereich erhalten.
Attribute	Geben Sie eine Liste von Attributen an, die bei einer Änderung zurückgegeben werden sollen. Beachten Sie, dass Sie Benachrichtigungen erhalten, wenn ein Attribut geändert wird, nicht nur die angegebenen Attribute.

Sie können bis zu fünf Benachrichtigungsanforderungen für eine einzelne LDAP-Verbindung registrieren. Sie benötigen einen dedizierten Thread, der auf die Benachrichtigungen wartet und diese schnell verarbeitet. Wenn Sie die funktion ldap_search_ext aufrufen, um eine Benachrichtigungsanforderung zu registrieren, gibt die Funktion einen Nachrichtenbezeichner zurück, der diese Anforderung identifiziert. Anschließend verwenden Sie die funktion ldap_result , um auf Änderungsbenachrichtigungen zu warten. Wenn eine Änderung auftritt, sendet der Server Ihnen eine LDAP-Nachricht, die den Nachrichtenbezeichner für die Benachrichtigungsanforderung enthält, die die Benachrichtigung generiert hat. Dies führt dazu, dass die ldap_result-Funktion mit Suchergebnissen zurückgibt, die das geänderte Objekt identifizieren.

Die Clientanwendung muss den Anfangszustand des überwachten Objekts bestimmen. Dazu müssen Sie zuerst die Benachrichtigungsanforderung registrieren und dann den aktuellen Zustand lesen.

Die Clientanwendung muss auch die Ursache der Änderung ermitteln. Bei einer Suche auf Basisebene wird eine Benachrichtigung angezeigt, wenn sich attribute ändern oder wenn das Objekt gelöscht oder verschoben wird. Bei einer Suche auf einer Ebene wird eine Benachrichtigung angezeigt, wenn ein untergeordnetes Objekt erstellt, gelöscht, verschoben oder geändert wird. Beachten Sie, dass das Verschieben oder Umbenennen eines Objekts in der Hierarchie über einem Zielobjekt keine Benachrichtigung generiert, obwohl sich der distinguished Name des Ziels dadurch geändert hat. Wenn beispielsweise Änderungen an den untergeordneten Objekten in einem Container überwacht werden, erhalten Sie keine Benachrichtigungen, wenn der Container selbst verschoben oder umbenannt wird.

Wenn der Client die Suchergebnisse verarbeitet, kann er die funktion ldap_get_dn verwenden, um den distinguished Name des geänderten Objekts abzurufen. Verlassen Sie sich nicht auf differenzierte Namen, um die nachverfolgten Objekte zu identifizieren, da sich distinguished names ändern können. Fügen Sie stattdessen das objectGUID-Attribut in die Liste der abzurufenden Attribute ein. Die objectGUID jedes Objekts bleibt unabhängig davon, wohin das Objekt innerhalb der Enterprise-Gesamtstruktur verschoben wird, unverändert.

Wenn ein Objekt innerhalb des Suchbereichs gelöscht wird, erhält der Client eine Änderungsbenachrichtigung, und das isDeleted-Attribut des Objekts wird auf TRUE festgelegt. In diesem Fall melden die Suchergebnisse den neuen distinguished Name des Objekts im Container Gelöschte Objekte seiner Partition. Es ist nicht erforderlich, das Tombstone-Steuerelement (LDAP_SERVER_SHOW_DELETED_OID) anzugeben, um Benachrichtigungen über Objektlöschungen zu erhalten. Weitere Informationen finden Sie unter Abrufen gelöschter Objekte.

Wenn ein Client eine Benachrichtigungsanforderung registriert hat, empfängt der Client weiterhin Benachrichtigungen, bis die Verbindung unterbrochen wird oder der Client die Suche durch Aufrufen der ldap_abandon-Funktion abbricht. Wenn der Client oder Server die Verbindung trennt, z. B. wenn der Server ausfällt, wird die Benachrichtigungsanforderung beendet. Wenn der Client erneut eine Verbindung hergestellt hat, muss er sich erneut für Benachrichtigungen registrieren und dann den aktuellen Zustand der relevanten Objekte lesen, falls änderungen aufgetreten sind, während der Client getrennt wurde.

Der Client kann den Wert des uSNChanged-Attributs eines Objekts verwenden, um zu bestimmen, ob der aktuelle Zustand des Objekts auf dem Server die neuesten Änderungen widerspiegelt, die der Client empfangen hat. Das System erhöht das uSNChanged-Attribut eines Objekts, wenn das Objekt verschoben oder geändert wird. Wenn beispielsweise der Server ausfällt und die Verzeichnispartition aus einer Sicherung wiederhergestellt wird, spiegelt das Replikat eines Objekts des Servers möglicherweise keine Änderungen wider, die zuvor an den Client gemeldet wurden. In diesem Fall ist der uSNChanged-Wert auf dem Server niedriger als der vom Client gespeicherte Wert.

Weitere Informationen und ein Codebeispiel, das das LDAP-Änderungsbenachrichtigungssteuerelement in einem asynchronen LDAP-Suchvorgang verwendet, finden Sie unter Beispielcode für den Empfang von Änderungsbenachrichtigungen.

Weitere Informationen zur Verwendung des LDAP-Änderungsbenachrichtigungssteuerelements finden Sie unter Übersicht über Änderungsnachverfolgung Techniken.