Conseils pour la migration Active Directory vers WS 2012 R2
jeudi 5 juin 2014 à 09:24I. Présentation
Cet article a pour objectif de mentionner les bonnes pratiques à suivre lorsque l’on souhaite migrer un environnement Active Directory vers Windows Server 2012 R2.
Ceci vous permettra de préparer votre migration dans les meilleures conditions possibles. Une migration est un projet à part entière, il faut veiller à bien tout préparer.
La procédure de migration complète ne sera pas décrite entièrement, il s’agit plutôt de conseils, de méthodes à utiliser, pour réaliser la migration dans les meilleures conditions.
Tout d’abord, migrer présente plusieurs avantages :
- Bénéficier du support de l’OS par Microsoft. Concernant Windows Server 2003, le support termine Juillet 2015).
- Passer à la virtualisation puisque Windows Server 2012 R2 gère très bien cette technologique, ainsi vous pourrez profiter des avantages d’une telle installation.
- Profiter des nouvelles fonctionnalités.
II. Prérequis matériel
Commençons par parler du serveur en lui-même. Il doit être certifié fonctionnel avec Windows Server 2012/2012 R2, ce qui peut se vérifier par la présence d’une étiquette sur le serveur.
Au niveau des attributions des ressources matérielles, Microsoft recommande 32 Go d’espace disque dur et 2 Go de RAM pour le serveur. Cependant les experts Active Directory de chez Microsoft recommandent plutôt 80 Go pour le disque dur et 8 Go de RAM.
Bien entendu, le processeur doit être compatible 64 bits puisque Windows Server 2012/2012 R2 est disponible exclusivement en version x64.
Si vous partez sur de la virtualisation, sachez qu’à partir de Windows Server 2012, il est possible de cloner un contrôleur de domaine à condition que l’hyperviseur gère le « VM-generationID ». Ce qui est le cas des dernières versions d’Hyper-V et de VMware.
III. Les différentes étapes
Un projet de migration d’Active Directory devrait se découper en 4 grandes étapes :
IV. Evaluation – Les bloqueurs potentiels
Il est important d’évaluer l’infrastructure actuelle avant d’envisager la migration, ceci dans le but d’identifier les bloqueurs potentiels. Ces bloqueurs n’empêcherons pas la migration mais pourront poser des problèmes suite à la migration. Il vaut mieux les identifier au préalable.
En général, tous les bloqueurs identifiés peuvent être contournés en paramétrant une GPO contenant certains paramètres spécifiques pour assurer la rétrocompatibilité.
A. Le chiffrement des comptes
Depuis Windows Server 2008 R2, le chiffrement DES/3DES des utilisateurs est désactivé par défaut. Si vous migrez depuis Windows Server 2000, 2003 ou 2003 R2 vous devez prendre cela en considération puisque ces OS utilisent le DES par défaut.
D’ailleurs, dans les options d’un compte, vous pouvez vérifier cela si l’option « Utiliser le chiffrement DES pour ce compte » est active ou non. Sinon, pour aller plus vite vous pouvez utiliser cette commande PowerShell sur votre annuaire :
Get-ADUser -filter * -Properties UserAccountControl | Where{($_.useraccountcontrol -band 2097152) -ne 0}Ou
dsquery * -filter "(UserAccountControl:1.2.840.113556.1.4.804 :=2097152)"
Si vous souhaitez réactiver le DES sur vos nouveaux contrôleurs de domaine, vous devez configurer ce paramètre de stratégies de groupe :
Paramètres Windows, Paramètres de sécurité > Stratégies locales > Options de sécurité > Sécurité réseau : Configurer les types de chiffrement autorisés pour Kerberos
Le chiffrement peut avoir un impact sur certaines applications codées en dur pour utiliser le DES ou 3DES, ce qui peut être le cas de certaines applications Java.
B. Compression des SIDs
Depuis Windows Server 2012, une nouvelle fonctionnalité permettant de compresser les SIDs est présente, et, activée par défaut. Cette compression permet de réduire la taille des tokens utilisés par Kerberos.
Certaines implémentations de Kerberos, comme ça peut être le cas sur des NAS ou Linux, ne supportent pas cette compression. Ainsi, cela peut poser des problèmes de compatibilité donc d’authentification.
Deux solutions :
- Désactiver la compression de SID uniquement pour le NAS, c’est-à-dire pour le compte utilisé par cette ressource.
- Désactiver la compression de SID sur l’ensemble de l’environnement. Attention cela requiert un redémarrage du contrôleur de domaine. Concernant le paramètre à modifier :
REG_DWORD : DisableResourceGroupsFields=1 HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kdc\Parameters
V. Evaluation – Ce qu’il faut évaluer
Voici quelques points important à prendre en compte lors de l’évaluation de votre infrastructure Active Directory.
- Vérifier la compatibilité des applications avec le système d’exploitation vers lequel vous migrez.
- Effectuer un inventaire des rôles et services installés sur les contrôleurs de domaine afin de déterminer s’ils doivent être réinstallés sur le nouveau serveur, rester sur le serveur actuel ou être assurés par un serveur différent. Il faut donc inclure la migration de ces services au projet de migration.
- Effectuer un état de santé de l’Active Directory.
VI. Commandes pour vérifier l’état de santé
Le dernier point cité précédemment mérite d’être détaillé car c’est un point incontournable dans l’évaluation de l’infrastructure en préparation à la migration.
A. Réplication de l’Active Directory
Afin de vérifier l’état de réplication de l’AD, on peut utiliser différentes commandes :
repadmin /replsummary : Déclenchera une collecte de données afin d’afficher un résumé de la réplication au niveau de la forêt.
repadmin /showrepl : Sur chaque DC, l’exécution de cette commande permet d’afficher l’état de la réplication lorsque le DC a tenté une réplication entrante pour la dernière fois.
Active Directory Replication Status Tool : Utilitaire disponible sur le site de Microsoft (Téléchargement), cet outil pratique et efficace permet de contrôler l’état de la réplication de l’ensemble des partitions de la forêt. Suite à une analyse, les erreurs trouvées vous seront indiquées.
Aperçu de l’application “Active Directory Replication Status Tool”
B. Réplication du SYSVOL
La réplication du SYSVOL peut être effectuée avec FRS ou DFSR, selon la version de Windows sous laquelle vous êtes et si vous avez déjà migré ou non le FRS vers DFSR.
Ultrasound : Cet outil fournit par Microsoft (Téléchargement) permet de surveiller et de dépanner la réplication via FRS
Sonar : Egalement pour FRS mais réservé aux systèmes d’exploitations Windows Server 2000 et 2003 (Téléchargement)
DFSRMon : Cet utilitaire permet de contrôler l’état de la réplication SYSVOL via DFSR sur votre domaine (Téléchargement)
C. La résolution de noms avec DNS
Le DNS est un élément indispensable dans un environnement Active Directory, il est important de vérifier qu’il soit en bonne santé lui aussi.
dcdiag /test:dns : Diagnostic du DNS concernant les enregistrements liés à l’Active Directory
Vous pouvez utiliser également l’utilitaire dnslint mais qui n’est pas présent sur toutes les versions de Windows. Par ailleurs, des tests de résolutions avec nslookup basiques peuvent être effectués en complément.
D. La base NTDS.dit
Ce fichier correspond à l’annuaire Active Directory, il en contient toutes les données. Il est préférable de vérifier l’état général de l’AD, pour cela l’Observateur d’événements doit être contrôlé afin de vérifier la présence éventuelle de messages d’erreurs.
Si vous migrez depuis Windows Server 2008 R2, vous devriez également faire une analyse avec le Best Pratices Analyzer qui peut vous remonter d’éventuels problèmes de configuration détectés.
La sauvegarde de l’état du système Active Directory
Comme vous sauvegardez régulièrement votre système (notamment capture instantanée de l’AD), vérifiez que vous disposez d’une sauvegarde grâce à la commande suivante :
repadmin /showbackup
Sans préciser de DC, la valeur localhost sera automatiquement ajoutée à la commande.
Exemple de résultat de la commande “repadmin /showbackup”
E. Les rôles FSMO
Utilisez la commande indiquée ci-dessous pour vérifier quel DC est maître d’opération pour chacun des rôles FSMO.
netdom query fsmo
Résultat de la commande “netdom query fsmo”
F. La synchronisation NTP
Vous pouvez vérifier l’état de la synchronisation NTP de votre contrôleur de domaine en utilisant cette commande :
w32tm /query /status
Résultat de la commande “w32tm /query /status”
Pour conclure sur cette partie, j’ajouterais que si vous avez des problèmes sur votre infrastructure actuelle, la migration ne les résoudra pas. C’est pourquoi il est intéressant d’effectuer tous ces tests au préalable afin de bien évaluer l’état actuel de votre infrastructure.
VII. Planifier la migration
A. L’architecture
Vous devez prévoir votre future architecture, il est important de déterminer une architecture de migration : Combien vais-je avoir de contrôleurs de domaine ? Vais-je avoir des contrôleurs de domaine en lecture seule ? Les DCs seront-ils virtualisés ? Etc.
Les réponses à ces questions vont vous permettre d’éviter certaines interrogations de dernières minutes, et, cela permettra de valider au préalable vos choix.
Vous devez également intégrer dans l’architecture les applications à tester, et, les autres rôles que doivent jouer vos serveurs afin de savoir quels serveurs les hébergeront.
B. Le retour arrière
C’est « triste à dire » mais vous devez préparer le retour arrière au cas où la migration ne se passerait pas du tout comme prévu… Pour cela prévoyez :
- Une sauvegarde l’Active Directory (Etat du système et Système)
- Une sauvegarde complète de votre disque avec une solution adéquat
- Une sauvegarde de la machine virtuelle (dans le cas de DC virtualisé)
Note : Pour la sauvegarde de l’état du système vous pouvez utiliser l’outil de sauvegarde fournit avec Windows Server.
De plus, il est préférable d’avoir :
- Un PRA de la restauration totale de la forêt (Plan de Reprise d’Activité)
- Prévoir une « Forest Recovery » qui pourrait être nécessaire dans certains cas (Exemples : Impossible d’ajouter un nouveau contrôleur de domaine, impossible de faire fonctionner la réplication entre les partenaires, compromission de l’environnement Active Directory, etc.)
VIII. Tester – Environnement de tests
Tester, tester et encore tester ! Pour préparer au mieux la migration, effectuez des tests sur un environnement complètement isolé de la production. Pensez à supprimer cet environnement à la fin des tests pour éviter toute communication avec l’environnement en production à l’avenir.
La méthode que je vous recommande pour la création d’un environnement de test est la suivante :
Restaurer la sauvegarde complète d’un contrôleur de domaine directement sur une machine physique ou au sein d’une machine virtuelle.
Une autre solution consisterait à ajouter un nouveau contrôleur de domaine à l’environnement de production, puis, à l’isoler dans un environnement de tests afin de le rendre autonome. On s’appuie réellement sur la production pour créer l’environnement de tests mais on ne vérifie pas l’état de la sauvegarde. De plus, il faudra réaliser un « metadata cleanup » sur les contrôleurs de domaine de production pour qu’ils « oublient » le DC dédié aux tests.
IX. Déployer – Préparer la migration
Etape décisive, le déploiement ! Cette partie référence quelques conseils et étapes intéressantes à suivre pour procéder à la migration et faire d’elle une réussite.
Le point suivante explique un début possible pour une migration, ensuite, une suite d’étape possible sera établie ce qui sera peut-être plus intéressant pour vous.
A. Bloquer la réplication
Il est possible de bloquer la réplication sortante sur un contrôleur de domaine, ceci dans le but d’effectuer des opérations de migration dessus sans affecter les autres contrôleurs de domaine tout le temps que la validation n’est pas effectuée.
Dans le cadre d’un environnement à 2 contrôleurs de domaine, sur le DC principal, empêcher la réplication sortante du schéma dans le but de vérifier qu’elle soit bien effectuée localement. Pour cela on utilise la commande suivante :
repadmin /options dc1 +disable_outbound_repl
On peut vérifier la prise en compte de cette option avec la commande suivante :
repadmin /showrepl
Dans le cas d’un environnement plus conséquent, c’est-à-dire où il y a plus de 2 DCs. Choisir un second DC est désactivez la réplication sortante sur ce dernier, puis, depuis le DC principal initier une réplication manuelle pour vérifier la réplication des objets et des attributs.
B. Vérifier le mode fonctionnel de la forêt
Exécutez la commande Adprep /forestprep sur le contrôleur de domaine. Attention, si vous êtes sur Windows Server 2003 la commande ne pourra pas être effectuée pour une mise à jour vers 2012/2012 R2, vous devez passer par un intermédiaire sous 2008 R2 (adprep n’existe plus sur 2012).
Il est à noter que le fait de migrer vers 2012 R2 implique que le schéma passera en version 69, ceci peut se vérifier dans l’attribut « ObjectVersion » du schéma. Par exemple, en étant sous 2003 la valeur passera de 31 à 69 mais par contre comme on a désactivé la réplication sortante les autres DCs ne seront pas affectés pour le moment. Cela offre un point d’assurance supplémentaire dans le cas où l’on souhaite revenir en arrière en cas de problème.
Vérifier s’il y a des problèmes… Si tout est OK on peut ouvrir à nouveau la réplication vers les autres DC mais avant cela on fait une réplication manuelle :
repadmin /replicate dc2 dc1 cn=schema,cn=configuration,dc=it-connect,dc=fr /force
On obtient le résultat : Sync from DC1 to DC2 completed successfully
Suite à la réplication, l’attribut ObjectVersion doit être passé également à 69 sur le second contrôleur de domaine.
Dans le cas d’un environnement très grand, il est intéressant de créer un script PowerShell pour vérifier la valeur de certains attributs de façon automatique. Vous gagnerez du temps, beaucoup de temps.
Enfin, on réactive en automatique la réplication sur le DC « principal » (- à la place de +) :
repadmin /options dc1 -disable_outbound_repl
Afin de forcer la réplication des DCs on utilisera la commande suivante :
repadmin /syncall /e
Cette procédure permet de vérifier la mise à jour du schéma locale sur le maitre de schéma et la mise à jour du schéma via une réplication sur le partenaire.
C. Les étapes du déploiement du premier contrôleur de domaine
Voici les étapes qui peuvent être suivies pour déployer le premier contrôleur de domaine sous Windows Server 2012/2012 R2 au sein de votre environnement.
- Préparer et appliquer la stratégie de groupe (GPO) qui permettra d’assurer la compatibilité entre votre environnement actuel et votre futur environnement. Configurez la stratégie de groupe en adéquation avec les résultats de vos tests.
- Installation du rôle Active Directory Domain Services (ADDS) et promotion en tant que contrôleur de domaine via le Gestionnaire de serveur (dcpromo n’existe plus). Pour promouvoir le premier contrôleur de domaine sous Windows Server 2012/2012 R2, le niveau fonctionnel de la forêt doit être au minimum « Windows Server 2003 ».
- Vérifier l’état de santé de votre infrastructure suite à la promotion du nouveau DC (réplication, DNS, numéro de version du schéma, vérifier les journaux, etc.)
- Vérifier et valider le bon fonctionnement de l’authentification
- Vérifier et valider le bon fonctionnement des applications tierces
- Sauvegardez votre contrôleur de domaine et votre annuaire avec NTDSutil
Ces étapes peuvent être répétées pour chacun des contrôleurs de domaine à intégrer.
D. Les étapes de la finalisation du déploiement
Avec nostalgie, vous devez rétrograder vos anciens contrôleurs de domaine, ils ont fait leur temps !
Remarque : Une fois tous les nouveaux DCs promus sous 2012/2012 R2, il est déconseillé de rétrograder les anciens DCs tous en même temps. Il vaut mieux en laisser un ancien actif le temps de finaliser la phase de transition, notamment si certaines applications continuent d’aller aléatoirement vers l’ancien DC et continue de fonctionner grâce au fait que l’ancien DC soit toujours présent. Pour vérifier vers quel contrôleur de domaine pointe une application pour l’authentification, utilisez un outil d’analyse réseau.
- Rétrograder les anciens DCs
- Augmenter le niveau fonctionnel du domaine et de la forêt
- Vérifier le bon fonctionnement des applications
- Activer et exploitez les nouvelles fonctionnalités. Par exemple : migrer la réplication SYSVOL de FRS vers DFSR, authentification plus forte (Authentication Mechanism Assurance), ADMX à la place des ADM, etc.
- Mettre à jour les différentes procédures concernant votre environnement, notamment le PRA
X. Liens utiles
Ci-dessous se trouvent une liste de liens contenant des informations utiles et pouvant vous aider dans votre migration !
- Windows Server 2012 – Best Practice Analyzer
- Windows Server : Capture instantanée de l’Active Directory
- Apprivoiser les services Active Directory
- Configurer le NTP avec w32tm
- ADMX Migrator : Convertir les ADM en ADMX
- Ajouter un contrôleur Windows Server 2012 dans un domaine existant
- Configuration requise pour Windows Server 2012 R2
- Les niveaux fonctionnels Active Directory
- Authentication Mechanism Assurance for AD DS
- Compression des SIDs sous Windows Server 2012
Je conclurais en disant qu’il faut faire de nombreux tests, bien évaluer son infrastructure et très bien se documenter pour éviter les surprises lors de la migration d’un Active Directory.
Vous aussi donnez vos conseils en laissant un commentaire sur cet article et donnez votre avis sur ce dernier !
