Restructurer un domaine Windows NT 4.0 vers Windows 2003 [60 mn de lecture - paru le 11/3/2003 - Public : Expert]

Auteur

Jonathan BISMUTH Elève-Ingénieur Supinfo Paris Promotion SUPINFO 2004    Lui écrire    Tous les projets de cet auteur    Le mini-CV de cet auteur

1. Préparation des domaines sources et cible avant migration

1.1. Phase préparatoire : Création du premier domaine de la nouvelle forêt (PDNF)

Le but de cette phase est la création d'une forêt intermédiaire, afin de faire une migration en deux temps. Pour créer cette forêt, il faut procéder en 3 temps :

•  installation de Windows 2003 sur une machine propre (pour les tests un PC classique peut faire l'affaire, en attendant la commande / le recyclage d'un serveur)
•  Installation et configuration d'un DNS sous cette machine afin de gérer les enregistrements dynamiques (sécurisés ou non).
•  Lancement de l'installation d'active directory

Ce premier domaine est la fondation de l'infrastructure Active Directory visée. Celui ci doit être créé avant toute migration de domaine existant.

Recommandation à l'installation

Avant d'installer Windows 2003 sur ce serveur, il faut au préalable s'assurer que le service DNS n'a jamais été installé sur la machine. Si tel n'est pas le cas, la résolution et la récursivité risquent de ne pas fonctionner.

•  Lancer l'assistant d'installation. Choisir le système de fichier NTFS, mettre une adresse IP statique et un masque qui correspondent à ceux de la topologie actuelle.
•  Dans les paramètres TCP/IP mettre son adresse en tant que serveur DNS (temporaire)
•  Installer Windows support tools.

Installation d'Active Directory

Lancer l'assistant d'installation sur l'ordinateur. L'assistant crée la base de données Active Directory et initialise les données de l'annuaire. Il installe et configure aussi le service DNS.

Vérifications post installation

Pour vérifier que l'installation d'Active Directory s'est déroulée correctement :

•  Vérifier l'observateur d'événement.
•  Lancer dcdiag.exe et netdiag.exe pour analyser le rapport d'erreur
•  Dans les paramètres du DNS, vérifier que _msdcs. forest_root_nom_domaine et forest_root_nom_domaine ont bien été créés. Vérifier que DomainDnsZones et ForestDnsZones existent.

1.2. Préparation de la mise à jour du domaine NT 4.0 vers le PDNF

Afin de réussir le processus de migration des ressources vers le PDNF, et après avoir suivi toutes les étapes précédentes, il faut procéder aux taches suivantes :

Sauvegarder les données du domaine

Penser à sauvegarder touts les données avant de commencer la mise à jour. Cette tache peut varier mais il faudra au minimum sauvegarder les données du PDC et du BDC.

Se protéger contre la surcharge potentielle du contrôleur de domaine

Avant toute installation de Windows 2003 sur le PDC, il faut le protéger en le configurant à l'avance comme émulateur de contrôleur NT 4.0 (par défaut sur le premier DC installé), ainsi, les clients 2000 ne le reconnaîtront pas comme contrôleur Active Directory et s'authentifieront comme avant. Penser à maintenir cette émulation jusqu'à la migration total des contrôleurs de chaque site.

Après avoir protégé le PDC de risque de surcharge, penser à neutraliser l'émulation sur les autres contrôleurs à migrer. Ceux-ci doivent être capable de contacter un contrôleur Active Directory pour réussir l'installation du service annuaire.

Après la migration suffisante ou totale des contrôleurs sous Windows 2003, il faudra supprimer du registre les modifications effectuées.

Etablir des relations d'approbation entre le domaine NT 4.0 et le PDNF

Avant de migrer des ressources du domaine source à un autre sous Active Directory, il faut s'assurer que des relations d'approbations explicites existent de part et d'autre. Celles-ci permettent aux utilitaires de migration existant comme ADMT de déplacer les objets correctement. De plus, ces relations permettent aux utilisateurs du domaine source d'accéder aux ressources du domaine cible et inversement, dans le cas d'une migration en plusieurs temps.

