Résoudre une erreur de OBJ_CLASS_VIOLATION dans Adamsync

Article
02/19/2024

Cet article explique comment résoudre une erreur de OBJ_CLASS_VIOLATION qui se produit lorsque vous utilisez l’outil Adamsync dans Windows Server.

S’applique à : Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 923835

Résumé

Cette erreur se produit en raison des différences de définition de classe entre le service d’annuaire Active Directory et le instance ADAM. Pour résoudre ce problème, suivez les étapes décrites dans les sections suivantes :

Déterminer l’attribut et la classe de l’objet
Étapes pour résoudre le problème lorsque les attributs appartiennent à la classe TOP
Étapes pour résoudre le problème lorsque les attributs n’appartiennent pas à la classe TOP

Symptômes

Vous essayez d’utiliser l’outil Adamsync.exe (Active Directory Application Mode) synchronisateur pour synchroniser les objets Active Directory avec un instance ADAM sur un serveur Windows Server. Toutefois, un message d’erreur semblable à ce qui suit est enregistré dans le fichier journal Adamsync :

Entrée de traitement : Page X, Frame X, Entrée X, Count X, USN X Entrée source de traitement
<guid=f9023a23e3a06d408f07a0d51c301f38> Traitement de l’entrée dans l’étendue
f9023a23e3a06d408f07a0d51c301f38. Ajout d’un objet cible
CN= TestGroup,OU= Accounts,dc= domain, dc= com. Ajout d’attributs : sourceobjectguid, objectClass, instanceType, displayName, info, adminDescription, displayNamePrintable, userAccountControl, codePage, countryCode, logonHours, primaryGroupID, comment, accountExpires, sAMAccountName, desktopProfile, legacyExchangeDN, userPrincipalName

Une erreur ldap s’est produite. ldap_add_sW : Violation de classe d’objet. Informations étendues : 0000207D : UpdErr : DSID-0315119D, problème 6002 (OBJ_CLASS_VIOLATION), données -2054643804

Cause

Ce problème se produit en raison des différences de définition de classe entre Active Directory et ADAM. Cette différence apparaît lorsque vous essayez de modifier un objet pour inclure un attribut qui n’est pas valide pour sa classe. Par exemple, l’attribut n’est pas défini dans le schéma ADAM, ou l’attribut est défini, mais l’attribut n’est pas présent dans la liste des attributs Obligatoires ou Facultatifs pour la classe spécifique. En règle générale, la deuxième situation est la cause la plus fréquente de ce problème.

La définition de classe de l’objet à synchroniser contient un ou plusieurs attributs dans Active Directory qui ne sont pas disponibles dans ADAM. La section « Ajout d’attributs » du message d’erreur mentionné dans la section « Symptômes » affiche les attributs que vous essayez d’ajouter. Ces attributs sont définis dans la liste des attributs facultatifs ou obligatoires pour la classe de l’objet en cours de synchronisation.

Par exemple, dans le message d’erreur mentionné dans la section « Symptômes », l’objet de référence est CN=TestGroup. Lorsque vous affichez l’objet CN=TestGroup dans Active Directory et que vous case activée la liste des attributs de cette classe et de toutes les classes parentes, vous voyez qu’un ou plusieurs attributs de cette liste ne figurent pas dans la liste des attributs obligatoires ou facultatifs activés pour cette classe dans ADAM.

Remarque

Cela inclut les listes d’attributs de toutes les classes parentes.

Résolution

Pour résoudre ce problème, procédez comme suit.

Déterminer les attributs et la classe de l’objet

Vérifiez la liste des attributs ajoutés à l’objet qui a échoué. Vous pouvez déterminer l’objet qui a échoué en affichant le message d’erreur dans le journal de synchronisation. L’objet ayant échoué est toujours le dernier objet indiqué à la fin du journal de synchronisation juste avant le message d’erreur. Par exemple, l’objet CN=TestGroup a échoué dans le message d’erreur mentionné dans la section « Symptômes ».
Déterminez si les attributs DisplayNamePrintable, Flags ou ExtensionName sont inclus dans le message d’erreur. Si l’un de ces attributs est inclus dans le message d’erreur, consultez la section « Étapes pour résoudre le problème lorsque les attributs appartiennent à la classe TOP ». Si aucun attribut n’est inclus dans le message d’erreur, consultez la section « Étapes pour résoudre le problème lorsque les attributs n’appartiennent pas à la classe TOP ».

