Introduction
Les objets stockés dans Active Directory peuvent devenir obsolètes, endommagés ou orphelins en raison de conflits de réplication.
Cet article se concentre sur les objets d’approbation qui peuvent être identifiés par le bit « INTERDOMAIN_TRUST_ACCOUNT » dans l’attribut userAccountControl . Pour plus d’informations sur ce bit, consultez userAccountControl Bits.
Symptômes
Les relations d’approbation sont représentées dans Active Directory par les éléments suivants :
-
Un compte d’utilisateur avec un caractère $ de fin.
-
Objet de domaine approuvé (TDO) stocké dans le conteneur système de la partition de répertoire de domaine.
La création d’approbations en double crée deux objets qui ont des noms de compte Sam (Security Account Manager) en double. Sur le deuxième objet, SAM résout le conflit en renommant l’objet $DUPLICATE-<Account RID>. L’objet dupliqué ne peut pas être supprimé et devient « orphelin ».
Remarque Un objet Active Directory est dit « orphelin » lorsqu’il représente un objet enfant actif stocké dans Active Directory dont le conteneur parent est manquant. Le terme est également parfois utilisé pour faire référence à un objet obsolète ou endommagé dans Active Directory qui ne peut pas être supprimé à l’aide d’un flux de travail normal.
Il existe deux principaux scénarios d’approbation obsolète :
-
Scénario 1 : Approuver l’utilisateur en état de conflit
Un utilisateur d’approbation peut devoir être supprimé dans les scénarios où il existe deux forêts et où une approbation a été précédemment créée entre des domaines dans ces forêts. Lorsque l’approbation a été créée pour la première fois, un problème a empêché la réplication. Un administrateur a peut-être transféré ou saisi le rôle FSMO (Flexible Single Master Operation ) du contrôleur de domaine principal (PDC) et créé à nouveau l’approbation sur un autre contrôleur de domaine (DC).
Plus tard, lorsque la réplication Active Directory sera rétablie, les deux utilisateurs d’approbation répliqueront vers le même contrôleur de domaine, ce qui provoquera un conflit de nommage. L’objet utilisateur de confiance se verra attribuer un DN de conflit (CNF) mangled ; par exemple:
CN=contoso$\0ACNF :a6e22a25-f60c-4f07-b629-64720c6d8b08,CN=Users,DC=northwindsales,DC=com
SamAccountName s’affiche également mangled :
$DUPLICATE-3159f
L’objet sans conflit de nom semble normal et fonctionne correctement. Il est possible de supprimer et de recréer l’approbation.
-
Scénario 2 : Approuver l’utilisateur orphelin
De même que dans le scénario 1, il peut être nécessaire de modifier ou de supprimer un utilisateur d’approbation si le partenaire d’approbation et d’approbation n’existe plus, mais que l’utilisateur d’approbation se trouve toujours dans la base de données Active Directory. En règle générale, le mot de passe de ces comptes est ancien, ce qui entraîne l’indicateur de ce compte par les outils d’analyse de la sécurité.
Messages d’erreur lorsqu’un administrateur tente de modifier les attributs d’une approbation
Il n’est pas possible de modifier les attributs de clé ou de supprimer l’objet utilisateur d’approbation orphelin. L’erreur suivante est donnée après la tentative de modification des attributs qui protègent l’objet :
|
Boîte de dialogue Erreur |
Message d’erreur |
 |
Échec de l’opération. Code d’erreur : 0x209a 0000209A : SvcErr : DSID-031A1021, problème 5003 (WILL_NOT_PERFORM), données 0 |
Lorsqu’un administrateur tente de supprimer l’objet, il échoue avec l’erreur 0x5, ce qui équivaut à « Accès refusé ». Ou l’objet d’approbation en conflit peut ne pas apparaître dans le composant logiciel enfichable « Domaines et approbations » Active Directory.
|
Boîte de dialogue Erreur |
Message d’erreur |
 |
