Thursday, December 21, 2017

Active Directory : récupération de la forêt (FR) - 1 - Introduction

English summary: I'm starting a series of blog posts about the "forest recovery", one of the more complex Active Directory recovery scenarios. I start with a descripton of my test network. Indeed, one of the primary ingredients for a successful forest recovery is solid documentation. We should know the configuration of our domain controllers and our Active Directory topology. Later steps include a full server backup of one of the domain controllers and an attempt to recovery the forest from this backup. Note that the other domain controllers will most likely have to be reformatted and rebuilt (especially if malicious activity is the cause for forest recovery) although other scenarios are possible.

***  

Dans ce texte, et les textes à suivre, j'aborde un des sujets les plus complexes à propos d'Active Directory : la récupération d'une forêt entière. Certes, il est rare qu'on soit obligé de recourir à une telle opération et la plupart des administrateurs n'en ont jamais fait l'expérience. Cependant, Microsoft nous recommande de préparer pour ce scénario un plan d'action, adapté à notre environnement, et de le répéter au moins une fois par an.

Il faut préciser d'emblée qu'il s'agit d'une opération extrême (surtout si nous comptons de nombreux contrôleurs de domaine) et que nous ne devrions l'entreprendre qu'après avoir consulté l'Assistance technique de Microsoft directement. Selon le guide publié par Microsoft, la récupération d'une forêt entière ne devrait être tentée qu'en dernier recours.

Voici un lien vers l'ensemble de la documentation (en version anglaise originale) :

Active Directory Forest Recovery Guide


***


Mais cette opération à quoi se résume-t-elle exactement ?

Dans certaines circonstances, nous pourrions être amenés à restaurer un seul contrôleur de domaine à partir d'une sauvegarde jugée fiable. De toute évidence, l'existence d'une telle sauvegarde est cruciale. Ensuite, nous supprimerions tous les autres contrôleurs de domaine et les rebâtirions à partir de zéro. En voilà donc les grandes lignes. Nous verrons les détails plus tard. Mais on comprend tout de suite la magnitude d'une telle opération pour une société avec des dizaines, voire des centaines de contrôleurs de domaine.

