Restructuration Active Directory 2000/2003 vers 2008Sommaire

1 Restructuration du domaine « mad.mir » et « company.lan » vers le domaine « nelite.fr »

1.1 Présentation et objectifs de la migration

1.2 Pré-requis

1.3 Préparation à la migration point par point

1.3.1 Création des comptes de migration

1.3.2 Mise en place de la résolution DNS entre la forêt cible et les forêts sources

1.3.3 Mise en place des relations d’approbations

1.3.4 Mise en place de la Délégation

1.3.5 Installer l’outil ADMT (Active Directory Migration Tool)

1.3.6 Activer l’audit sur les contrôleurs de domaine

1.3.7 Installer le serveur d’exportation des mots de passe

1.4 Migration pas à pas

1.4.1 Migration des groupes locaux et globaux

1.4.2 Migration des utilisateurs et des mots de passe

1.5 Point sur la migration

1.6 Erreurs fréquentes

1.6.1 DNS

1.6.2 Migration des mots de passe

1.6.3 Migration du SID de l’utilisateur

1.6.4 Importation de la clé de chiffrement

2 Conclusion

1 Migration/Restructuration 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.

La migration compte différentes étapes présentées dans ce document, une phase d’audit, de

propositions d’infrastructure précède ce document. Cette exemple peut être adapté à votre

entreprise en fonction de vos besoins, merci de me contacter sur :

guillaume.arsicaud@nelite.com. En termes de logiciels et d’outils, le processus de migration est

gratuit.

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 :

Solution : Activer le transfert de zone, pour cela il faut faire un propriété sur la zone primaire et

dans l’onglet transfert de zone, spécifier les zones qui sont autorisées à recevoir un transfert de

zone.

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 : Un message d'erreur apparait "Impossible de vérifier l'audit et TcpipClientSupport sur les

domaines. La migration de l'identificateur SID sera impossible. Accès refusé."

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.