Présentation
Il arrive que l’on rencontre des situations où il est nécessaire de revoir l’ensemble de l’organisation. C’est le cas par exemple lors de la fusion ou de la scission d’une entreprise. Il s’agit d’une opération de migration des objets Active Directory d’un domaine vers un autre.
L’outil de migration Active Directory Migration Tool permet d’effectuer cette opération.
Cette suite d’article a pour but de présenter cet outil et fait référence au guide de migration ADMT disponible à l’adresse http://www.microsoft.com/fr-fr/download/details.aspx?id=19188.
Que peut-on faire ?
L’image ci-dessous nous présente quelques possibilités de l’outil :
A gauche nous avons le domaine source avec des utilisateurs, des groupes et des ordinateurs. A droite le domaine cible. L’opération permet de migrer ses différents éléments tout en autorisant le compte du nouveau domaine de continuer à accéder aux ressources partagées du domaine source. La migration en elle-même ne donne pas accès aux utilisateurs du domaine source à des ressources du domaine cible.
Pour comprendre le principe il faut déjà définir certains attributs d’un objet AD (utilisateurs, ordinateurs ou groupe). Chaque objet AD possède un identifiant unique dans l’environnement (SID), comme par exemple : « S-1-5-12–7623811015-3361044348-030300820-1013 ». La partie en rouge est identique pour l’ensemble du domaine alors que la partie en bleue est unique pour chaque objet du domaine. Lorsqu’un objet est authentifié par un contrôleur de domaine il obtient un « jeton d’accès ». Son jeton d’accès contient son SID ainsi que tous les SID de tous les groupes auxquels il appartient directement ou par imbrication de groupe (c’est pour cela qu’il faut rouvrir la session lorsqu’on ajoute un utilisateur dans un groupe). La migration ADMT permet d’ajouter à ce jeton son historique SID venant de l’ancien domaine ainsi celui des groupes auxquels il appartient afin qu’il puisse accéder aux ressources qui n’ont pas encore été migré vers le nouvel AD.
Nous en déduisons déjà qu’il est préférable de migrer les utilisateurs puis les ordinateurs et en dernier les serveurs de ressource. Cela permet de faire une migration progressive et de conserver l’accès aux ressources pour les utilisateurs déjà migrés et ceux travaillant encore avec le compte du domaine source.
Note : sur Windows 7 et supérieur vous pouvez exécuter la commande « whoami /groups », pour voir les groupes auxquels vous appartenez.
Migration intra forêt ou inter forêt
- la migration inter forêt permet de créer une nouvelle forêt AD et d’y créer un clone de l’objet source. Dans ce type de scénario l’objet existe dans le domaine cible et dans le domaine source. Il est possible de désactiver l’utilisateur du domaine source lors de la migration ou de planifier sa désactivation automatique au bout d’un certain nombre de jours.
- la migration inter domaine permet de déplacer un objet d’un domaine vers un autre domaine dans la même forêt. Il s’agit cette fois-ci d’un déplacement de l’objet car celui-ci n’existera plus dans le domaine source.
Les versions ADMT
Il existe différentes versions d’ADMT permettant de couvrir une majorité de scénarios, mais il faut bien comprendre que toutes les combinaisons entre domaines source et domaine cible ne sont pas possibles.
Ce tableau extrait du guide de migration ADMT( http://www.microsoft.com/fr-fr/download/details.aspx?id=19188) permet d’identifié les possibilités :
|
Version d'ADMT |
Plate-forme d'installation |
Conditions requises pour le domaine source |
Conditions requises pour le domaine cible |
Objets de migration de l'ordinateur pris en charge |
|---|---|---|---|---|
|
Windows Server 2003 |
Les domaines source peuvent contenir des contrôleurs de domaine qui exécutent Windows NT, Windows 2000 Server ou Windows Server 2003. Aucun niveau fonctionnel minimum de domaine n'est requis pour un domaine source. |
Le niveau fonctionnel minimum de domaine cible est Windows 2000 natif. |
Permet de migrer des ordinateurs qui exécutent Windows 2000 Professional, Windows XP, Windows NT 4, Windows 2000 Server et Windows Server 2003. |
|
|
Windows Server 2008 |
Les domaines source peuvent contenir des contrôleurs de domaine qui exécutent Windows 2000 Server, Windows Server 2003, ou Windows Server 2008. Aucun niveau fonctionnel minimum de domaine n'est requis pour un domaine source mais ADMT v3.1 ne peut pas être utilisé pour migrer des objets à partir de domaines Windows NT 4. |
Le niveau fonctionnel minimum de domaine cible est Windows 2000 natif. Si le domaine cible a des contrôleurs de domaine qui exécutent Windows Server 2008 R2, utilisez ADMT v3.2. Remarque Il existe des problèmes connus qui surviennent lorsque vous utilisez ADMT v3.1 pour migrer des objets vers un domaine qui a des contrôleurs de domaine Windows Server 2008 R2. Pour plus d'informations, voir l'article 976659 de la Base de connaissances Microsoft (http://go.microsoft.com/fwlink/?LinkId=182290). |
Permet de migrer des ordinateurs qui exécutent Windows 2000 Professional, Windows XP, Windows Vista, Windows 2000 Server, Windows Server 2003 et Windows Server 2008. |
|
|
Windows Server 2008 R2 |
Le niveau fonctionnel minimum de domaine source est Windows Server 2003. |
Le niveau fonctionnel minimum de domaine cible est Windows Server 2003. |
Permet de migrer des ordinateurs qui exécutent Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008 et Windows Server 2008 R2. |
Nous remarquons :
-depuis un domaine NT4 il n’est possible d’utiliser que la version 3.0. La migration ne peut se faire que vers un domaine avec un niveau fonctionnel Windows 2000 natif et l’outil de migration ne peut être installé que sur une version 2003. Nous constatons donc qu’il n’est pas forcément possible de migrer un domaine ancien vers des environnements récents dans une étape unique.
- la dernière version publié au moment d’écrire cet article (3.2) ne fait pas référence à Windows 2012 et 2012 R2. Néanmoins il est possible de migrer vers des contrôleurs de domaine en 2012 ou 2012R2. Si vous êtes dans ce cas consulter l’article : http://technet.microsoft.com/en-us/library/active-directory-migration-tool-versions-and-supported-environments(v=ws.10).aspx
Avant de commencer :
- planifier votre migration et faites le point sur l’ensemble de vos applications,
- exécuter des sauvegardes régulières de vos contrôleurs de domaine incluant l’état du système. Pour plus de détails sur la partie sauvegarde Active Directory vous pouvez consulter l’article suivant : http://pbarth.fr/node/15
- déchiffrez les fichiers utilisant le système EFS faute de quoi vous risquez de perdre l’accès au contenu
- vérifier la synchronisation des horloges entre le domaine source et cible. L’authentification Kerberos est dépendante de la synchronisation des horloges et pourrait échouer. Vous pouvez consulter l’article suivant pour comprendre comment géré la synchro des horloges dans un domaine AD : http://pbarth.fr/node/87
Exchange :
Si vous disposez d’un environnement Exchange il est possible de migrer les boîtes aux lettres vers un environnement Exchange 2010 ou 2013. Ce n’est pas l’objectif de cet article néanmoins vous trouverez quelques pistes dans les liens suivants.
http://blogs.technet.com/b/exchange/archive/2010/08/10/3410619.aspx
Commentaires
ADMT - cas d'utilisation
Bonjour Philippe,
Merci pour cet article.
En effet, je compte mener une opération de restructuration de mon architecture AD en utilisant ADMT.
En effet, l'entreprise où je travaille est repartie sur 4 regions. Chaque région a mis en place sa forêt AD basée sur le nom de domaine abc.com , on se retrouve donc avec 4 forêts indépendantes qui portent le même nom de domaine.
Notre objectif est d'unifier tout ça dans une forêt unique qui s'appellera soc.local
Je pense que ADMT fait bien l'affaire?
Sinon, qu'en est-il de la jonction des postes utilisateurs à la nouvelle forêt ?
Vont-ils retrouver leurs sessions?
Merci
ADMT - cas d'utilisation
on se retrouve donc avec 4 forêts indépendantes qui portent le même nom de domaine.
Le fait que les 4 domaines portent le même nom ne vous simplifiera pas la migration. Vous ne pouvez avoir qu'une approbation avec un nom précis à un moment donné. Il vous faudra migrer progressivement chaque entreprise. Oui les utilisateurs retrouvent leur environnement en migrant les postes dans la nouvelle forêt.
Migration AD
Bonjour Philippe,
Merci pour ton retour rapide!
Je commence déjà à réfléchir à propos d'un plan de travail qui peut se résumer en ce qui suit:
1. Création du nouveau serveur Contrôleur de Foret principal soc.local
2. Mise en place de la machine ADMT
3. Création de la relation d'Approbation entre soc.local la première forêt abc.com
4. migration via ADMT des objets AD depuis abc.com vers site1.soc.local
5. Jonction des machines de abc.com au domaine site1.soc.local
6. Suppression de l'approbation [soc.local , abc.com],
7. Eradication de la forêt abc.com (1er site)
8. reprise des etapes 3-7 pour la forêt abc.com (2ème site) pour une migration vers site2.soc.local
9. reprise des etapes 3-7 pour la forêt abc.com (3ème site) pour une migration vers site3.soc.local
10. reprise des etapes 3-7 pour la forêt abc.com (4ème site) pour une migration vers site4.soc.local
Qu'en pensez vous?
Hello,
Hello,
Je n'ai pas compris tu veux faire une forêt avec 4 domaines ? Si oui sache que le domaine racine est particulier car il contient des groupes de sécurité privilégié dans la forêt (admin de l'entreprise, du schéma etc ...). Au niveau AD il n'y pas de nécessite à faire un domaine par site. La question du multi-domaine dépend avant tout de la façon d'administrer les environnements et des limites de sécurité. Comment as-tu prévu de gérer les utilisateurs (centralisé), les accès ? les ressources centralisés ? ou chaque site est indépendant ?
Gestion Multisites
Bonjour Philippe,
De part notre répartition géographique, nous avons aujourd'hui une équipe locale par région qui gère sa forêt d'une façon autonome.
D'autre part, et pour des raisons de performances, nous souhaitons garder un controleur de domaine au niveau de chaque région, pour éviter des problèmes de congestion du WAN,
C'est pour cela que j'ai pensé à une organisation multidomaine?
Par contre, les principaux objectifs que nous comptons atteindre c'est :
- Harmoniser les politiques GPO sur tous les postes utilisateurs,
- Avoir une seule source pour l'authentification,
- Permettre l'intégration avec d'autre système (Messagerie / Bases de données / Filtrage de Contenu)
Vous voyez que le multidomaine n'est pas un bon choix?
Merci
Re Gestion Multisites
Vous pouvez n'avoir qu'un domaine et des contrôleurs de domaines sur chaque site. Cela ne crée pas de congestion en soi. La partie performance va dépendre de la répartition des applications. Si a côté vous mettez un seul serveur de ficher sur le site principale vous verrez que ce n'est pas l'AD qui vous posera le plus de problème. Même question si vous utiliser un intranet ou un serveur de messagerie centralisé. Les serveurs d'impressions doivent être géré par site.
La gestion décentralisé est un argument a prendre en compte qui oriente vers un environnement multi domaine. Sachez que les scénarios de Disaster Recovery sont un peu plus lourd avec plusieurs domaines. Il est préférable d'avoir au moins 2 DC par domaine avec des sauvegardes de l'état du système. Il peut aussi s'avérer utile de créer un domaine racine neutre vu que ce dernier dispose des groupes privilégiés au niveau de la forêt.
Restructuration AD
Bonjour Philippe;
Merci beaucoup pour ta collaboration, je tiendrais compte de tes précieuse remarques.
Bonne journée
Re :Restructuration AD
De rien, en espérant avoir pu t'aider dans tes choix ...
Droits quite à une migration
Bonjour,
J'ai suivi tes précieux conseils, et j'ai commencé à migrer mes groupes, quelques user, quelques PC. Tout c'est bien passé, les attributs sont bon, les SID historique correspondent aux SID sources, etc etc
Sauf que, les droits depuis le domaine final, vers le domaine source ne fonctionnent pas.
J'ai lu et relu, rien n'y fait. Bien sur les "builtin" fonctionnent.
Une idée ??
merci
Perte des droits sur le domaine source
Bonjour,
j'ai suivi à la lettre tes conseils, et je t'en remercie. Une fois les premier éléments migrés, je ne peux accéder à mes fichiers du domaine source.
J'ai vérifié les attributs user, group.. et les SID Historiques correspondent aux SID du domaine source.
une idée
encore merci
Re : Perte des droits sur le domaine source
Tu as bien vérifié dans ton approbation que le SID Filtering est désactivé ? Ce paramètre de sécurité activé par défaut lors de la création d'une approbation empêche l'utilisation du Sid History. Lorsqu'il est désactivé l'approbation apparaît avec un avertissement. Dans le cas d'une migration ADMT il faut le désactiver pour que l'utilisateur migré puisse utilisé son SID History afin d'accéder à la ressource dans le domaine source.
Voir :
http://pbarth.fr/node/108
Migration et consolidation
Bonjour Philippe,
J'ai une question a propos d'une migration inteforet et intraforet.
Nous allons réorganiser l'active directory en implémentant une nouvelle convetion de nommage avec un nouveau modele de délégation.
Devons nous migrer les groupes locaux qui donnent accès au ressources avec les mêmes noms au début et ensuite changer le nom des groupes vers la nouvelle convention de nommage ? une fois biensûr que nous sommes sures que les accès sont consérvés ,quels sont les attribut a changer si c'est le cas ?
Merci d'avance pour l'eclaircissement :) j'aurais surement d'autres question par la suite :)
Migration et consolidation
Bonjour Philippe,
J'ai une question a propos d'une migration inteforet et intraforet.
Nous allons réorganiser l'active directory en implémentant une nouvelle convetion de nommage avec un nouveau modele de délégation.
Devons nous migrer les groupes locaux qui donnent accès au ressources avec les mêmes noms au début et ensuite changer le nom des groupes vers la nouvelle convention de nommage ? une fois biensûr que nous sommes sures que les accès sont consérvés ,quels sont les attribut a changer si c'est le cas ?
Re ; Migration et consolidation
Droit sur dossier migré
Bonjour et merci de ce fantastique article qui m' a bien servi. J'ai une question à propos des droits des user sur les dossiers migré sur le nouveau serveur de fichier.
J'ai donc effectué ma migration (groupe, user, AD) et ensuite copié les data via Robocopy. Hors sur le domaine de destination je vois bien mes users de l'ancien domaine et tant que le user se logue sur l'ancien domaine il à accès aux fichiers. S'il se logue sous le nouveau domaine il n'a plus d'accès aux data. Lorsque je regarde les droits NTFS je vois bien les groupes de l'ancien domaine avec mes users mais là il faut que j'entre les nouveaux groupes de mon nouveau domaine. Si je ne le fais pas à la main pas d'accès aux users.
Peut on "transformer" les groupes du domaine A.local en B.local ? Quel moyen avons nous pour le faire automatiquement ?
Merci
RE : Droit sur dossier migré
Les permissions NTFS et les groupes sont normalement migré par ADMT. En générale on migre les serveurs de ressources à la fin pour que les utilisateurs de l'ancien et du nouveau puisse y accéder. La migration d'un serveur de fichier se passe comme pour un autre poste du domaine.
Si tu migres les fichiers et les partages manuellement tu dois remettre les bons droits.
Salut et merci pour ce
Salut et merci pour ce Feedback rapide.
L'ancien serveur de fichier c'est le contrôleur de domaine donc impossible à migrer comme pour un poste. J'ai lu plus loin sur ton site qu'il fallait désactiver le SID Filtering. Cela pourrait peut être venir de là ? Qu'en penses tu ?
En tout cas je récupère bien les droits de l'ancien domaine sur le nouveau, pas de soucis la dessus et via ADMT oui je récupère les groupes et les users (et je migre les postes avec).
Lorsque tu dis "Si tu migres les fichiers et les partages manuellement tu dois remettre les bons droits." tu le fais bien avec robocopy et le /SEC ? c'est bien cela ?
<p>J'ai lu plus loin sur ton
<p>J'ai lu plus loin sur ton site qu'il fallait désactiver le SID Filtering. Cela pourrait peut être venir de là ? Qu'en penses tu ?</p>
Oui si SID Filtering n'est pas dédactivé sur l'approbation les utilisateurs migré sur le nouveau domaine ne peuvent pas accéder à une ressource de l'ancien domaine.
SID Filtering
Hello Philippe
Merci pour ce feedback, je bosse la dessus today
Merci
Migration windows xp sp3 X86 depuis admt 3.2
RE : Migration windows xp sp3 X86 depuis admt 3.2
Migration windows xp sp3 X86 depuis admt 3.2
Voir :
Voir :
https://support.microsoft.com/fr-fr/help/929493/error-message-when-you-u...
Urgent
Re :Urgent
Changement de nom de foret
Re :Changement de nom de foret
Bonjour, Je ne suis pas sur d'avoir tout compris.
je souhaite intégrer le domaine d'une foret à ma foret existante
Il n'est pas possible d'intégrer un domaine déja existant d'une une autre forêt à votre forêt actuelle. Il faut créer un nouveau domaine si nécessaire et migrer les utilisateurs, les ordinateurs et les groupes avec ADMT.
Même si il est possible de renommer un domaine, l'opération est déconseillée car beaucoup d'éléments peuvent être perturbés, comme par exemple les serveurs Exchange. C'est une opération qui représente pas mal de risque sur les services liés et qui nécessite un très haut niveau de maitrise sur les éléments impactés.