1.3. Planification de migration des profiles utilisateurs

Les profiles utilisateurs enregistrent les données et informations des utilisateurs. Ceux-ci sont translatés durant le processus de migration.Seul le SID primaire est utilisé pour assigner un profile à un utilisateur, les SIDs de l'historique sont ignorés. Il faut penser à ne transvaser les profiles d'un domaine à l'autre qu'en mode d'ajout, de sorte qu'en cas d'échec, ceux-ci soient toujours disponibles sur le domaine source, sans configuration de mappage.

1.3.a Etablire des procédures administratives

Il convient de définir la façon dont les objets à migrer sont administrés pendant le processus de migration. Etablire des procédures permet de préserver les objets dans les domaines sources et destination, et ainsi permettre un retour arrière en cas d'échec. Les procédures doivent être obligatoirement prises pour :

•  Les comptes utilisateurs, y compris les SIDs
•  Les membres de groupes globaux

Les comptes utilisateurs

Durant le processus de migration, les comptes utilisateurs existent dans les domaines source et destination.
Il faut continuer d'administrer les comptes du domaine source pendant la mise en place de la migration et utiliser l'option ‘'remplacer les comptes conflictuels'' dans ADMT pour re-migrer les comptes problématiques aussi souvent que nécessaire.

Ceci permet de s'assurer que les modifications faites à un compte dans le domaine source sont faites dans celui du domaine de destination.

Les groupes globaux

Il faut continuer d'administrer les groupes du domaine source durant le processus de migration et utiliser l'option ‘'remplacer les comptes conflictuels'' dans ADMT pour re-migrer les groupes problématiques aussi souvent que nécessaire. Ceci permet de s'assurer que les modifications faites à un groupe dans le domaine source sont faites dans celui du domaine de destination.

2.3.b Préparer les domaines source et destination pour la migration

Avant de restructurer le domaine NT 4.0, il convient de s'assurer que le domaine cible Windows 2003 fonctionne dans un mode qui accepte la réception en masse d'objets migrants.Le PDNF doit être en mode ‘'Windows 2000 natif'' ce qui n'est pas fait par défaut. Pour passer le PDNF en mode ‘'Windows 2000 natif''  :

•  Lancer domaine et approbation Active Directory
•  Sélectionner le nouveau domaine
•  Clique droit et sélectionner augmenter le niveau fonctionnel du domaine
•  Choisir Windows 2000 natif et valider

Attention
Ne jamais augmenter le niveau fonctionnel de la forêt , cette opération est irréversible et empêche toute migration d'une version antérieure de Windows.

2.4.c Installer le kit de cryptage élevé

Dans la mesure où les mots de passe utilisateurs doivent être migrés, les deux contrôleurs de domaine des domaines source et cible doivent utiliser le pack de cryptage élevé.Disposant de licences NT 4.0 françaises, il n'existe pas de pack spécifique en dehors des états unis. Pour obtenir le kit de cryptage élevé, il faut installer Internet Explorer 4.1 ou ultérieur sur le PDC du domaine source

2.3.d Etablire des comptes de migration

Afin de migrer des compte et ressources, il faut créer des comptes et leur assigner les capacités appropriées. Dans la mesure où des relations d'approbations ont été faite dans les deux sens plus haut, la gestion de ces compte est simplifiée. Pour créer le compte de migration lorsque une double approbation existe :

