Comment résoudre les problèmes de migration inter-forêts sIDHistory avec ADMTv2

2025-01-15

Cet article explique comment résoudre les problèmes de migration sIDHistory inter-forêts avec l’outil de migration Active Directory version 2 (ADMTv2).

Numéro de la base de connaissances d’origine : 322970

Plus d’informations

Lorsque vous utilisez ADMTv2 pour migrer sIDHistory dans le cadre d’une migration d’utilisateurs ou de groupes inter-forêts, la configuration est requise avec les exigences de migration de base.

Par défaut, sIDHistory, password et objectGUID sont tous conservés pendant les migrations intra-forêt, mais ce n’est pas vrai pour le clonage inter-forêts.

Étant donné qu’il n’existe aucun contexte de sécurité intégré pour les opérations inter-forêts, vous devez prendre des mesures pour protéger la sécurité des opérations au-delà des limites de forêt.

Configuration

Les exigences de base pour les opérations de migration inter-forêts sont les suivantes :

Migration de compte d’utilisateur et de groupe basé sur l’Assistant sans sIDHistory

Le domaine source doit approuver le domaine cible.
Le compte d’utilisateur qui exécute ADMTv2 doit disposer de droits d’administrateur dans le domaine source.
Le compte d’utilisateur ADMT doit disposer d’autorisations déléguées pour créer des objets utilisateur ou de groupe dans le conteneur cible.
DNS (nom d’hôte) et résolution de noms NetBIOS entre les domaines doivent exister.

La migration sIDHistory nécessite les dépendances supplémentaires suivantes

Audit de réussite et d’échec de la gestion des comptes pour les domaines source et cible.
Les domaines sources appellent cet audit de gestion des utilisateurs et des groupes.
Groupe local vide dans le domaine source nommé {SourceNetBIOSDom}$$$.
La HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupportclé de Registre doit être définie sur 1 sur le contrôleur de domaine principal du domaine source.
Vous devez redémarrer le contrôleur de domaine principal du domaine source après la configuration du Registre.
La sécurité Windows nécessite des informations d’identification utilisateur avec le droit étendu migratesIDHistory délégué ou les droits d’administrateur dans le domaine cible. Vous ajoutez ces informations d’identification dans l’Assistant lorsque la migration sIDHistory est activée.

Pour déléguer le droit étendu MigrateSidHistory sur un contrôleur de domaine ou sur un ordinateur sur lequel le pack Outils d’administration Windows Server est installé, procédez comme suit :

Cliquez sur Démarrer, Outils d'administration, puis sur Utilisateurs et ordinateurs Active Directory.
Cliquez avec le bouton droit sur le nom du domaine à partir duquel vous souhaitez déléguer l’extension MigrateSidHistory, puis cliquez sur Déléguer le contrôle pour ouvrir la fenêtre De l’Assistant Délégation de contrôle.
Cliquez sur Suivant, cliquez sur Ajouter, entrez le nom de l’utilisateur ou du groupe que vous souhaitez ajouter dans la boîte de dialogue Sélectionner les utilisateurs, ordinateurs ou groupes, cliquez sur OK, puis sur Suivant.
Cliquez pour sélectionner l’option Créer une tâche personnalisée pour déléguer l’option, puis cliquez sur Suivant.
Assurez-vous que ce dossier, les objets existants dans ce dossier et la création de nouveaux objets dans cette option de dossier sont sélectionnés, puis cliquez sur Suivant.
Vérifiez que l’option Général est sélectionnée, cliquez sur Migrer l’historique des SID dans la liste Autorisations , puis cliquez sur Suivant.
Vérifiez que les informations sont correctes, puis cliquez sur Terminer.
- Aucun id sID à migrer n’existe dans la forêt cible, soit en tant que sID principal, soit en tant qu’attribut sIDHistory d’un autre objet.

Exigences supplémentaires pour la migration de sIDHistory avec les interfaces de ligne de commande ou de script

Lorsque vous démarrez une migration d’utilisateur ou de groupe avec la migration sIDHistory à partir de la ligne de commande ou d’un script, la commande ou le script doit être exécuté sur le contrôleur de domaine dans le domaine cible.
Le compte d’utilisateur qui exécute la migration doit disposer de droits d’administrateur dans les domaines source et cible.

Conditions spéciales pour l’Assistant Mappage de groupe et fusion

Si sIDHistory doit être migré pendant le mappage et la fusion de groupes, l’étendue des groupes sources doit correspondre à l’étendue du groupe cible.

Dépannage

L’étape la plus simple que vous pouvez utiliser pour résoudre les problèmes de migration sIDHistory inter-forêts consiste à utiliser l’Assistant Migration de compte d’utilisateur ou l’Assistant Migration de compte de groupe pour exécuter une migration en mode test.

Pendant la migration en mode test, ADMTv2 valide les dépendances suivantes :

Le groupe local {SourceNetBIOSDom}$$$ est créé.
TcpipClientSupport sur le contrôleur de domaine principal source ou l’émulateur de contrôleur de domaine principal est activé.
L’audit dans les deux domaines est activé.

