Avant d'aborder le sujet de l'Active Directory Forest Recovery, essayons de passer en revue les différents scénarios de récupération et de déterminer dans quelles situations chacun d'entre eux s'applique.
(Remarque : si vous êtes ici uniquement pour le titre, descendez directement en bas de l'article).
La première, et la plus simple, est la récupération d'objets.
La récupération d'objet désigne le processus consistant à récupérer un ou plusieurs objets qui ont été supprimés. Cela peut résulter d'une erreur humaine, d'une défaillance technique (une solution de gestion des identités qui désactive par erreur un utilisateur) ou d'une faille de sécurité, à laquelle nous consacrerons une section distincte.
La récupération d'objets est relativement facile, notamment grâce à la fonction de corbeille introduite par Windows 2008 R2 (plus d'informations à ce sujet ici : https://technet.microsoft.com/en-us/library/dd379542(v=ws.10).aspx).
La deuxième étape, qui n'est pas très compliquée non plus, concerne la restauration du serveur.
Imaginons que vous disposiez d’un contrôleur de domaine sur deux (au moins ; si ce n’est pas le cas , veuillez en promouvoir un deuxième immédiatement ) et que ce serveur subisse une panne matérielle. Quelle est la solution la plus simple pour restaurer un contrôleur de domaine ? Eh bien, il suffit de le promouvoir ! Comme il n'y a aucune différence entre un contrôleur de domaine et un autre, la restauration d'un serveur se résume simplement à promouvoir ce contrôleur de domaine spécifique à partir de zéro. Vous souhaiterez bien sûr conserver le même nom et la même adresse IP, mais vous disposez, je l'espère, d'un guide de configuration ; vous devriez donc savoir comment configurer un contrôleur de domaine à partir de zéro.
Le troisième est la récupération de domaine.
La restauration de domaine permet de restaurer un seul domaine au sein d'une forêt entière. Quelles peuvent en être les causes ? Cela peut commencer par une erreur humaine, mais ces incidents sont généralement dus à des pannes matérielles multiples (tous les contrôleurs de domaine de DomainX sont hors service, ou s'il n'en reste qu'un seul), à des suppressions massives dans la base de données ou à des problèmes de configuration. La restauration de domaine est un sujet un peu difficile à expliquer en un seul article de blog, mais j'aborderai certainement la question de la restauration d'un domaine unique dans un environnement de forêt dans un prochain article.
C'est là que les choses se compliquent
Récupération d'attributs
Imaginons que vous ayez accidentellement exécuté un script qui a modifié ou supprimé le contenu de l'attribut « prénom » de tous les utilisateurs. Comment pourriez-vous remédier à cela ? Eh bien, vous pourriez opter pour une restauration des objets pour tous les utilisateurs, mais vous risqueriez alors de passer à côté de certaines modifications, selon le moment où la sauvegarde a été effectuée.
Imaginons maintenant que cela ait été le fait de quelqu'un d'autre, par exemple un bug dans un logiciel, ou qu'une faille de sécurité au sein de l'entreprise ait permis à un pirate de corrompre votre contenu ?
Pour l'instant, il n'existe pas de solution parfaite à ce problème. Vous pourriez utiliser des instantanés et vous en servir comme référence, mais transférer le bon contenu de l'instantané vers la base de données active pourrait facilement se transformer en un véritable cauchemar avec ldifde (sans compter que déterminer les différences entre l'instantané et la base de données active n'est pas non plus une mince affaire).
Et mon préféré : Active Directory Forest Recovery
Pour cela, je vais m'appuyer sur le livre blanc de Microsoft intitulé « Forest Recovery » : https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-forest-recovery-guide.
Et citez la section intitulée «Déterminer quand procéder à la restauration forestière » :
Tous les contrôleurs de domaine ont été logiquement corrompus ou physiquement endommagés au point que la continuité des activités est impossible ; par exemple, toutes les applications commerciales qui dépendent d'AD DS ne fonctionnent pas.
Un administrateur malhonnête a compromis l'environnement Active Directory.
Un attaquant exécute intentionnellement ou un administrateur exécute accidentellement un script qui corrompt les données dans la forêt.
Un pirate ou un administrateur étend accidentellement le schéma Active Directory en y apportant des modifications malveillantes ou contradictoires.
Aucun des contrôleurs de domaine ne peut répliquer avec ses partenaires de réplication.
Aucun contrôleur de domaine ne peut modifier AD DS.
Les nouveaux contrôleurs de domaine ne peuvent être installés dans aucun domaine.
Comment faire ? Eh bien, les pages 29 à 54 du livre blanc décrivent en détail les étapes à suivre.