•  Dans le domaine source, créer un compte res_migrator
•  Ajouter ce compte au groupe administrateurs du domaine
•  Sur le domaine cible, déléguer à ce compte (du fait de la relation d'approbation) des permissions sur les OUs concernées par la migration (exemple : users, computers…)
•  Ajouter le groupe global A dmins du domaine du domaine cible au dossier contenant les profiles utilisateurs sur le domaine source et y calquer les permissions du groupe global A dmins du domaine du domaine source.

1.4. Configurer les domaines source et cibles pour migrer l'historique SID

Pour migrer l'historique SID, il faut s'assurer que les conditions ci-dessous sont respectées :

•  Un groupe local est utilisé pour auditer les opération d'historique dans le domaine source
•  Le support des clients TCP/IP est activé sur le PDC
•  Des stratégies d'audit sont implémentées sur les domaines source et de destination

1.5. Mise en place d' ADMT (Active Directory Migration Tool)

Installer ADMT sur le contrôleur du PDNF. Cet utilitaire va s'occuper de migrer les différentes ressources. Pour ce faire, il suffit d'installer admigration.msi disponible sur le CD de Windows 2003 dans \i386\admt

1.5.a Activer la migration des mots de passe

Afin de migrer les mots de passe NT 4.0 grâce a ADMT, il faut utiliser un PES pour héberger les DLL de migration de mots de passe. Ce PES est un contrôleur du domaine hôte gérant le cryptage 128bits.La procédure suivante active le support de la migration de mots de passe :

Dans le domaine cible, s'assurer que le groupe par défaut ‘' Pre-Windows 2000 Compatible Access '' contient les groupes anonymes et tout le monde.Dans le domaine source, insérer le CD de Windows 2003 dans le lecteur du PDC et installer pwdmig.exe disponible dans le dossier \i386\admt\pwdmig .

Pour créer une clé de cryptage :

•  Se connecter sur le PDNF en utilisant un compte administratif
•  Mettre une disquette formatée dans le lecteur
•  Lancer une invite de commande puis entrer
      ADMT KEY Domaine_Source A: [ mot_de_passe ] ou [*]

Note
Le domaine source à spécifier est son nom NetBIOS (ici synet1), et non son FQDN (xxx.com), le mot de passe à entrer est optionnel, toutefois pour des raisons de sécurité il est fortement recommandé d'en entrer un. Si au lieu du mot de passe, on entre une astérisque, le mot de passe demandé ne sera pas affiché à l'écran.Pour activer la migration de mots de passe sur le domaine source :

•  Sur le PES, insérer la disquette de clé de cryptage et le CD-Rom Windows Server 2003
•  Parcourir le CD-Rom jusqu'au dossier \i386\admt\pwdmig et lancer pwdmig.exe . Le mot de passe entré précédemment est demander.
•  Entrer le mot de passe et terminer le processus d'installation
•  Dans le registre, modifier la valeur de l'entrée DWORD AllowPasswordExport de la clé HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA à 1.

Attention
L'édition du registre Windows dépasse les standards de sécurité, toujours sauvegarder celui-ci avant toute modification

1.5.b Initialiser ADMT en lançant une simulation de migration de groupes globaux

avant de lancer ADMT pour la première fois effectuer les taches suivantes :

•  Créer un groupe local source_domain$$$ dans le domaine source. Celui-ci servira à l'audit et la migration de SID
•  Dans le registre, créer la valeur de l'entrée DWORD TcpipClientSupport dans HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA avec une valeur de 1
•  Activer la stratégie d'audit de gestions des utilisateurs et groupes sur les domaine sources et cible.

Initialiser ADMT en lançant un test de migration des comptes de groupes avec l'option de migration de l'historique SID. Voici le tableau des paramètres à entrer :

•  Quand l'assistant aura fini son exécution, vérifier les log afin de contrôler les erreurs éventuelles.

1.5.c Identifier les comptes de service

Certains contrôleurs et serveurs membres exécutent des applications en tant que service en utilisant un compte de service (c'est le cas d' Agresso ou de Saratoga par exemple). Ce compte de service est un utilisateur standard mais qui dispose de l'autorisation Log on as a service . Nous allons tenter ici de les identifier.

ADMT ajoute ses comptes dans la liste des comptes de service ne s'exécutant pas sous le compte system local. Ils doivent être mis à jour après leur migration. Pour les identifier, suivre les étapes suivantes :

Dans l'assistant de migration des comptes de service, sélectionner les paramètres du tableau :

•  Lorsque l'assistant se termine, vérifier le fichier log. Ce fichier contient des informations sur les raisons d'un éventuel échec (par exemple RC=5 permissions non valides).