Dans un environnement serveur Microsoft, perdre son annuaire Active Directory, c'est risquer de tout perdre. Plus d'annuaire et c'est l'ensemble du fonctionnement des services de vos domaines Windows qui s'effondrent. Autant dire que pour garantir la continuité d'exploitation de votre SI, il est essentiel de disposer d'un plan de sauvegarde et surtout de restauration d'Active Directory (AD).
Contrairement à la plupart des autres applications du réseau, Active Directory est une application distribuée. L'annuaire est distribué sur plusieurs contrôleurs où serveurs et, par défaut, chaque contrôleur de domaine a une copie complète de l'annuaire et la capacité de le modifier (NDLR : ceci ne concerne pas les nouveaux RODC - Read Only Domain Controlers. Notez aussi que cet article traite du cas de réseaux de taille moyenne. Si votre réseau est plus vaste et que vous avez plusieurs domaines ou des "forêts" multiples, les principes sont identiques, même si les détails peuvent varier). Par conséquent, pour vous garantir de la perte du contenu de l'annuaire, il faut assurer la sauvegarde - et la restauration - d'au moins un des contrôleurs de domaine. En revanche, si vous voulez être capable de restaurer n'importe quel contrôleur, vous aurez à les sauvegarder tous.
Une application pas tout à fait comme les autres
Sauvegarder AD signifie capturer l'état du système, un ensemble de données systèmes qui inclut la base de données Active Directory, les journaux associés et les dossiers de transaction, de registre, les informations de configuration COM +, les fichiers de démarrage, le volume système SYSVOL, les informations de certificats électroniques (si vous utilisez les services de certificats), ainsi que quelques fichiers systèmes additionnels.
La sauvegarde de l'annuaire peut s'effectuer avec les outils gratuits fournis par Microsoft dans Windows 2000, 2003 et 2008. Vos outils de sauvegarde seront sans doute également en mesure de capturer un état du système.
Il est important de se rappeler que ce n'est pas parce que vous êtes capable de capturer l'état du système, que vous pourrez le restaurer. Exemple extrême, si vous avez un petit domaine et que vous avez co-localisé votre contrôleur de domaine sur le même serveur que votre logiciel de sauvegarde, la restauration risque d'être très difficile. La solution passant par l'usage de logiciels d'imagerie de disque (genre Ghost) ne vous aidera pas davantage : Active Directory ne peut être sauvegardé de cette façon, à moins que vous n'arrêtiez chaque contrôleur avant de prendre une image système. Sans parler du casse-tête pour remettre l'ensemble en marche...
Bien définir sa stratégie en cas d'incident sur un contrôleur de domaine
Il est donc important de prendre un peu de recul et de vous demander comment vous aller pouvoir restaurer un contrôleur de domaine ? Dans la pratique, la meilleure réponse est de se mettre dans des conditions où vous n'aurez jamais à effectuer ce genre d'opération. Ainsi, si vous avez déployé AD dans les règles de l'art (avec deux ou plusieurs contrôleurs de domaine AD), le besoin de restaurer un contrôleur de domaine dégradé ne devrait même pas se présenter. Dans la plupart des cas, il suffira de réinstaller un serveur propre, de le promouvoir comme contrôleur de domaine et de laisser AD répliquer automatiquement ses données vers le nouveau serveur. Même en ces temps d'informatique verte et d'économies d'énergie, nous vous recommandons fortement de considérer ceci comme votre "Plan A" : quand un contrôleur AD est perdu, ne vous inquiétez pas pour sa restauration. Rebâtissez un serveur stable, avant de le promouvoir comme contrôleur de domaine pour revenir à l'état initial (une fois bien sûr la réplication AD achevée). Bien sûr, ce conseil est valide aussi bien dans l'univers physique que dans un datacenter virtualisé (la reconstruction d'une image serveur propre n'en sera que plus rapide).
Définir une stratégie, la tester et la documenter
La seule exception porte sur les rôles FSMO (Flexible Single Master Operation) : ces derniers ne basculent pas automatiquement sur un autre serveur AD. Ces rôles doivent être assignés manuellement par l'administrateur à un contrôleur de domaine spécifique. La bonne nouvelle est que les rôles FSMO ne sont pas forcèment critiques pour l'exploitation d'un domaine et peuvent rester hors ligne pendant que vous décidez quoi faire d'eux pour quelques heures. Par exemple, le rôle de maître de schéma FSMO est uniquement utilisé lorsque vous mettez à jour votre schéma, une opération qui ne se produira que quelques fois par an. Le rôle FSMO d'émulateur PDC est plus critique, car il contribue à assurer que toute modification de mots de passe est immédiatement répercutée à l'ensemble des contrôleurs du domaine.
Prenez donc votre temps et déterminez avec précision ce que sera votre stratégie de sauvegarde et de restauration en cas de chute d'un contrôleur AD. Veillez aussi à tester votre plan en simulant un échec ou l'indisponibilité d'un contrôleur AD (pour cela montez par exemple une configuration virtuelle de test). Et, lors de ce test, ne manquez pas de prendre des notes détaillées, ce qui pourrait vous éviter de coûteuses erreurs à 3 heures du matin en cas d'un incident sur votre annuaire.
Joel Synder est associé chez Opus One, un cabinet de conseil en informatique américain spécialisé en sécurité et en messagerie.
En complément :
Toute reproduction ou représentation intégrale ou partielle des pages publiées sur ce site, faite sans l'autorisation de l'éditeur est illicite et constitue une contrefaçon. LeMagIT s'engage à respecter la confidentialité des données personnelles conformément à la loi 78-17 du 6 janvier 1978. LeMagIT n'assume aucune responsabilité de type éditoriale sur les commentaires publiés sur ce site, la mise en ligne n'étant soumise à aucun contrôle à priori. La fréquentation de ce site est certifiée OJD.
Tous les services du MagIT sur