Retour d’expérience sur ADMT -> migration des ressources d’un domaine NT4 vers un domaine 2003 existant

Salut
J’ai récemment travaillé sur un projet de migration des ressources d’un domaine NT4 vers un domaine 2003 existant (fusion/consolidation de deux domaines). L’architecture de mon client était la suivante :
* 1 domaine NT4 avec un serveur NT4 SP6a
* 1 domaine 2003 avec 3 contrôleurs de domaine Windows 2003 R2 SP2. 
Le but principal de ce projet était de migrer automatiquement les ressources du domaine NT4 dans le domaine 2003. L’opération devait être transparente pour les utilisateurs.
Pour cela nous avons utilisé ADMT 3.0. Ce produit est gratuit et peut être télécharger à l’adresse suivante :
http://www.microsoft.com/downloads/details.aspx? FamilyID=6f86937b-533a-466d-a8e8-aff85ad3d212&displaylang=en
Le principal avantage de cet outil est qu’il permet :
* De migrer les groupes, les comptes utilisateurs et les ordinateurs du domaine NT4 vers le domaine 2003 en conservant le SID de l’ancien domaine NT4 (SID HISTORY). Plus précisement, ls ressources dans le domaine ont deux identifiants, un GUID (comme tout objet dans un domaine Active Directory) et le SID HISTORY.
* De migrer les mots de passe des utilisateurs (avec le service d’Exportation des mots de passe installé sur le contrôleur de domaine NT4).
* De modifier en masse et automatiquement les ACL sur les dossiers et fichiers. En fait ADMT va rechercher les ressources qui utilient des SID de l’ancien domaine. Si le SID correspond au SID HISTORY d’une ressource dans le domaine 2003 (ressources migrées), alors ADMT remplace le SID HISTORY par le GUID de la ressource.
* D’affecter le profil utilisateur de chaque compte utilisateur du domaine NT4 migré dans le domaine 2003 au compte utilisateur du domaine 2003.

Microsoft fournit une documentation très complète sur cet outil à cette adresse :
http://www.microsoft.com/downloads/details.aspx? familyid=D99EF770-3BBB-4B9E-A8BC-01E9F7EF7342&displaylang=en

Personnellement je divise toujours ce type de projet en 4 étapes :
1. Etude de l’existant :
Cette étape permet de vérifier et valider le fonctionnement du domaine NT4 et du domaine Active Directory 2003. J’ai toujours des suprises à cette étape (problèmes non détectés par le client).
Les poins stuivants doivent être analysés :
a. Configuration DNS : les stations de travail du domaine NT4 doivent être configurées pour utiliser un serveur DNS hévergeant les zones DNS du domaine Active Directory. En effet les stations de travail membre d’un domaine Active Directory font des requêtes dans la zone DNS qui correspond à leur domaine pour localiser l’emplacement d’un contrôleur de domaine (DC), d’un DC serveur de “Catalogue Global” et d’un DC “Emulateur PDC”. En cas de mauvaise configuration DNS, ADMT peut échouer la migration de la machine sur le nouveau domaine.
b. Vérifier le bon état de l’annuaire : pour cela, installer les supports tools de Windows 2003 et faire un “dcdciag /v /e > c:\dcdiag.txt”). Faire une recherche sur les mots fail et error au niveau du fichier c:\dcdiag.txt.
c. Analyser les observateurs d’événements sur le serveur 2003 et le serveur NT4. Au niveau du serveur NT4, traquer tout problème d’authentification des stations de travail (erreur netlogon 5722 entre autres).  Ces messages indiquent généralement que ces machines ont des problèmes de compte ordinateur (mot de passe de compte ordinateur différent sur la station de travail / contrôleur de domaine…). Ces machines ne migreront pas correctement avec ADMT car le compte de ressource n’arrivera pas à s’authentifier sur la station de travail. Sortir les machines problématiques du domaine puis le réentrer (vous pouvez aussi utiliser la commande netdom).