Étapes pour résoudre le problème lorsque les attributs appartiennent à la classe TOP

Vous constaterez que la classe TOP dans le schéma Active Directory contient l’attribut DisplayNamePrintable, Flags ou ExtensionName. Toutefois, ces attributs ne sont pas contenus dans la classe TOP dans ADAM. Toutefois, vous ne pouvez pas modifier la classe TOP dans ADAM. Par conséquent, utilisez l’une des méthodes suivantes pour résoudre le problème :

Excluez ces attributs à l’aide de la <section exclude> dans le fichier de configuration XML.
À l’aide du schéma MMC, ajoutez manuellement ces attributs à la liste des attributs facultatifs pour la classe appropriée dans le schéma ADAM. Par exemple, dans le message d’erreur mentionné dans la section « Symptômes », l’objet défaillant est de la classe Group. Par conséquent, vous devez ajouter ces attributs à la liste Attributs facultatifs pour la classe Group dans ADAM.

Étapes pour résoudre le problème lorsque les attributs n’appartiennent pas à la classe TOP

Dans ADSchemaAnalyzer, sous le menuOptions desoutils\, cliquez sur Mettre à jour avec des références aux éléments nouveaux et présents sous l’onglet Génération LDIF.
Utilisez le menu Fichier pour charger Active Directory comme schéma cible et ADAM comme schéma de base. Attendez que l’outil termine la comparaison des schémas.
Dans le menu Schéma , cliquez sur Marquer tous les éléments comme inclus.
Dans le menu Fichier , cliquez sur Créer un fichier LDIF pour créer un fichier LDF contenant les modifications.

Remarque

Si vous importez ce fichier LDF directement dans ADAM, les attributs nécessaires ne seront probablement pas ajoutés ou modifiés correctement.
Aucun message d’erreur n’est affiché. Consultez la section « Pourquoi vous ne pouvez pas importer le fichier LDF directement dans ADAM » pour obtenir une explication de la raison pour laquelle cela se produit. Dans ce cas, passez à l’étape 5 sans importer le fichier LDF.
Examinez le fichier LDF que vous avez créé à l’étape 4. Plus précisément, consultez la classe à l’origine du problème. Par exemple, affichez la classe Group. La section de cette classe contient la liste des attributs présents dans la liste des attributs obligatoires ou facultatifs pour cette classe dans Active Directory, mais qui sont manquants dans ADAM.
Recherchez l’attribut du problème dans le fichier LDF. Pour ce faire, examinez la section « #attributes » dans le fichier LDF. Les attributs qui ne sont pas importés restent dans cette section. En règle générale, l’attribut de problème est le seul attribut que vous trouvez dans la section « #attributes ». Si vous trouvez l’attribut de problème, passez à l’étape 8. Si vous ne trouvez pas l’attribut de problème, passez à l’étape 7.
Si l’attribut de problème n’est pas évident dans la section « #attributes » du fichier LDF, procédez comme suit pour rechercher l’attribut du problème :
1. Actuellement, toutes les modifications apportées à une classe se trouvent dans une section dans le fichier LDF. Il s’agit de la section « #Updating Present Elements ». Sous cette section, recherchez la section qui met à jour la classe qui rencontre le problème. Par exemple, si la classe Group est le problème, vous trouverez une section qui ressemble à ce qui suit :
  
  # Élément Update : group
  dn : cn=Group,cn=Schema,cn=Configuration,dc=X
  changetype : modifier
  add: mayContain
  # mayContain : adminCount
  mayContain : 1.2.840.113556.1.4.150
  # mayContain : controlAccessRights
  mayContain : 1.2.840.113556.1.4.200
  # mayContain : groupAttributes
  mayContain : 1.2.840.113556.1.4.152
  # mayContain : groupMembershipSAM
  mayContain : 1.2.840.113556.1.4.166
  -
  
  Remarque Certaines autres entrées qui peuvent se trouver ici ont été exclues de cet exemple.
  
  Dn:
  changetype : modifier
  add : schemaUpdateNow
  schemaUpdateNow : 1