Et quelles sont ces circonstances ? Voilà quelques exemples (d'autres se trouvent dans la documentation citée plus haut) :

  • Corruption de la base de données de tous les contrôleurs de domaine.
  • Piratage des contrôleurs de domaine.
  • Échec catastrophique d'une mise à niveau du schéma (extrêmement rare mais le recours préféré est un plan de récupération solide - plutôt que la désactivation de la réplication lors de la mise à niveau).

Best Practices for Implementing Schema Updates or : How I Learned to Stop Worrying and Love the Forest Recovery

(Comme d'habitude, la plupart de la documentation est en anglais. Quoi qu'il en soit, remarquez bien les liens vers d'autres sources dans l'article).


Parmi les ingrédients pour une récupération réussie :

  • Une sauvegarde valable.
  • Un DVD d'installation ou un fichier .iso pour le système d'exploitation en question. On fait démarrer le serveur avec ce média et amorce le processus de récupération.
  • Configuration des contrôleurs de domaine (documentation avec carte de la topologie éventuellement (plus il y a de contrôleurs de domaine, plus c'est utile)). 
  • Mot de passe DSRM (mode de restauration des services Active Directory).
  • Informations de connexion d'un administrateur de domaine, de préférence le compte administrateur par défaut. Du point de vue de la récupération, ce compte ne devrait pas être désactivé bien que cela se discute du point de vue de la sécurité. En effet, les tentatives de connexion infructueuses ne peuvent pas verrouiller ce compte et un pirate pourrait, en principe, tenter de se connecter sans cesse. Il vaut sans doute mieux doter le compte d'un mot de passe fort et surveiller de près les tentatives de connexion avec un bon outil d'audit.
  • DNS intégré à Active Directory. Ce n'est pas une obligation mais la mise en oeuvre d'une autre sorte de DNS risque de compliquer la récupération de manière considérable. La documentation suppose d'ailleurs que DNS s'intègre à Active Directory.
  • Des contrôleurs de domaine avec l'interface graphique. Il est possible de récupérer une forêt ne comprenant que des contrôleurs de domaine à interface minimale (Server Core) mais c'est plus complexe et la documentation ne traite pas ce scénario.
  • Une forêt à un seul domaine est le plus facile à récupérer et en particulier pour ce qui concerne les catalogues globaux. Contrairement au scénario pour une forêt à multiples domaines, nous n'avons nul besoin de supprimer le catalogue global existant après la récupération du premier contrôleur de domaine. La documentation fournit plus de détails sur le pourquoi de cette nécessité.

Remarque : je crois comprendre qu'il faut préférer les sauvegardes du serveur entier aux sauvegardes de l'état système. En effet, Microsoft ne prend pas en charge la restauration de l'état système à un autre contrôleur de domaine, voire le même contrôleur de domaine après une réinstallation du système d'exploitation (OS). 


Notre configuration

Nous ne pouvons pas le dire assez : une bonne documentation est un des ingrédients pour une récupération réussie. Dans les lignes suivantes, je fournis en guise de documentation une description de mon banc d'essai.
  • Nous avons une forêt à un seul domaine, ce qui est (depuis un bon moment) la topologie Active Directory que recommande Microsoft.
  • Nous avons trois contrôleurs de domaine exécutant Windows Server 2008 R2 SP1 :
  1. DC5 - 10.8.1.5
  2. DC6 - 10.8.1.6
  3. DC7 - 10.8.1.7
  • Le masque de sous-réseau est /8 ou 255.0.0.0
  • Je ne donne pas ici la passerelle par défaut mais c'est un paramètre à inclure dans la documentation.
  • Quant aux paramètres de serveur DNS, le premier désigne l'adresse IP d'un autre contrôleur de domaine et le second l'adresse IP du contrôleur de domaine en question (sa propre adresse IP). Cette configuration fait l'objet de discussions sur les forums consacrés à Active Directory. D'autres choix sont possibles.
  • Notre niveau fonctionnel de la forêt et du domaine (FFL/DFL) sont tous deux à Window 2008 R2.
  • DC5 tient tous les rôles dits "FSMO".
  • Tous les contrôleurs de domaine sont serveurs DNS (DNS intégré à Active Directory).
  • Les redirecteurs sont des serveurs OpenDNS : 208.67.220.123 et 208.67.222.123

Remarque : quand notre DNS s'intègre à Active Directory, les zones sont bel et bien répliquées entre contrôleurs de domaine. Il n'en va pas de même pour les paramètres des serveurs. Il faut les documenter et éventuellement les rétablir à la main.

  • Chaque contrôleur de domaine est "catalogue global" (GC).
  • DC5 tient tous les rôles dits "FSMO".
  • Nous utilisons DFSR pour la réplication des partages NETLOGON et SYSVOL.
  • Nous sauvegardons nos GPO vers un dossier local, lui-même sauvegardé lors des sauvegardes du serveur entier. Cela peut sembler superflu mais je l'ai vu recommander quelque part (une source fiable).
  • Les serveurs sont "activés" (licence d'essai de 180 jours).
  • Les mises à jour (Windows Updates) sont complètes au moment où j'écris ces lignes.
  • Si nous utilisons un certificat tiers (Verisign, Digicert, etc.), nous devrions en tenir compte. Il serait compris dans une sauvegarde entière du serveur mais si nous devions rebâtir d'autres contrôleurs de domaine (cas tout à fait probable dans une récupération de forêt) nous devrions en avoir un exemplaire sous la main. Une option : l'exporter du serveur qui fait l'objet d'une restauration complète.


Les étapes à suivre (démonstration et détails dans les "chapitres" à venir)

  1. Effectuer une sauvegarde de serveur entier d'un de nos contrôleurs de domaine.
  2. Restaurer le serveur entier sur le matériel même (Bare Metal Restore - BMR).
  3. Faire une restauration d'autorité du SYSVOL.
  4. Nettoyer les métadonnées des contrôleurs de domaine que nous n'allons pas restaurer.
  5. Rajouter ces contrôleurs de domaine à la forêt après une réinstallation du système d'exploitation.



No comments:

Post a Comment