2. Préparer l’environnement informatique :
a. Il faut tout d’abord établir une relation d’approbation entre le domaine NT4 et le domaine Active Directory 2003. Pour cela appliquer l’article http://support.microsoft.com/kb/325874/en-us. Si cela ne fonctionne pas, le problème provient probablement d’un problème de résolution de noms. Pour corriger ce problème, installer le service WINS sur un contrôleur de domaine du domaine 2003 et faire pointer tous les serveurs dont le serveur NT4 sur ce serveur WINS.
Penser à désactiver le filtrage des SID (sinon le SID HISTORY ne sert à rien). Pour cela taper la commande suivante (sur une seule ligne):
netdom trust NOM_NETBIOS_DOMAINE_CIBLE /domain:NOM _ NETBIOS _ DOMAINE _ SOURCE
/quarantine:No /usero:compte_administrateur_domaine_cible
/passwordo:mot_de_passe_compte_administrateur_domaine_cible

Dans la console “Domaine et Approbation“, aller dans les propriétés de votre domaine 2003. Dans l’onglet approbations, sélectionner la relation d’approbation avec le domaine NT et cliquer sur “Propriétés”. Dans la fenêtre “Propriétés nom netbios_domaine_source“, vous devez avoir le messager suivant “Le filtrage d’indetificateur de sécurité (SID) est désactivé. cela pose un risque de sécurité…”.
Si vous rencontrez des problèmes pour établir la relation d’approbation, penser aussi à la configuration de votre réseau et de vos pare-feu. En effet s’il y a un pare-feu entre les contrôleur du domaine NT4 et ceux du domaine 2003, certains ports doivent être ouvert. Pour plus d’informations, voir l’article suivant :
http://technet.microsoft.com/en-us/library/bb727063.aspx
Valider aussi que le ping est possible…

b. Pour le compte de ressource, si la sécurité n’est pas un critère trop important, je vous préconise de créer un compte dans le domaine NT4 qui est Admins du domaine et d’ajouter ce compte aux groupes Builtin\Administrateurs. Si la sécurité est importante, au niveau des OU dans lesquels vous aller migrer les ressources avec ADMT, utiliser l’assistant délégation d’administration et déléguer des droits aux comptes de migration (créé dans le domaine source NT4). Le mieux est de déléguer des droits à un groupe et d’ajouter à ce groupe, le compte de migration.
Remarque :
Le compte de migration doit être Admins du domaine car par défaut seul ce compte a des droits administrateur local sur toutes les machines du domaine NT4. Vous avez besoin de ces droits pour exécuter l’agent ADMT qui va basculer la machine du domaine NT4 vers le domaine 2003.

c. Créer une ou plusieurs OU dans le domaine 2003 pour les ressources du domaine NT4.

d. Installer un contrôleur de domaine Active Directory si le site en est dépourvu et installer ADMT sur ce serveur. Si ce n’est pas possible, rattacher le ou les sous réseaux du site géographique où se trouve le domaine NT4 à un site Active Directory et installer ADMT sur un contrôleur de domaine de ce site. En effet si vous ne faites pas ça, vous êtes obliger de forcer la réplication et de mettre en place de la résolution WINS pour migrer les stations de travail. En effet les routeurs bloquent le broadcast par défaut et pour vous loguer il faut que les ressources migrées via ADMT soient disponibles sur le contrôleurs de domaine Active Directory que vous utiliserez sur le site avec le domaine NT4.

3. Migrer les ressources :
a. Migrer les groupes :
Comme indiquer dans la documentation Microsoft, migrer les groupes en premier.
Ne migrer pas les groupes prédéfinis comme Administrateurs. Même si certains groupes ne servent plus, migrer les. Vous ferez le ménage après la migration… Dans le cas contraire, certains SID du domaine NT4 ne seront pas migrés et voius verrez des numéros étranges dans vos permissions quand vous aurez coupé la relation d’approbation entre les domaines NT4 et 2003.
Au niveau de la fenêtre “Option de groupe”, cocher uniquement “Effectuer la migration des indentificateurs SID de groupe vers le domaine“.