2. Modifiez les entrées que vous avez localisées à l’étape 4a en divisant les entrées en un seul attribut par opération. Par exemple, modifiez les entrées de l’exemple de l’étape 7a en utilisant des entrées qui ressemblent à ce qui suit :
  
  # Élément Update : group
  dn : cn=Group,cn=Schema,cn=Configuration,dc=X
  changetype : modifier
  add: mayContain
  # mayContain : adminCount
  mayContain : 1.2.840.113556.1.4.150
  -
  
  # Élément Update : group
  dn : cn=Group,cn=Schema,cn=Configuration,dc=X
  changetype : modifier
  add: mayContain
  # mayContain : controlAccessRights
  mayContain : 1.2.840.113556.1.4.200
  -
  
  dn : cn=Group,cn=Schema,cn=Configuration,dc=X
  changetype : modifier
  add: mayContain
  # mayContain : groupAttributes
  mayContain : 1.2.840.113556.1.4.152
  -
  
  dn : cn=Group,cn=Schema,cn=Configuration,dc=X
  changetype : modifier
  add: mayContain
  # mayContain : groupMembershipSAM
  mayContain : 1.2.840.113556.1.4.166
  -
  
  Remarque Certaines autres entrées qui peuvent se trouver ici ont été exclues de cet exemple.
  
  Dn:
  changetype : modifier
  add : schemaUpdateNow
  schemaUpdateNow : 1
Enregistrez le fichier LDF.
Importez le fichier LDF dans le schéma ADAM à l’aide de la commande fournie au début du fichier LDF.
Affichez le rapport affiché par l’utilitaire Ldifde. Ldifde signale désormais les erreurs qui se produisent avec les attributs qui n’ont pas été importés. Les informations d’erreur ressemblent aux exemples d’informations suivants :
```
ldifde -i -u -f c:\data\problem\KBtest_modified.ldf -s localhost:50010 -j .-c "cn=Configuration,dc=X" #configurationNamingContext  
Connecting to "localhost:50010"
```
Connexion en tant qu’utilisateur actuel à l’aide de SSPI
Importation du répertoire à partir du fichier « c :\data\problem\KBtest_modified.ldf »
Chargement des entrées.
Ajouter une erreur à la ligne 15 : Déjà existant
L’erreur côté serveur est la suivante : 0x2071 Une tentative d’ajout d’un objet à l’objet a été effectuée
ectory avec un nom déjà utilisé.
L’erreur du serveur étendu est la suivante :
00002071 : UpdErr : DSID-0305030D, problème 6005 (ENTRY_EXISTS), données 0

Remarque

Recherchez l’attribut du problème dans le fichier LDF en affichant le numéro de ligne indiqué dans le rapport d’erreurs.
Utilisez ces informations d’erreur pour rechercher l’attribut du problème et résoudre le problème. Procédez comme suit pour essayer de résoudre le problème :
1. Recherchez l’attribut du problème dans le fichier LDF en affichant le numéro de ligne indiqué dans le rapport d’erreurs. L’attribut ayant échoué peut avoir un préfixe « DUP- » dans displayName.
2. Notez l’identificateur d’objet (OID) de l’attribut et recherchez cet identificateur d’objet dans ADAM.
3. Recherchez l’attribut dans ADAM qui a le même identificateur d’objet.
4. Comparez l’attribut dans ADAM et dans le fichier LDF pour trouver des différences. Par exemple, les attributs peuvent avoir un DisplayName différent, mais le même identificateur d’objet.
5. Déterminez l’attribut à conserver, puis corrigez l’autre attribut. Par exemple, vous pouvez supprimer l’entrée du fichier LDF ou corriger l’entrée d’attribut ADAM. Vous pouvez également exclure l’attribut de problème de la synchronisation à l’aide de la <section exclude> dans le fichier de configuration XML.
Une fois l’attribut de problème corrigé dans Active Directory ou dans le schéma ADAM, ou après la suppression de l’attribut du fichier LDF, importez à nouveau le fichier LDF modifié. L’opération d’importation doit maintenant réussir. Si le problème n’est pas résolu, un autre attribut peut être à l’origine du problème. Répétez les étapes 10 à 12 jusqu’à ce que tous les attributs soient importés.

