Notifications de modification dans services de domaine Active Directory

services de domaine Active Directory fournir un mécanisme permettant à une application cliente de s’inscrire auprès d’un contrôleur de domaine pour recevoir des notifications de modification. Pour ce faire, le client spécifie le contrôle de notification de modification LDAP dans une opération de recherche LDAP asynchrone. Le client spécifie également les paramètres de recherche suivants.

Paramètre	Description
Étendue	Spécifiez LDAP_SCOPE_BASE pour surveiller uniquement l’objet, ou LDAP_SCOPE_ONELEVEL pour surveiller les enfants immédiats de l’objet, sans inclure l’objet lui-même. Ne spécifiez pas LDAP_SCOPE_SUBTREE. Bien que l’étendue de la sous-arborescence soit prise en charge si l’objet de base est la racine d’un contexte d’affectation de noms, son utilisation peut avoir un impact grave sur les performances du serveur, car elle génère un message de résultat de recherche LDAP chaque fois qu’un objet dans le contexte d’affectation de noms est modifié. Vous ne pouvez pas spécifier LDAP_SCOPE_SUBTREE pour une sous-arborescence arbitraire.
Filtrer	Spécifiez un filtre de recherche « (objectclass=*) », ce qui signifie que vous recevez des notifications pour les modifications apportées à n’importe quel objet dans l’étendue spécifiée.
Attributs	Spécifiez une liste d’attributs à retourner lorsqu’une modification se produit. N’oubliez pas que vous recevez des notifications quand un attribut est modifié, pas seulement les attributs spécifiés.

Vous pouvez inscrire jusqu’à cinq demandes de notification sur une seule connexion LDAP. Vous devez disposer d’un thread dédié qui attend les notifications et les traite rapidement. Lorsque vous appelez la fonction ldap_search_ext pour inscrire une demande de notification, la fonction retourne un identificateur de message qui identifie cette demande. Vous utilisez ensuite la fonction ldap_result pour attendre les notifications de modification. Lorsqu’une modification se produit, le serveur vous envoie un message LDAP qui contient l’identificateur de message pour la demande de notification qui a généré la notification. Cela entraîne le retour de la fonction ldap_result avec des résultats de recherche qui identifient l’objet modifié.

L’application cliente doit déterminer l’état initial de l’objet surveillé. Pour ce faire, vous devez d’abord inscrire la demande de notification, puis lire l’état actuel.

L’application cliente doit également déterminer la cause de la modification. Pour une recherche de niveau de base, une notification se produit lorsqu’un attribut change, ou lorsque l’objet est supprimé ou déplacé. Pour une recherche à un niveau, une notification se produit lorsqu’un objet enfant est créé, supprimé, déplacé ou modifié. N’oubliez pas que le déplacement ou le renommage d’un objet dans la hiérarchie au-dessus d’un objet cible ne génère pas de notification même si le nom unique de la cible a changé en conséquence. Par exemple, si vous surveillez les modifications apportées aux objets enfants dans un conteneur, vous ne recevrez pas de notifications si le conteneur lui-même est déplacé ou renommé.

Lorsque le client traite les résultats de la recherche, il peut utiliser la fonction ldap_get_dn pour obtenir le nom unique de l’objet modifié. Ne vous fiez pas aux noms uniques pour identifier les objets suivis, car les noms uniques peuvent changer. Au lieu de cela, incluez l’attribut objectGUID dans la liste des attributs à récupérer. L’objetGUID de chaque objet reste inchangé quel que soit l’emplacement où l’objet est déplacé dans la forêt d’entreprise.

Si un objet dans l’étendue de recherche est supprimé, le client reçoit une notification de modification et l’attribut isDeleted de l’objet est défini sur TRUE. Dans ce cas, les résultats de la recherche indiquent le nouveau nom unique de l’objet dans le conteneur Objets supprimés de sa partition. Il n’est pas nécessaire de spécifier le contrôle tombstone (LDAP_SERVER_SHOW_DELETED_OID) pour recevoir des notifications de suppressions d’objets. Pour plus d’informations, consultez Récupération d’objets supprimés.

Lorsqu’un client a inscrit une demande de notification, le client continue de recevoir des notifications jusqu’à ce que la connexion soit interrompue ou que le client abandonne la recherche en appelant la fonction ldap_abandon. Si le client ou le serveur se déconnecte, par exemple, si le serveur échoue, la demande de notification est terminée. Lorsque le client se reconnecte, il doit s’inscrire à nouveau aux notifications, puis lire l’état actuel des objets d’intérêt en cas de modifications pendant la déconnexion du client.

Le client peut utiliser la valeur de l’attribut uSNChanged d’un objet pour déterminer si l’état actuel de l’objet sur le serveur reflète les dernières modifications que le client a reçues. Le système augmente l’attribut uSNChanged d’un objet lorsque l’objet est déplacé ou modifié. Par exemple, si le serveur échoue et que la partition d’annuaire est restaurée à partir d’une sauvegarde, la réplica du serveur d’un objet peut ne pas refléter les modifications précédemment signalées au client, auquel cas la valeur uSNChanged sur le serveur sera inférieure à la valeur stockée par le client.

Pour plus d’informations et un exemple de code qui utilise le contrôle de notification de modification LDAP dans une opération de recherche LDAP asynchrone, consultez Exemple de code pour la réception de notifications de modification.

Pour plus d’informations sur l’utilisation du contrôle de notification de modification LDAP, consultez Vue d’ensemble des techniques de Change Tracking.