Etude réalisée en 04/2010
Préparation et migration des domaines « mad.mir » et « company.lan » vers « nelite.fr » (Guillaume)
Préparation et migration des domaines « mad.mir » et « company.lan » vers « nelite.fr » (Guillaume)
Sommaire
1
Migration du domaine « mad.mir » et « company.lan »
vers le domaine « nelite.fr »
1.1 Présentation
et objectifs de la migration
Les
domaines « mad.mir » et « company.lan » vont disparaitre
pour laisser place au nouveau domaine « nelite.fr ». Nous aurons une
architecture cible mono-forêt/mono-domaine. Une migration inter-forêts des
objets sera donc à effectuer. Ici, les ressources seront migrées après les
utilisateurs (non détaillé dans ce document), il faudra donc qu’ils conservent leurs droits sur le domaine
source. Nous donnerons une attention particulière pour qu’il soit possible, en
cas d’erreur lors de la migration, de revenir en arrière.
Voici une présentation du contexte ainsi qu’un schéma permettant de visualiser la situation
initiale et la situation visée :
Après une étude des besoins et
diverses propositions d’infrastructure, une entreprise à valider la
mutualisation de l’ensemble de son infrastructure sur un site. Les principales
raisons ont été la réduction du coût d’administration du système d’information
mais également permettre l’évolution de l’infrastructure tout en proposant une
solution pérenne (car il sera possible de basculer en multi-domaine si les
besoins venaient à évoluer) et capable d’accueillir les nouvelles technologies
Microsoft dans les meilleurs conditions.
De ce fait, une
restructuration puis une migration Active Directory a été validée afin d’élever
le niveau fonctionnel de base sous 2000 pour le site 2 et 2003 pour le site 3
vers 2008 sur le site 1.
Pour
une meilleure compréhension, le domaine
source est « mad.mir » et/ou « company.lan ». Le domaine cible est « nelite.fr ».
1.2 Pré-requis
Cette procédure part du principe que les éléments suivant
sont en productions et configurés.
·
Installation
du nouveau domaine cible sous Windows server 2008 x64, avec une
configuration réseau permettant la communication avec les domaines sources.
·
Installation
d’une machine Windows server 2008 x64 pour l’installation du serveur PES (Password
Export Server) et configuration réseau permettant la communication avec
l’ensemble des serveurs.
·
Installation
et configuration des serveurs DNS pour qu’ils puissent résoudre les noms de
domaine internes.
·
Le niveau fonctionne du domaine « mad.mir »
doit être élevé en « mode natif »
Les
pré-requis étant fixés, tous les éléments sont réunis pour débuter la
préparation à la migration.
1.3 Préparation à la migration point par point
1.3.1 Création
des comptes de migration
Lors de la migration, nous
devons utiliser les droits du groupe « Administrateurs du domaine »
(ou tout autre compte ayant les possibilités de création/modification des unités
d’organisations dans le domaine source et dans le domaine cible). Il n’est pas
conseillé d’utiliser le compte « Administrateur » car ses droits ne
sont pas limités, il fait partie du groupe ayant les droits sur l’entreprise. Il est donc
recommandé de créer un utilisateur qui fera partie du groupe
« Administrateurs du domaine ». Cette opération permet, en plus de
répondre aux bonnes pratiques Microsoft, d’avoir un utilisateur dédié à la
migration et qui sera distingué clairement dans les journaux d’évènements par
exemple.
Le nom du compte créé sera « adminmig »,
qui fera donc partie du groupe « Administrateurs du domaine » (un
compte sera créé dans le domaine cible mais également un par domaine source.)
Les comptes de migrations sont terminés, nous allons
continuer en abordant la mise en place de la résolution DNS inter forêt.
1.3.2 Mise
en place de la résolution DNS entre la forêt cible et les forêts sources.
Vous avez trois contrôleurs de
domaine avec le service DNS (Domain Name System) d’installé et de configuré. Le
but de la manipulation qui suit, est de résoudre les noms DNS de la forêt
« mad.mir » et « company.lan » depuis la forêt « nelite.fr »
et inversement.
Sur la forêt
« nelite.fr », il vous faut créer une zone stub de la zone « mad.mir ».
Dans notre cas, la zone stub permet de ne pas configurer de redirecteur et de
limiter les enregistrements transférés d’une forêt à une autre.
Remarque : La manipulation est identique pour
créer la zone stub de « company.lan ». Avant de configurer la zone
DNS du domaine « mad.mir », nous allons ajouter la zone stub « nelite.fr »
au domaine « company.lan ». Pour cela, refaites la même manipulation
décrite ci-dessus, mais en renseignant le nom de la zone stub « nelite.fr »
et le nom du serveur DNS qui héberge la zone.
A
présent, nous allons renouveler l’opération sur le domaine « mad.mir »,
mais cette fois en utilisant une zone DNS secondaire (car il est hébergé sur un
Windows 2000, hors la notion de zone stub apparait avec Windows 2003.)
Sur la forêt
« mad.mir », il vous faut créer une zone DNS secondaire de la zone « nelite.fr ».
Voici un schéma permettant d’avoir une vue d’ensemble des opérations
effectuées :
Vous pouvez désormais résoudre
des noms de domaines entre les différents domaines. Un simple test permet de le
confirmer. Effectuer un ping en utilisant le FQDN du serveur DNS cible depuis
l’un de vos deux serveurs sources. Passons à l’étape suivante qui est la
configuration des relations d’approbations.
1.3.3 Mise
en place des relations d’approbations
Notre
migration englobe trois domaines, par conséquent nous devons créer des règles
de sécurités permettant le dialogue de ces trois entités sans liens. La
solution, est la mise en place de relations d’approbations bidirectionnelles
(cette relation est justifiée par les besoins du client, car pendant la phase
de cohabitation les deux forêts devront pouvoir communiquer entre elles pour
fournir l’accès aux ressources des utilisateurs migrés).
Pour mettre en place une relation d’approbation entre deux
domaines («nelite.fr » et « mad.mir ») il faudra utiliser la
console « domaines et approbations active directory ». Il faudra
effectuer la même manipulation depuis le domaine nelite.fr pour le domaine
« company.lan ». Les comptes de migrations seront utilisés durant
cette étape.Pour vérifier le bon fonctionnement de la relation d’approbation, il faudra la valider cette dernière.
Il
est maintenant possible aux domaines sources de communiquer avec le domaine
cible et inversement. Mais aucun droit n’est configuré, c’est donc la prochaine
étape.
1.3.4
Mise en place de la Délégation
Sur le
domaine « mad.mir », il faut déléguer l’administration de l’unité
d’organisation ou sont positionnées vos utilisateurs au compte
« adminmig » du domaine « nelite.fr », pour que ce dernier ai
les droits nécessaires lors de la migration. Il faut répéter l’opération pour
le domaine « company.lan ».
Pour cela, se placer sur le domaine « mad.mir ». Lancer
la console d’administration « Utilisateurs et Ordinateurs d’active
directory ». Se positionner sur l’unité d’organisation et cliquer sur
« Délégation de contrôle ». De là, vous pouvez choisir un utilisateur
(effectué une recherche de « adminmig » sur le domaine « nelite.fr »).
Ensuite, vous donnez le maximum de droits à cet utilisateur sur l’unité
d’organisation. Faire de même pour le domaine « company.lan ».
L’utilisateur « adminmig » du
domaine cible a désormais l’accès aux objets de l’annuaire des domaines
sources. Cependant, il faut installer un logiciel permettant de réaliser la
migration.
1.3.5 Installer
l’outil ADMT (Active
Directory Migration Tool)
Microsoft
fournit un outil de migration gratuit du nom d’ADMT, actuellement dans sa
version 3.1 compatible avec Windows server 2008. Nous allons l’utiliser pour
effectuer des migrations d’utilisateurs, de comptes ordinateurs, de groupes, des
mots de passe etc.
ATTENTION :
Cet outil doit être installé sur un serveur tiers Windows server 2008 (qui n’a
pas les rôles d’annuaire). Ce serveur doit également faire partie du domaine
cible (qui pour rappel est « nelite.fr »).
La migration est actuellement possible,
toutefois le compte ne conservera pas l’accès aux ressources de son ancien
domaine. Ce qui n’est pas tolérable au vu des demandes du client. Nous allons
donc activer un paramètre pour régler ce problème.
1.3.6 Activer
l’audit sur les contrôleurs de domaine
Cette
étape est indispensable à la réussite du projet de migration. Une erreur
apparait si vous n’activez pas l’audit sur les contrôleurs de domaine. Voir le
chapitre « Erreurs fréquentes »
L’activation
de l’audit diffère entre Windows serveur 2008 et 2000. Cependant, dans les deux
cas vous devrez activer la stratégie « Auditer la gestion des comptes ».
Il vous
reste à créer un groupe local dans le domaine source (mad.mir) portant le nom Netbios
du domaine suivi de $$$, soit MAD$$$ dans notre cas. Ce groupe permet la prise
en charge de l’audit (ce qui est un pré-requis pour la migration de
l’historique SID. Ce paramètre est important car il permet de conserver les
droits et donc l’accès aux ressources du domaine source, demande formulé par le
client).
Il faut répéter cette opération pour le domaine
« company.lan ».
La migration des comptes objets est
disponible (avec pour les utilisateurs leurs SID), mais il reste un dernier
détail. La migration des mots de passe. C’est un élément important, car le
client souhaite que la migration soit la plus transparente possible pour
l’utilisateur. Pour résoudre ce problème nous allons installer un serveur
d’exportation des mots de passe.
1.3.7 Installer
le serveur d’exportation des mots de passe
Une
transparence totale est assurée pour l’utilisateur lors de la migration de son
compte. En effet, même si l’utilisateur sera basculé vers un nouveau domaine
nous conserverons son mot de passe (il sera néanmoins possible de migrer
l’utilisateur et de demander un changement de mot passe lorsqu’il se connectera
sur le nouveau domaine). Nous allons utiliser un logiciel fournis gratuitement
par Microsoft « Password Export Server » dans sa version 3.1.
De plus,
nous ajoutons de la sécurité (lors de la migration des mots de passe des
utilisateurs d’une forêt à l’autre) grâce à une clé de chiffrement.
1.3.7.1 Création
de la clé de chiffrement
Sur le serveur membre du domaine
cible, sur lequel ADMT est installé, exécuter la ligne de commande
suivante :
admt key
/option:create /sourcedomain:mad.mir /keyfile:C :\Key.pes
Cette ligne crée la clé de chiffrement dans le répertoire
C : qui est à copier sur le serveur d’exportation de mots de passe.
A noter que pour effectuer cette opération, le serveur
requière la prise en charge du chiffrement 128bits, composant installé de base
dans les systèmes d’exploitation à partir de Windows Server 2000 (à condition
d’avoir installé Internet Explorer 4.1 ou ultérieur).
1.3.7.2 Installation
du service d’exportation
L’exécutable
est à télécharger sur le site de Microsoft via le lien suivant : _http://www.microsoft.com/downloads/details.aspx?familyid=F0D03C3C-4757-40FD-8306-68079BA9C773&displaylang=fr
Lancer
l’exécutable téléchargé et renseigner le chemin de la clé de chiffrement.
Renseigner le compte « adminmig ». Une fois le
service installé, le serveur doit redémarrer.
Le serveur redémarré, il faut démarrer le service d’exportation
des mots de passe dans les services Windows. La manipulation doit être répétée
pour le domaine « company.lan ».
Tous les éléments sont réunis pour débuter
la migration. Nous prendrons en compte dès lors une phase de retour en arrière
sur chaque partie. Le client a clairement formulé cette demande dans le cahier
des charges.
1.4 Migration
pas à pas
1.4.1 Migration
des groupes locaux et globaux
Il est maintenant possible de
commencer la migration. Mais vous devez respecter un ordre bien précis. En
effet, Microsoft recommande de migrer les groupes globaux et de domaine locaux
avant d’entreprendre la migration d’utilisateurs. Cette recommandation permet
aux utilisateurs de conserver leurs dépendances vis-à-vis des groupes, mais
également aux différentes ressources de leur ancien domaine. Lors de la
migration, l’utilisateur aura deux SID, l’ancien (pour avoir accès à ses
anciennes ressources et un nouveau pour le nouveau domaine).
Pour effectuer une migration des
groupes, se placer sur le serveur tiers, où l’outil ADMT est installé et
sélectionner « l’outil de migration active directory ». Vous devez préciser l’assistant que vous allez
utiliser (dans notre cas, « migration des comptes de groupes »). Vous
devrez ensuite sélectionner le domaine source ainsi que le domaine cible.
Ensuite,
vous devez choisir le mode de saisi des groupes. Pour des raisons évidentes il
est préférable de sélectionner un fichier regroupant l’ensemble des groupes, au
format « .cvs ».
Vous avez différentes options à
l’étape suivante que vous devez sélectionner en fonction de vos besoins.
L’étape
suivante permet en cas d’erreur de ne pas migrer le groupe, ce qui permet de
revenir en arrière. Sélectionner « Ne pas migrer l’objet source si un
conflit est détecté dans le domaine cible ».
Cette tâche est à répétée pour
l’ensemble des groupes du domaine « company.lan »
1.4.2 Migration
des utilisateurs et des mots de passe
Pour
effectuer une migration des utilisateurs avec leurs mots de passe, se placer
sur le serveur tiers, où l’outil ADMT est installé et lancer ADMT.
Une
fois la console « Outil de migration Active Directory » lancé, sélectionner
« l’Assistant de migration des utilisateurs ». Vous devez renseigner
le domaine source « mad.mir » et le domaine cible « nelite.fr ».
Choisissez le même mode de saisi des utilisateurs que celui des groupes. Et
indiquer la migration du mot de passe de l’utilisateur. A présent, vous saisissez
les options de transition de compte (attention, conserver le SID pour que les
utilisateurs une fois migré sur le nouveau domaine puissent toujours accéder à
leurs ressources de l’ancien domaine).
L’étape
suivante permet en cas d’erreur de ne pas migrer le groupe, ce qui permet de
revenir en arrière (répondant au besoin du client). Sélectionner « Ne pas
migrer l’objet source si un conflit est détecté dans le domaine cible ».
Cette
tâche est à répéter pour l’ensemble des utilisateurs et des mots de passe du
domaine« company.lan ».
1.5 Point
sur la migration
La migration des groupes, des utilisateurs, des mots
de passe et des SID sont terminés. Pour compléter la migration, il faut migrer
les dossiers des comptes itinérants des utilisateurs des anciens domaines
« mad.mir » et « company.lan » vers « nelite.fr ». De
plus, il faut lancer le script (fournis par Microsoft) qui permet de remplacer
votre ancien SID uniquement par les nouveaux. Ces deux étapes permettent de
clôturer la migration, car vous pouvez maintenant couper les domaines sources.
Le serveur d’exportation des mots de passe n’est plus
utile, par conséquent vous pouvez supprimer cette machine.
1.6 Erreurs fréquentes :
1.6.1 DNS
Objet : Problème de chargement de la zone stub ou de la
zone DNS secondaire.
Cause : Vous n’avez pas autorisé le serveur DNS
primaire faisant autorité sur la zone à transférer sa zone vers un autre DNS.
Exemple :
1.6.2 Migration
des mots de passe
Objet : Problème de migration de mot de passe
d’utilisateur
Cause : Le service d’exportation de mot de passe n’est
pas disponible
Exemple :
Solution : Revoir la partie « 1.2.7 Installer le
serveur de d’exportation des mots de passe ».
1.6.3 Migration
du SID de l’utilisateur
Objet : Impossible de migrer le SID de l’utilisateur
Cause : L’audit n’a pas été activé sur l’un des
serveurs sources ou cible
Exemple :
Solution : Revoir la partie « 1.2.6 Activer
l’audit sur les contrôleurs de domaine »
1.6.4 Importation
de la clé de chiffrement
Objet : Impossible d’importer la clé de chiffrement
lors de l’étape « 1.2.7 Installer le serveur de d’exportation des mots de
passe ».
Cause : Vous utilisez ADMT depuis un DC.
Exemple : Un message d’erreur vous interdit d’effectuer
cette opération car vous n’êtes pas administrateur local de votre machine.
Solution : Installer ADMT sur un serveur membre du
domaine mais qui n’est pas DC. En effet, pour importer la clé il faut être
administrateur local, hors il est impossible d’obtenir ce status sur un DC.
2
Conclusion
Le
client a maintenant atteint ses objectifs de migration. Toutes les étapes de préparations
proposées ont permis de réaliser une migration intégrant les demandes du client
à moindre couts.
La mise en œuvre d’une
infrastructure mono-domaine/mono-forêt est optimisée pour les besoins du
client. Cependant, il faudra organiser et mettre en œuvre de la délégation pour optimiser au maximum le processus
d’administration en production et donner une réelle valeur ajouté à cette
infrastructure.
L’ensemble
des sources ont été récupéré sur le site de Microsoft. Le document « ADMT
v3.1 Guide: Migrating and Restructuring Active Directory Domains» a été la
référence sur la plupart des points techniques. Lien : _
http://www.microsoft.com/downloads/details.aspx?familyid=6D710919-1BA5-41CA-B2F3-C11BCB4857AF&displaylang=en.
Aucun commentaire:
Enregistrer un commentaire