Active Directory, Armageddon, exemple de sinistre

Cet exemple s’appuie sur un cas réel que j’ai traité il y a environ un an. Il était facile de discerner l’erreur de conception flagrante de cette configuration. Le domaine racine avait un seul DC. J’ai été appelé lorsque l’unique DC du domaine racine est tombé en rade et que le personnel IT n’a pas pu le récupérer.

Certes, il y avait un disque RAID 5 mais, par un coup du sort, les informaticiens ont perdu deux disques de la baie. Pour aggraver encore les choses, la sauvegarde était vieille de 11 mois. Autrement dit, la situation était carrément désastreuse !

Un domaine racine avec un seul DC a provoqué un désastre.

Le domaine enfant avait tous les comptes utilisateur et, chose intéressante, il n’y a pas eu de pannes pour les utilisateurs et aucune réclamation. J’ai d’abord pensé à des objets persistants, mais comme il n’y avait pas d’autres DC, il ne pouvait pas y avoir d’objets persistants sur le domaine. En revanche, il pouvait y avoir des GC sur le domaine enfant.

SOLUTION : Le plan d’action suivant a été élaboré :

1.   Définissez la durée de vie d’objets fantômes (TSL) sur 365 jours afin de ne pas courir le risque d’ajouter des objets persistants. Pour ce faire, utilisez l’outil ADSIEdit et modifiez l’attribut TSL à l’emplacement suivant :

cn=Directory Service,cn=WindowsNT,cn=Services,cn=Configuration, dc=mycomain,dc=com

2. Restaurez la sauvegarde sur le DC du domaine racine.
3. Paramétrez l’heure système sur le DC du domaine de forêt à la date/heure actuelle.
4. Définissez la valeur 1 pour StrictReplicationConsistency sur tous les DC.
5. « Rétrogradez » (demote) le GC sur le domaine enfant vers un DC.
6. Effectuez un contrôle d’état :
a. Journaux d’événements.
b. Validez la confiance.
c. Connectez-vous à partir d’une machine du domaine racine au moyen d’un compte du domaine enfant et vise versa.
d.   Ajoutez des utilisateurs + sites tests sur chaque domaine et vérifiez s’ils sont répliqués vers tous les DC.
7. « Rétrogradez » (demote) le GC sur le domaine enfant vers un DC.
8. Laissez la réplication se dérouler et mettre à jour le DC racine.
9. Effectuez la promotion d’au moins un DC en GC.
10. Vérifiez la présence d’erreurs au niveau des journaux d’événements.
11. Créez un deuxième DC pour le domaine racine.
12. Définissez la valeur 180 jours pour le TSL (minimum).
12. Sauvegardez tous les DC.

En fait, nous avons effectué toute cette procédure en premier lieu dans un laboratoire. En utilisant les sauvegardes courantes des DC de domaine enfant et l’ancienne sauvegarde du DC de domaine racine, nous avons reproduit l’environnement. Ensuite, nous avons exécuté la procédure décrite ci-dessus. Le contrôle d’état dans l’environnement de test a en fait remonté quelques erreurs DNS (non liées à cette procédure), de sorte que nous avons corrigé ces erreurs et d’autres problèmes dans l’environnement de production. A ce stade, nous étions confiants dans le fonctionnement de la restauration et tout a fonctionné sans incidents. La chose intéressante est que nous avons effectué l’opération pendant les heures de bureau et qu’il n’y a eu aucune interruption ou réclamation de la part des utilisateurs.

Il est facile de provoquer des sinistres AD, mais il n’est pas toujours aisé de les résoudre. Il est important que tout administrateur AD soit au fait des signes avant-coureurs et fasse attention aux journaux et rapports. Soyez vigilants et évitez les sinistres, en espérant que les conseils de cet article vous y aideront !

Sécurité et Gestion Active Directory, pour aller avec @ITPROFR :

1. Techniques de cartographie AD avec BloodHound · iTPro.fr
2. Une plongée dans le schéma AD · iTPro.fr
3. Les fondements de la sécurité Active Directory · iTPro.fr