Échec de l’opération. Code d’erreur : 0x5
|
Cause
Ce problème se produit car les objets d’approbation appartiennent au système et ne peuvent être modifiés ou supprimés que par les administrateurs qui utilisent la console MMC Domaines et approbations Active Directory. Cette fonctionnalité est par conception.
Résolution
Après avoir installé les mises à jour Windows du 14 mai 2024 sur des contrôleurs de domaine exécutant Windows Server 2019 ou une version ultérieure de Windows Server, il est désormais possible de supprimer les comptes d’approbation orphelins à l’aide de l’opération schemaUpgradeInProgress. Pour ce faire, procédez comme suit :
-
Identifiez un compte d’utilisateur d’approbation orphelin dans votre domaine. Par exemple, cette sortie de LDP.exe ; affiche un indicateur userAccountControl de 0x800 qui identifie l’utilisateur d’approbation :
Développement de la base ' CN=northwindsales$,CN=Users,DC=contoso,DC=com'...
Obtention de 1 entrée :
Dn : CN=northwindsales$,CN=Users,DC=contoso,DC=com
…primaryGroupID : 513 = ( GROUP_RID_USERS ) ;
pwdLastSet : 27/04/2013 10:03:05 PM Temps universel coordonné ;
sAMAccountName : NORTHWINDSALES$ ;
sAMAccountType : 805306370 = ( TRUST_ACCOUNT ) ;
userAccountControl : 0x820 = ( PASSWD_NOTREQD | INTERDOMAIN_TRUST_ACCOUNT )
;… -
Si nécessaire, ajoutez un compte d’administrateur de domaine à partir du domaine des comptes d’approbation obsolètes au groupe « Administrateurs de schéma » dans le domaine racine de la forêt. (Le compte utilisé pour la suppression doit avoir le droit d’accès au contrôle « Control-Schema-Master » à la racine du réplica NC de schéma et doit pouvoir se connecter au contrôleur de domaine qui détient le compte orphelin.)
-
Assurez-vous que les mises à jour Windows du 14 mai 2024 ou ultérieures sont installées sur un contrôleur de domaine accessible en écriture dans le domaine des comptes d’approbation obsolètes.
-
Connectez-vous à ce contrôleur de domaine avec un compte d’administrateur de schéma. Si vous avez ajouté un compte au groupe « Administrateurs de schéma » à l’étape 2, utilisez ce compte.
-
Préparez un fichier d’importation LDIFDE pour modifier SchemaUpgradeInProgress et supprimer l’objet.
Par exemple, le texte ci-dessous peut être collé dans un fichier d’importation LDIFDE pour supprimer l’objet identifié à l’étape 1 :Dn:
changetype : modifier
add : SchemaUpgradeInProgress
SchemaUpgradeInProgress : 1
-dn : CN=northwindsales$,CN=Users,DC=contoso,DC=com
changetype : deleteIndicateurs sur la syntaxe LDIFDE :
-
La ligne avec uniquement un trait d’union (« - ») est essentielle, car elle met fin à la série de modifications sous le type de modification « modify ».
-
La ligne vide après la ligne avec le trait d’union est également essentielle, car elle indique LDIFDE que toutes les modifications sur l’objet sont terminées et que les modifications doivent être validées.
-
-
Importez le fichier LDIFDE à l’aide de la syntaxe suivante :
ldifde /i /f nameOfLDIFFileCreatedInStep5.txt /j
Remarques
-
Le paramètre /i indique une opération d’importation.
-
Le paramètre /f suivi d’un nom de fichier indique le fichier contenant les modifications.
-
Le paramètre /j suivi d’un chemin de fichier journal écrit un ldif.log et un fichier ldif.err avec les résultats de la mise à jour, si la procédure a fonctionné et, si ce n’est pas le cas, l’erreur qui s’est produite pendant le mod.
-
Spécification d’un point (« . ») avec le paramètre /j, écrit les journaux dans le répertoire de travail actif.
-
-
Si nécessaire, supprimez l’administrateur de domaine précédemment ajouté à l’étape 2 du groupe « Administrateurs de schéma ».