Si vous le souhaitez, ADMT peut réparer l’une de ces dépendances qui ne sont pas définies. Pour réparer ou configurer ces paramètres, le compte utilisé pour exécuter ADMT doit disposer d’autorisations suffisantes dans chaque domaine respectif pour effectuer les tâches.

Seul l’Assistant effectue ces vérifications et corrections. Les interfaces de ligne de commande et de script n’effectuent pas ces vérifications et ne fonctionnent pas sans configuration correcte.

Messages d’erreur courants avec la migration sIDHistory inter-forêts

« Le handle n’est pas valide (code d’erreur = 6). »

Cette erreur indique un problème RPC où l’outil de migration ne peut pas se lier à un point de terminaison RPC sur le contrôleur de domaine principal source. Les causes possibles sont les suivantes :

TcpipClientSupport sur le contrôleur de domaine principal source ou l’émulateur de contrôleur de domaine principal n’a pas été activé.
Le contrôleur de domaine principal ou l’émulateur de contrôleur de domaine principal n’a pas été redémarré après la configuration de TcpipClientSupport.
La résolution de noms DNS ou NetBIOS ne fonctionne pas.

Impossible de vérifier l’audit et TcpipClientSupport sur les domaines. Ne sera pas en mesure de migrer sid’s. Le groupe local spécifié n’existe pas.

Cette erreur indique généralement qu’un utilisateur ou un groupe global ou universel avec le nom {SourceNetBIOSDom}$$$ existe déjà. ADMT crée généralement le groupe local de ce nom, mais il ne peut pas le faire si un principal de sécurité existe déjà avec le nom.

Impossible de vérifier l’audit et TcpipClientSupport sur les domaines. Ne sera pas en mesure de migrer sid’s. Accès refusé.

Cette erreur indique généralement que le compte d’utilisateur utilisé pour exécuter ADMT n’a pas suffisamment d’autorisations pour effectuer la migration dans un ou les deux domaines. Échec de la recherche de nom de domaine, rc=1332. Le mappage entre les noms de compte et les ID de sécurité n’a pas été effectué. Cette erreur dans le fichier Migration.log après une migration avec sIDHistory indique généralement que le domaine source a configuré des approbations qui n’existent pas sur le domaine cible. Pour résoudre ce problème, exécutez l’Assistant Migration d’approbation pour mapper les approbations dans le domaine source, puis répliquez les relations dans le domaine cible.

Informations supplémentaires sur sIDHistory

SIDHistory est un attribut à valeurs multiples des principaux de sécurité dans Active Directory qui peut contenir jusqu’à 850 valeurs. Pour assurer la compatibilité descendante avec les contrôleurs de domaine qui exécutent des versions antérieures de Windows, l’attribut sIDHistory est disponible uniquement dans les domaines qui fonctionnent au niveau fonctionnel de Windows.

Certains produits fournisseurs tiers permettent d’activer sIDHistory dans des domaines en mode mixte. Ces revendications ne représentent pas l’utilisation légitime des API publiques. Les administrateurs de domaine qui utilisent ces outils risquent de mettre leur déploiement Active Directory dans un état non pris en charge.

Pendant les migrations intra-forêts, LDAP_Rename est responsable du déplacement d’objets. En raison de cela, les objets migrés conservent des données d’identification importantes, notamment l’objetGUID et le mot de passe. Ce n’est pas le cas pour les migrations inter-forêts, qui appellent DSAddSidHistory pour remplir l’attribut dans le domaine cible. La migration de mot de passe peut être activée pour le clonage entre forêts, mais l’objetGUID est toujours perdu pendant ce type de migration.

Dans les deux cas, les objets migrés reçoivent un nouvel ID sID par le domaine cible. Le sID d’origine est ajouté à l’attribut sIDHistory de l’objet migré dans le nouveau domaine. Après cela, l’attribut sIDHistory peut ne pas être modifié ou supprimé à l’aide des outils d’administration Active Directory standard. Cela n’est pas autorisé, car l’attribut sIDHistory appartient au SAM. Il est possible d’effacer le sIDHistory à l’aide d’un script ou d’un outil interne Microsoft non public.

Notez que le sIDHistory est un outil transitionnel et n’est pas destiné à exister indéfiniment attaché aux principaux de sécurité. Bien que la migration de sIDHistory puisse considérablement faciliter et simplifier le processus de migration de domaine, il existe des ramifications de sécurité importantes qui doivent être prises en compte avant d’implémenter l’élément sIDHistory dans une entreprise de production.

Un jeton de sécurité Windows peut contenir un maximum de 1 023 SID, y compris sIDHistory et les ID de groupe. Kerberos est également limité, car Windows Kerberos a une mémoire tampon 73 sID. Cette taille peut être doublée par un changement de registre à l’échelle de l’entreprise. Le dépassement de ces limites enfreint la restriction MaxTokenSize et peut entraîner des résultats imprévisibles, notamment l’échec de l’authentification Kerberos et l’application erratique ou inexistante de stratégies. Pour éviter ces problèmes, utilisez la traduction de sécurité au lieu de sIDHistory comme solution à long terme pour maintenir l’accès aux ressources après une migration de domaine.