b. Migrer ensuite les comptes utilisateurs :
Sélectionner tous les comptes sauf les comptes prédéfinis comme “Administrateur“.
Au niveau de la fenêtre “Option de l’utilisateur“, sélectionner “Mettre à jour les droits utilisateur” et “Corriger l’appartenance des groupes utilisateurs associés“.
Si la migration des mots de passe échoue, penser à démarrer le service “Exportation des mots de passe” sur le seveur NT4. Une fois installé sur le serveur NT4, ce service est configuré pour démarrer manuellement.

c. Migrer les stations de travail :
Cela se passe en deux temps :
* Migration des comptes ordinateurs :
Au niveau de a fenêtre “Traduire les objets“, contrairement à ce qu’indique la documentation Microsoft, cocher toutes les cases ! Sinon les permissions sur les ressources présentes sur les stations de travail ne seront pas traduites (même problème avec les profils utilisateurs…).
Attention au conflit avec des comptes ordinateurs qui existent déjà. En cas de conflit avec une machine du domaine 2003, sortir la machine du domaine NT4, la renommer et la faire rejoindre le domaine NT4. Remigrer le compte ordinateur avec ADMT.
* Une fois la migration des comptes ordinateurs terminée, il faut maintenant exécuter l’agent ADMT sur les stations de travail. Toujours commencer par exécuter un test de prévérification pour voir quels sont les machines qui passent ou non.
Les causes d’échec les plus courantes que j’ai rencontré sont :
* Pare feu qui n’autorise pas le partage de fichiers et d’imprimantes.
* Services arrêtés. Certaines versions de Windows que l’on peut télécharger sur Internet s’amusent à arrêter des services qui sont nécess&ires pour joindre une machine dans un domaine… Le mieux est de comparer avec une machine normal configurée par défaut.
* Problème d’authentification : visualiser les observateurs d’événements sur la station de travail pour vérifier si elles communiqent correctement avec le contrôleur de domaine NT4.
* Problème configuration réseau : vérifier que la station de travail est configurée avec comme serveurs dns principal un serveur dns qui héberge la zone DNS utilisée par le domaine Active Directory.
* La POST VERIFICATION échoue souvent à cause de problème de résolution de noms. Pour que cela fonctionne bien, la meilleure solution est de relancer la POST VERIFICATION 20 de fois avec comme intervalle de relance 1 minute. Si cela échoue comme même, vérifier les paramètres du client DNS (configuration TCP/IP avancée). Il faut que la machine soit configurée pour s’enregistrer dynamiquement dans la base DNS à l’aide son nom +suffixe dns principal (qui doit maintenant correspondre avec le nom du domaine Active Directory).
Remarque :
En cas de doûte, je vous préconise d’afficher / conserver le journal de l’agent ADMT où toutes les opérations/erreurs sont inscrites. Analyser ce journal dans le détail.
Dans certains cas, je vous préconise de vous connecter sur les stations de travail pour faire une vérification manuelle (observateur d’événements).

d. Migrer enfin les serveurs de fichiers :
Appliquer la même procédure sauf qu’au niveau de la fenêtre “Traduire les objets“, il ne faut pas cocher “Profil utilisateur”.

4. Finalisation de la migration :
* Supprimer la relation d’approbatrion avec le domaine NT4. Tester dans un premier temps, l’arrêt du serveur NT4 pour valider que tout fonctionne bien.
* Supprimer le SID History (si vous aimez les problèmes).
* Désactiver les ressources qui ne sont plus utiliser. Ne supprimer pas, on ne s’est jamais…

