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

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

Lorsque vous utilisez ADMTv2 pour effectuer une migration de sIDHistory dans le cadre d'une migration de groupe ou d'utilisateur inter-forêts, une configuration est requise par les exigences de migration de base.

Par défaut, sIDHistory, le mot de passe et objectGUID sont tous conservés durant les migrations inter-forêts, mais cela n'est pas valable pour le clonage inter-forêts.

Étant donné qu'il n'y a aucun contexte de sécurité intégré pour les opérations inter-forêts, vous devez prendre des mesures afin de protéger la sécurité des opérations traversant les limites de forêts.

Configuration

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

Migration de compte de groupe et d'utilisateur de base basée sur l'Assistant sans sIDHistory

• Le domaine source doit approuver le domaine cible.
• Le domaine source doit exécuter Microsoft Windows NT 4.0 Service Pack 4 (SP4) ou version ultérieure.
• Le domaine cible doit être en mode natif Microsoft Windows 2000 ou version ultérieure.
• Le compte d'utilisateur qui exécute ADMTv2 doit avoir des droits d'administrateur dans le domaine source.
• Le compte d'utilisateur ADMT doit avoir des autorisations déléguées afin de créer des objets d'utilisateur ou de groupe dans le conteneur cible.
• La résolution de nom DNS (nom d'hôte) et NetBIOS entre les domaines doit exister.

La migration de sIDHistory requiert les dépendances supplémentaires suivantes

• Audit des succès et des échecs de gestion de compte pour les domaines source et cible.
• Les domaines sources Windows NT 4.0 appellent cet audit de gestion des groupes et des utilisateurs.
• Un groupe local vide dans le domaine source nommé {SourceNetBIOSDom}$$$.
• La clé de Registre HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport doit avoir la valeur 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.
• Si le domaine cible est un domaine Windows 2000, la sécurité Windows requiert des informations d'identification d'utilisateur avec des droits d'administrateur dans le domaine cible. Vous ajoutez ces informations d'identification dans l'Assistant lorsque la migration de sIDHistory est activée.
  
  Pour déléguer le droit étendu MigrateSidHistory sur un contrôleur de domaine Microsoft Windows Server ou sur un ordinateur sur lequel les outils d'administration de Windows Server 2003 sont installés, procédez comme suit :
  1. Cliquez sur Démarrer, sur Outils d'administration, puis sur Utilisateurs et ordinateurs Active Directory.
  2. Cliquez avec le bouton droit sur le nom du domaine à partir duquel vous voulez déléguer le droit étendu MigrateSidHistory, puis cliquez sur Délégation de contrôle pour ouvrir la fenêtre Assistant Délégation de contrôle.
  3. Cliquez sur Suivant, puis sur Ajouter, entrez le nom de l'utilisateur ou du groupe que vous voulez ajouter dans la boîte de dialogue Sélectionner les utilisateurs, les ordinateurs ou les groupes, cliquez sur OK, puis sur Suivant.
  4. Sélectionnez l'option Créer une tâche personnalisée à déléguer, puis cliquez sur Suivant.
  5. Assurez-vous que l'option De ce dossier et des objets qui s'y trouvent. Déléguer aussi la création de nouveaux objets dans ce dossier. est sélectionnée, puis cliquez sur Suivant.
  6. Assurez-vous que l'option Général est sélectionnée, cliquez sur Migrer l'historique SID dans la liste Autorisations, puis cliquez sur Suivant.
  7. Vérifiez que les informations sont correctes, puis cliquez sur Terminer.
• Si le domaine cible est un domaine Windows Server 2003, la sécurité Windows requiert des informations d'identification d'utilisateur avec le droit étendu MigratesIDHistory délégué ou les droits d'administrateur dans le domaine cible.
• Il ne peut exister aucun SID à migrer dans la forêt cible, ni comme SID principal, ni comme attribut sIDHistory d'un autre objet.

Exigences supplémentaires pour la migration de sIDHistory avec la ligne de commande ou des interfaces de scripts

• Lorsque vous démarrez une migration d'utilisateur ou de groupe avec la migration de 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 avoir des droits d'administrateur dans les domaines source et cible.

Exigences spéciales pour l'Assistant Mappage et fusion des groupes

• Si sIDHistory doit être migré pendant le mappage et la fusion des groupes, la portée des groupes sources doit correspondre à celle du groupe cible.

Résolution des problèmes

La mesure la plus simple que vous pouvez prendre pour résoudre les problèmes de migration de sIDHistory inter-forêts consiste à utiliser l'Assistant Migration des comptes d'utilisateurs ou l'Assistant Migration des comptes de groupes pour exécuter une migration en mode test.

Durant 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 est activé dans les deux domaines.

Éventuellement, ADMT peut réparer ces dépendances si elles ne sont pas définies. Pour réparer ou configurer ces paramètres, le compte qui est utilisé pour exécuter ADMT doit avoir suffisamment d'autorisations dans chaque domaine pour effectuer les tâches.

Notez que seul l'Assistant exécute ces vérifications et corrections. La ligne de commande et les interfaces de scripts n'exécutent pas ces vérifications et ne fonctionnent pas sans configuration correcte.

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

Cette erreur indique un problème RPC selon lequel l'outil de migration ne peut pas créer de liaison avec 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.

Cette erreur indique en général qu'un utilisateur ou un groupe global ou universel avec le nom {SourceNetBIOSDom}$$$ existe déjà. ADMT crée en général le groupe local de ce nom, mais cela lui est impossible si une entité de sécurité de ce nom existe déjà. Cette erreur indique en général que le compte d'utilisateur utilisé pour exécuter ADMT n'a pas les autorisations suffisantes pour effectuer la migration dans un domaine ou dans les deux. Cette erreur présente dans le fichier Migration.log après une migration avec sIDHistory indique en général que le domaine source a des approbations configurées qui n'existent pas sur le domaine cible. Pour résoudre ce problème, exécutez l'Assistant Migration des relations d'approbation pour mapper les approbations dans le domaine source, puis répliquez les relations dans le domaine cible.

Informations supplémentaires sur sIDHistory

Le sIDHistory est un attribut d'entités de sécurité multivaleur dans Active Directory qui peut contenir jusqu'à 850 valeurs. Pour fournir une 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 opèrent au niveau fonctionnel du mode natif Windows 2000 ou ultérieur.

Certains produits de fournisseurs tiers permettent l'activation de sIDHistory dans les domaines en mode mixte. Cela ne représente pas l'utilisation légitime des API publiques. Les administrateurs de domaine qui utilisent de tels outils risquent de mettre leur déploiement Active Directory dans un état non pris en charge.

Durant les migrations inter-forêts, LDAP_Rename est responsable du déplacement des objets. Pour cette raison, les objets migrés conservent des données d'identification importantes, y compris l'objectGUID 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 inter-forêts, mais l'objectGUID est toujours perdu lors de ce type de migration.

Dans les deux cas, un nouveau SID est affecté aux objets migrés 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 ne peut pas être modifié ni supprimé à l'aide des outils d'administration Active Directory standard car l'attribut sIDHistory est détenu par le 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 qui n'est pas censé être joint indéfiniment aux entités de sécurité. Bien que la migration du sIDHistory puisse simplifier considérablement le processus de migration de domaine, il existe des ramifications de sécurité importantes qui doivent être prises en compte avant d'implémenter le sIDHistory dans une entreprise de production.

Un jeton de sécurité Windows 2000 peut contenir au plus 1 023 SID, y compris sIDHistory et les SID de groupe. Kerberos est également limité car Windows 2000 Kerberos a une mémoire tampon de 73 SID. Après l'application de Windows 2000 Service Pack 2 (SP2), cette taille peut être doublée par une modification du Registre à l'échelle de l'entreprise. Le dépassement de ces limites viole la restriction MaxTokenSize et peut provoquer des résultats imprévisibles, y compris l'échec de l'authentification Kerberos et l'application erratique ou inexistante de stratégies. Pour prévenir ces problèmes, utilisez Traduction de la sécurité au lieu de sIDHistory comme solution à long terme pour conserver l'accès aux ressources après une migration de domaine.