> Tech > Active Director – Sinistre virtuel

Active Director – Sinistre virtuel

Tech - Par Renaud ROSSET - Publié le 19 septembre 2013
email

Dans une autre situation, un plan de reprise après sinistre parfaitement logique concernant 2 DC virtuels a été conçu et implémenté, puis a provoqué le sinistre.

Active Director – Sinistre virtuel

Dans ce cas, deux serveurs physiques étaient configurés avec chacun un DC virtuel (cf. figure 3). Par conséquent, le DC était en fait un disque dur virtuel (VHD), autrement dit un fichier sur le disque physique.

Figure 3. Une configuration avec deux serveurs physiques, chacun exécutant un DC virtuel.

Les informaticiens de l’entreprise réalisaient chaque nuit une sauvegarde sur l’hôte physique. Comme les fichiers VHD pouvaient être copiés et déplacés vers d’autres emplacements, l’administrateur pensait qu’il pouvait copier le fichier VHD de centre de données 1 (DC1) vers DC2 et le fichier VHD de DC2 vers DC1.

Ils répétèrent cette stratégie pour DC3 et DC4. Ainsi, au final, ils pensaient qu’en cas de défaillance de DC1, ils pouvaient restaurer ce dernier en copiant son fichier VHD à partir de DC2 (ou DC3 ou DC4) vers DC1 ou un nouveau serveur et restaurer l’activité de l’entreprise.

Ils ne sauvegardaient pas les DC au sein de leur propre OS, mais uniquement l’hôte physique. Notez que la restauration du disque dur virtuel (VHD) varie en fonction de votre logiciel de machine virtuelle (VM), mais telle n’est pas la question ici. Cette situation souligne les lacunes de la conception.

Satisfaits de la validité de leur plan, les administrateurs décidèrent de tester la reprise. Ils reproduisirent ce scénario en laboratoire. Pour cela, ils supprimèrent l’ensemble VM/VHD existants de DC1 et en créèrent un nouveau au moyen de l’ensemble VM/VHD de DC1 stocké sur DC2. L’opération échoua, mais cela ne fut pas visible d’emblée. La réplication semblait fonctionner, mais les mises à jour étaient absentes, et des collègues identifièrent d’autres anomalies.

Ils venaient de découvrir les effets d’un rollback d’USN, en restaurant Active Directory sur le DC1 au jour précédent. Cette approche n’est en rien erronée à condition de procéder correctement. Toutefois, les administrateurs de notre exemple ont violé quelques règles importantes :

• Ne restaurez en aucun cas un DC à partir d’une image instantanée (snapshot). Le VHD est une image instantanée, mais il existe d’autres approches possibles.
• Ne sauvegardez jamais un DC en sauvegardant le fichier VHD sur l’ordinateur hôte. Sa restauration est impossible.
• Sauvegardez systématiquement l’état système d’un DC virtuel (dans la VM proprement dite) au moyen d’un utilitaire de sauvegarde et de restauration « compatible avec Active Directory ». Cela réinitialise l’ID d’invocation de la base de données AD et conserve toutes les versions de la base de données synchronisées sur l’ensemble des DC.

Le rollback d’USN accidentel est difficile à détecter et il n’existe qu’un remède à cette situation : recréer le DC. Cette approche crée, en gros, un vide dans les transactions de base de données sur le DC restauré. Par conséquent, d’autres DC pensent que les transactions (ajout, modification et suppression d’un objet) ont été répliquées vers le DC problématique et ils ne les répliquent plus. Le DC interrompu ne possède pas les objets et ne recevra aucune notification pour les obtenir. Cela aboutit à une impasse.

SOLUTION : Pour prévenir ce sinistre, lisez l’article de Bases de connaissances Microsoft KB 875495. Vérifiez que vous comprenez bien les causes et effets d’un rollback d’USN accidentel et comment identifier la situation. D’autre part, suivez les règles exposées dans cet article et dans la Base de connaissances pour éviter la survenue de cette situation.

Téléchargez cette ressource

Sécuriser votre système d’impression

Sécuriser votre système d’impression

Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.

Tech - Par Renaud ROSSET - Publié le 19 septembre 2013