Remarque :
Pour migrer vers un domaine 2008, il faut utiliser ADMT 3.1.
Une des limites d’ADMT est que l’on ne peut pas migrer les groupes prédéfinis (Admins du domaine, utilisateurs du domaine…). C’est un peu embêtant quand on a mis des permissions sur ces groupes. Il semble que les outils de QUEST gère cette problématique. Sinon, faire des scripts avec l’utilitaire subinacl.
http://www.microsoft.com/downloads/details.aspx? FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b&displaylang=en
Pour les amateurs de SID History, consulter ce lien :
http://blog.portail-mcse.net/index.php?post/2008/05/21/ De-multiples-Sid-en-SIDhistory

Bonne migration avec ADMT
A+

A propos Guillaume Mathieu

Directeur Technique chez Flexsi
Ce contenu a été publié dans Active Directory, ADMT, Audit, Dns, Migration, Outils, Windows 2003 Server, Windows NT4. Vous pouvez le mettre en favoris avec ce permalien.

4 réponses à Retour d’expérience sur ADMT -> migration des ressources d’un domaine NT4 vers un domaine 2003 existant

  1. darkbol dit :

    Bonjour,

    Très bon article, j’ai pu faire une corrélation avec mon processus et ça colle 🙂

    Ma migration concernant le serveur de fichiers m’a donné des choses bizarres. Certaines ACL n’ont pas été traduites. Quelle pourrait en être la raison?

    Un blocage d’héritage?

    Merci pour ta réponse,

    Dark

  2. Bonjour

    Attention, il est possible que btu n’es pas migré tous les comptes utilisateurs et les groupes dans le nouvel annuaire ou que certains comptes / groupes soient ceux d’un autre domaine (relation d’approbation).
    Hors, la transcripytion des ACL change l’ACL si il y a un mappage possible entre le compte / groupe dans le domaine source et dans le domaine cible.

    As tu des erreurs dans le fichier de log ?

  3. darkbol dit :

    Mes fichiers log ADMT ne me révèlent aucune erreur.

    Question : l’ACL devrait pouvoir rester grâce à la relation d’approbation non ?

    Voici mon retour de migration 2000 – 2003 AD / Exchange (maintien de l’ancien domaine pour quelques users) et les incidents apparus, j’espère que cela pourra servir.

    a. Migration de Bal écrase les contacts existants possédant la même adresse SMTP
    b. La sécurité liant les objets AD à la messagerie n’ont pas été migrés. (Droits sur les BAL de services, La délégation d’utilisateurs (« De la part de… », Adresses de messagerie sur les listes de diffusion)
    c. Plusieurs utilisateurs se connectent sous un nouveau profil. En effet, le noms d’ouverture de session avaient été renommés une semaine avant la migration.
    d. ACL non translatés sur le serveur de fichier

    Autant, j’ai des réponses pour le premier (doublon de smtp et compte admt doit être dans les administrateurs exchange), autant je cherche des réponses pour les c. et d. :

    c. pq un renommage ne permet pas de garder le profil (SIDHistroy nous faisant défaut?)
    d. y a t il un taux d’erreur de translation? par rapport à ce que tu me dis, le mappage est possible vu ma relation d’approbation. Maintenant j’y pense, si les utilisateurs faisaient partie d’un groupe global, là effectivement ça ne passera pas. Quels sont les autres cas?

    Merci

    Dark

  4. Philippe GUERELLE dit :

    Très bon article.
    Cependant une question, dans notre entreprise nous avons réalisé et vécu une migration de serveur de fichiers ainsi qu’une migration de domaine.
    Nos données sont copiés vers notre nouveau serveur de fichiers qui est dans notre nouveau domaine, ils nous restent à supprimer les SID non résolus.
    A l’époque j’avais trouvé l’outil subinacl, mais notre ancien contrôleur de domaine est tombé en panne.
    Depuis l’outil ne permet plus de supprimer les SID non résolus car selon il inerrogeait l’ancien domaine.
    Avez vous une autre solution ?

    Cordialement.

Laisser un commentaire