Journalisation des diagnostics

Lorsque vous trouvez l’attribut de problème, il peut ne pas être évident ce qui ne va pas. Par exemple, vous ne trouverez peut-être pas un identificateur d’objet en double ou un

entrée DisplayName différente. Lorsqu’un attribut de problème n’est pas importé, vous pouvez obtenir plus d’informations sur l’échec en activant la journalisation du débogage pour l’interface LDAP. Pour cela, procédez comme suit :

Pour obtenir plus d’informations sur l’échec de ldifde, activez la journalisation LDAP dans ADAM. Pour ce faire, remplacez la valeur de l’entrée de Registre des événements de l’interface LDAP de catégorie 16 par 5. Cette entrée de Registre se trouve sous la sous-clé de Registre suivante : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ADAM_instanceName\Diagnostics
Réimportez le fichier LDF.
Recherchez les erreurs dans le journal des événements.
Une fois la résolution des problèmes terminée, réinitialisez la valeur de l’entrée de Registre des événements de l’interface LDAP de catégorie 16 à 0. Sinon, le journal des événements sera inondé.

Contact Support Microsoft

Si le problème n’est pas résolu après avoir effectué les étapes décrites dans cet article, contactez Support Microsoft.

Statut

Ce comportement est inhérent au produit.

Plus d’informations

Pour synchroniser les données d’Active Directory avec ADAM à l’aide de l’outil Adamsync, procédez comme suit :

Cliquez sur Démarrer, pointez sur Tous les programmes, sur ADAM, puis cliquez sur Invite de commandes outils ADAM.
À l’invite de commandes, tapez la commande suivante, puis appuyez sur ENTRÉE : adamsync /fs Server_Name : port_numbernom_configuration /log log_file_name.log

Pourquoi vous ne pouvez pas importer le fichier LDF directement dans ADAM

Si vous importez le fichier LDF que vous avez créé à l’étape 1 sous la section « Étapes de résolution du problème lorsque les attributs n’appartiennent pas à la classe TOP » dans ADAM, ces attributs ne sont toujours pas ajoutés à la liste d’attributs dans ADAM. Vous pouvez vérifier ce comportement en utilisant la console MMC du schéma ADAM ou ADSIEDIT pour examiner le schéma. Ce comportement se produit car l’opération d’importation Ldifde échoue en mode silencieux. Actuellement, Ldifde ne signale pas d’erreurs. Il échoue en mode silencieux en raison de la façon dont ADSchemaAnalyzer construit le fichier LDF. ADSchemaAnalyzer utilise les commandes ntdsschemaadd et ntdsSchemamodify . Ces commandes activent le contrôle LDAP permissif. Cela signifie que toute défaillance est silencieuse.

En outre, pour chaque classe, tous les attributs à ajouter à la liste Attributs facultatifs sont ajoutés en une seule opération d’ajout/modification. Par conséquent, en cas de problème lors de l’ajout de l’un des attributs, l’opération entière échoue et aucun attribut n’est ajouté dans la liste. Par conséquent, des étapes supplémentaires doivent être effectuées pour trouver l’attribut du problème.

En règle générale, la cause probable de l’échec est un identificateur d’objet en double d’un attribut ou une autre différence dans les définitions d’attribut dans Active Directory et ADAM. Cela signifie que les OID en double peuvent être manqués et qu’un attribut peut être considéré comme un nouvel attribut si le LDapDisplayName n’existe pas dans ADAM.