Interrogation des modifications à l’aide du contrôle DirSync
Le contrôle de synchronisation d’annuaires Active Directory (DirSync) est une extension de serveur LDAP qui permet à une application de rechercher dans une partition d’annuaire des objets qui ont changé depuis un état précédent.
Utilisez le contrôle DirSync via ADSI en spécifiant la préférence de recherche ADS_SEARCHPREF_DIRSYNC lors de l’utilisation de IDirectorySearch. Pour plus d’informations et un exemple de code, consultez Exemple de code à l’aide de ADS_SEARCHPREF_DIRSYNC. Vous pouvez également effectuer une recherche DirSync à l’aide de l’API LDAP. L’exemple suivant décrit l’implémentation d’ADSI, dont la plupart s’appliquent également à l’utilisation directe de LDAP, sauf comme indiqué à la fin de cette rubrique.
Lorsque vous effectuez une recherche DirSync, vous passez un élément de données spécifique au fournisseur (cookie) qui identifie l’état du répertoire au moment de la recherche DirSync précédente. Pour la première recherche, vous transmettez un cookie Null, et la recherche retourne tous les objets qui correspondent au filtre. La recherche retourne également un cookie valide. Stockez le cookie dans le même stockage que celui que vous synchronisez avec le serveur Active Directory. Lors des recherches suivantes, récupérez le cookie à partir du stockage et transmettez-le avec la demande de recherche. Les résultats de la recherche incluent désormais uniquement les objets et attributs qui ont changé depuis l’état précédent identifié par le cookie. La recherche retourne également un nouveau cookie à stocker pour la recherche suivante.
Le tableau suivant répertorie les paramètres de recherche que la demande de recherche du client peut spécifier.
| Paramètre | Description |
|---|---|
| Base de la recherche | La base d’une recherche DirSync doit être la racine d’une partition d’annuaire, qui peut être une partition de domaine, la partition de configuration ou la partition de schéma. |
| Étendue | L’étendue d’une recherche DirSync doit être ADS_SCOPE_SUBTREE, c’est-à-dire la sous-arborescence entière de la partition. N’oubliez pas que pour la recherche d’une partition de domaine, la sous-arborescence inclut les têtes, mais pas le contenu, des partitions de configuration et de schéma. Pour rechercher des modifications dans une étendue plus petite, utilisez la technique USNChanged au lieu de DirSync. |
| Filtrer | Vous pouvez spécifier n’importe quel filtre de recherche valide. Pour une recherche initiale avec un cookie Null, les résultats incluent tous les objets qui correspondent au filtre. Pour les recherches suivantes avec un cookie valide, les résultats de la recherche incluent uniquement des données pour les objets qui correspondent au filtre et qui ont changé depuis l’état indiqué par le cookie. Pour plus d’informations sur les filtres de recherche, consultez Création d’un filtre de requête. |
| Attributs | Vous pouvez spécifier une liste d’attributs à retourner lorsqu’une modification se produit. Pour chaque objet, les résultats initiaux incluent tous les attributs demandés définis sur l’objet . Les résultats de recherche suivants incluent uniquement les attributs spécifiés qui ont été modifiés. Les attributs inchangés ne sont pas inclus dans les résultats de la recherche. Dans l’implémentation ADSI, les résultats de la recherche incluent toujours objectGUID et instanceType de chaque objet. En outre, la liste d’attributs spécifiée agit comme un filtre supplémentaire : les résultats de la recherche initiale incluent uniquement les objets qui ont au moins l’un des attributs spécifiés définis ; Les recherches suivantes incluent uniquement les objets sur lesquels un ou plusieurs attributs ont été modifiés (valeurs ajoutées ou supprimées). |
Sachez également que :
Pour les recherches incrémentielles, la meilleure pratique consiste à lier au même contrôleur de domaine (DC) que celui utilisé dans la recherche précédente, c’est-à-dire au contrôleur de domaine qui a généré le cookie. Si le même contrôleur de domaine n’est pas disponible, attendez qu’il soit ou liez-le à un nouveau contrôleur de domaine et effectuez une synchronisation complète. Stockez le nom DNS du contrôleur de domaine dans le stockage secondaire avec le cookie.
Vous pouvez passer un cookie généré par un contrôleur de domaine à un autre contrôleur de domaine hébergeant un réplica de la même partition d’annuaire. Il n’y a aucune chance qu’un client rate des modifications à l’aide d’un cookie d’un contrôleur de domaine sur un autre contrôleur de domaine. Toutefois, il est possible que les résultats de recherche du nouveau contrôleur de domaine incluent des modifications signalées par l’ancien contrôleur de domaine ; dans certains cas, le nouveau contrôleur de domaine peut retourner tous les objets et attributs, comme avec une synchronisation complète. Le client doit simplement rendre sa base de données cohérente avec les résultats de recherche signalés pour tout appel DirSync donné, c’est-à-dire gérer tous les résultats incrémentiels comme s’il s’agissait de l’état le plus récent. Peu importe que vous ayez déjà vu la modification ou que vous reveniez à un état précédent, car les synchronisations incrémentielles répétées convergeront vers la cohérence.
Il est également possible que l’autre contrôleur de domaine rejette le cookie retourné par le contrôleur de domaine d’origine. La recherche génère une erreur LDAP sur le serveur comme « 0000203D : LdapErr : DSID-xxxxxxxxxx, comment : Contrôle de traitement des erreurs, données 0 », et l’application cliente peut générer une erreur telle que « System.DirectoryServices.Protocols.DirectoryOperationException : Une erreur de protocole s’est produite ». Cela peut se produire, par exemple, lorsque le cookie est plus ancien et que le contenu interne du cookie est censé être différent lorsqu’il est traité par un serveur LDAP exécutant une autre version de Windows. Le cookie est une structure opaque et il n’est pas garanti qu’il soit structurellement cohérent entre toutes les versions du système d’exploitation Windows. L’application cliente doit gérer ce cas et réessayer avec une synchronisation complète si cette erreur se produit.
Lorsqu’un objet est renommé ou déplacé, ses objets enfants, le cas échéant, ne sont pas inclus dans les résultats de la recherche, même si les noms uniques des objets enfants ont changé. De même, lorsqu’un ACE pouvant être hérité est modifié dans un descripteur de sécurité d’objet, les objets enfants de l’objet ne sont pas inclus dans les résultats de la recherche, même si les descripteurs de sécurité des objets enfants ont changé.
Utilisez l’attribut objectGUID pour identifier les objets suivis. L’objetGUID de chaque objet reste inchangé, quel que soit l’emplacement où l’objet est déplacé dans la forêt.
N’oubliez pas que les résultats d’une recherche DirSync indiquent l’état des objets sur un réplica de la partition d’annuaire au moment de la recherche. Cela signifie que les modifications apportées sur d’autres contrôleurs de domaine ne seront pas incluses si elles n’ont pas été répliquées sur le contrôleur de domaine cible. Cela signifie également que les attributs d’un objet peuvent avoir changé plusieurs fois depuis la recherche DirSync précédente, mais que la recherche affiche uniquement l’état final, pas la séquence de modifications.
Dans l’implémentation ADSI, l’application doit gérer le cookie comme opaque et ne pas faire d’hypothèses sur son organization interne ou sa valeur.
N’oubliez pas que le client stocke le cookie, la longueur du cookie et le nom DNS du contrôleur de domaine dans le même stockage que celui qui contient les données d’objet synchronisées. Cela garantit que le cookie et les autres paramètres restent synchronisés avec les données de l’objet si le stockage est restauré à partir d’une sauvegarde.
Pour récupérer l’attribut parentGUID , qui est construit pour le contrôle DirSync, il est également nécessaire de demander l’attribut name .
Pour utiliser le contrôle DirSync, le droit « obtenir les modifications du répertoire » doit être attribué à l’appelant à la racine de la partition surveillée. Par défaut, ce droit est affecté aux comptes Administrateur et LocalSystem sur les contrôleurs de domaine. L’appelant doit également disposer du droit d’accès de contrôle étendu DS-Replication-Get-Changes . Pour plus d’informations sur l’implémentation d’un mécanisme de suivi des modifications pour les applications qui doivent s’exécuter sous un compte qui n’a pas ce droit, consultez Interrogation des modifications à l’aide d’USNChanged. Pour plus d’informations sur les privilèges, consultez Privilèges.
Récupération d’objets supprimés avec une recherche DirSync
Les résultats de la recherche ADS_SEARCHPREF_DIRSYNC incluent automatiquement des objets supprimés (pierres tombstone) qui correspondent au filtre de recherche spécifié. Toutefois, un filtre de recherche qui correspondra à un objet lorsqu’il sera actif peut ne pas correspondre à l’objet après sa suppression. Cela est dû au fait que les pierres tombstone conservent uniquement un sous-ensemble des attributs présents sur l’objet d’origine. Par exemple, vous utilisez généralement le filtre suivant pour les objets utilisateur.
(&(objectClass=user)(objectCategory=person))
L’attribut objectCategory est supprimé lorsqu’un objet est supprimé, de sorte que le filtre ci-dessus ne correspond à aucun objet tombstone. À l’inverse, l’attribut objectClass étant conservé sur les objets tombstone, un filtre « (objectClass=user) » correspond aux objets utilisateur supprimés.
La liste d’attributs que vous spécifiez avec une recherche DirSync agit également comme un filtre ; Les résultats de la recherche incluent uniquement les objets sur lesquels un ou plusieurs attributs spécifiés ont été modifiés depuis la recherche DirSync précédente. Si la liste d’attributs n’inclut pas d’attributs conservés sur des pierres tombstone, les résultats de la recherche n’incluent pas de pierres tombales. Pour gérer ce problème, demandez tous les attributs en spécifiant une liste d’attributs null ; ou vous pouvez demander l’attribut isDeleted , défini sur TRUE sur toutes les pierres tombstone. Les attributs Tombstone ont le bit 0x8 défini dans l’attribut searchFlags de la définition attributeSchema .
Pour plus d’informations, consultez Récupération d’objets supprimés.
Implémentation LDAP du contrôle DirSync
Vous pouvez également effectuer une recherche DirSync à l’aide de l’API LDAP avec le contrôle LDAP_SERVER_DIRSYNC_OID . Si vous utilisez l’API LDAP, spécifiez également les contrôles LDAP_SERVER_EXTENDED_DN_OID et LDAP_SERVER_SHOW_DELETED_OID . Le contrôle LDAP_SERVER_EXTENDED_DN_OID entraîne une recherche LDAP pour renvoyer une forme étendue du nom unique qui inclut l’objetGUID et objectSID pour les objets de principal de sécurité tels que les utilisateurs, les groupes et les ordinateurs. Le contrôle LDAP_SERVER_SHOW_DELETED_OID entraîne l’inclure dans les résultats de la recherche des données pour les objets supprimés. N’oubliez pas que ces contrôles sont automatiquement inclus dans l’implémentation ADSI.