Deep dive : la sauvegarde Active Directory

La sauvegarde d’Active Directory est un élément crucial pour la pérennité de votre système d’information, que ce soit en cas de sinistre, de cyber-attaque ou parce que Gérard à encore supprimé le compte du RSSI il y a 3 mois… Cet article, dénué de toute prétention intellectuelle et au format SVCCL^[1], vous expliquera avec moult détails comment fonctionne la suppression d’objets dans la base de données Active Directory et comment vérifier que vous sauvegardez correctement votre annuaire.

^[1] SVCCL : Servez-Vous, C‘est Complètement Libre !

« tu pousses la sauvegarde un peu trop loin, Maurice ! »

Vous vous demandez sûrement le lien entre la punchline d’une publicité des années 2000 et notre sauvegarde. Et vous avez bien raison – ceci dit, mettez vous à la place de l’auteur qui cherche à trouver des titres racoleurs sur un sujet aussi drôle qu’une enclume est utile pour jouer du Jazz Manouche – mais je m’égare (de triage). Le lien, donc, est une histoire vécue. Une histoire qui, heureusement, eut un dénouement qui ne se solda pas avec un pic de nouveaux inscrits à pole emploi (je sais, le nom a changé, mais je suis vieux. Vive les PTT !).

Un matin, alors que les petits zozios pépiaient à tout va dans les branches de l’unique arbre qui trônait dans la cour, un ami découvre pour son plus grand déplaisir que tout son système d’information est inopérant. Une panne électrique ? Gérard qui a utilisé psExec ? Que nenni ! Un crypto ! 50 domaines Active Directory qui ne se voient plus, des clients qui appellent parce qu’ils ne peuvent plus ouvrir de session sur leurs serveurs de bureaux distants ni imprimer la lettre d’excuse pour l’absence du fiston au mariage du prince Albert ! Heureusement, les sauvegardes sont gérées selon la méthode recommandée : un petit appel à son prestataire et les bandes sont de retour – le long travail de restauration des systèmes est initié…

Mais (vous ne l’attendiez plus, celui-là !), voilà : lorsque les contrôleurs de domaine ont été relancés, les trois-quarts n’arrivent plus à charger la base de données AD (non, ce n’est pas la faute de Gérard) ; la base de données est corrompue, impossible de la récupérer… Que s’est-il passé ? Pourquoi les sauvegardes, pourtant testées à l’occasion d’un crash de production (c’est là leur tout premier, vous me suivez ?), n’ont-elles pas atteint l’objectif ? Que va dire Gérard en arrivant un Mars à la main ^[2] ? Tout simplement parce que la sauvegarde de l’AD doit être réalisé en créant un état « stabilisé » de la base de donnée, état que l’on ne peut pas obtenir avec certitude lorsque votre sauvegarde est un snapshot de machine virtuelle…

^[2] « un bon Mars et ça repart ! » – cette vanne a reçu un accueil mitigé, allez savoir pourquoi…

Le souci, à mon niveau, c’est que lorsque j’interviens chez mes clients et que je jette un œil à la sauvegarde, je constate assez régulièrement qu’elles sont dans le même état que mon ami. Les audits fait par des entreprises spécialisées passent aussi à coté (j’en ai encore eu la démonstration il y a peu avec un grand nom du secteur… Un petit check et on a constaté que la dernière sauvegarde AD datait d’il y a deux ans). Soyez rassuré ! Contrôler si la sauvegarde est correctement réalisée est une opération très simple !

Allez, finit de rire, on passe aux choses sérieuses…

Principe

Active Directory est un service multi-maitres, n’ayant aucun lien avec un conglomérat historique colonialiste (je dis ça à l’attention de nos lecteurs très à woke) : il repose sur la réplication des informations entre les différents contrôleurs de domaine, ce qui le rend donc implicitement lié à la sauvegarde de ces derniers (jusque-là, c’est parfaitement logique). La sauvegarde d’Active Directory doit être réalisée lorsque le service est opérationnel sur les contrôleurs de domaine – au moment de l’installation du rôle, un jeu de commande spécifique à la sauvegarde de ce dernier est ajouté au système (la bibliothèque de fonction est enregistrée dans le fichier Ntdsbcli.h).

« Attendez », s’exclame Gérard, « cela veut-il dire que le logiciel de sauvegarde doit appeler ces commandes ? » (oui, il peut aussi poser des questions pas si bête, notre ami Gérard). La réponse est oui : voilà pourquoi un simple snapshot de VM ne peut pas suffire… Et ce point est tout aussi valable pour d’autre forme de base de données, comme celle de Entra ID Connect ou d’un serveur SQL.

Points de vigilance

Cette petite mésaventure qui nous a servit d’introduction nous l’a prouvé : Active Directory est un service critique. En particulier, ce dernier dépend intégralement du service DNS pour son fonctionnement : votre stratégie de sauvegarde doit inclure deux zones dans son périmètre :

• la zone de votre domaine (mon.domaine.tld)
• la zone _msdcs de votre domaine (_msdcs.mon.domain.tld)

Autre point important : vos sauvegardes ne devraient être que des sauvegardes complètes (oui, comme les crêpes, merci Gérard), ADDS ne supportant pas les sauvegardes incrémentales^[3] si ces dernières sont réalisées avec Windows Backup – pour les solutions éditeurs, il faudra se référer à la documentation. A noter que tous les changements qui se produisent durant la sauvegarde sont enregistrés dans un log temporaire, lui-même sera ajouté à la fin du fichier de sauvegarde une fois terminée.

^[3] à ne pas confondre avec l’emmental, pour ceux qui sont encore sur la complète.

Définir un plan de récupération

C’est bien là l’un des bons points que notre incident a mis en avant : le plan de récupération était établi, même si il n’a pas fonctionné. Sachant que les données contenues dans la base de données Active Directory peuvent être répliquées, définir un plan de récupération doit envisager plusieurs scénarios :

• Récupération sur incident partiel (objet supprimé par exemple)
• Perte d’un contrôleur de domaine
• Perte de tous les contrôleurs de domaine
• Action sporadique de Gérard

Pour la suppression d’un objet, une restauration autoritaire de ce dernier suffit – et si vous avez activé les bonnes options, il est même possible de récupérer ce dernier en quelques minutes, pour peu que l’on vous ai demandé de le faire (et que vous en ayez envie). On en reparlera un peu plus loin.

Si vous devez maintenant restaurer un contrôleur de domaine, il est possible soit de le réinstaller, soit de partir d’une sauvegarde (tout dépend du temps de restauration). La plupart des administrateurs opteront pour une réinstallation tant les OS modernes permettent un retour à la normal en quelques dizaines de minutes (modulo la taille de votre base de données et votre latence réseau). Si c’est votre cas, n’oubliez pas de documenter la procédure de nettoyage forcée dans l’annuaire de votre contrôleur avant action (ntdsutil.exe, option metadata cleanup). Si vous voulez en apprendre davantage, vous pouvez vous référer à cet article de Microsoft : https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup#clean-up-server-metadata-using-the-command-line.

Enfin, pour une perte complète du domaine, vous pouvez optez pour une restauration de tous les DC ou seulement de quelques-uns et le complété par une réinstallation des autres contrôleurs (enfin, ça c’est la théorie, encore faut-il avoir des sauvegardes fonctionnelles !).Pour accélérer le temps de restauration, concentrez vous en priorité sur les DC tenant les rôles FSMO (en particulier le rôle PDCemulator) : tous les autres DC peuvent être reconstruits à partir d’un seul (ou, pour reprendre les termes de Connor MacLeod, il ne peut n’en rester qu’un). N’hésitez pas à consulter la documentation de MiniMou à ce sujet : https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-perform-initial-recovery

Que Sauvegarder ?

La sauvegarde Active Directory requiert de sauver la base de données et les logs transactionnels. La sauvegarde devrait également inclure la zone DNS et le contenu du dossier SYSVOL (stratégies de groupe).

La  base de données Active Directory utilise le format ESE (Extensible Storage Engine), ainsi que la méthode ISAM (Indexed and Sequential Access Method) – une architecture de base de données orientée enregistrements qui fournit un accès extrêmement rapide aux enregistrements. ESE indexe les données dans le fichier de base de données. A noter que le fichier peut atteindre une taille maximale de 16 Tb et contenir jusqu’à 2 milliards d’entrées. Si votre zone DNS est intégrée à Active Directory, elle sera sauvegardée avec la base données dans les partitions ForestDNSZones, DomainDNSZones et Global Catalog.

Base de données	NTDIS.DIT
Logs transactionnels	edb.chk, edb.log, edb*.log, res*.log

Le format ESE : https://learn.microsoft.com/en-us/windows/win32/extensible-storage-engine/extensible-storage-engine

Quels sont les privilèges nécessaires ?

Pour réaliser cette opération, le compte utilisé doit disposer du privilège SE_BACKUP_NAME, qui provoque une attribution des privilèges permettant la lecture de tous les fichiers, indépendamment des permissions données (ACL) – tout accès autre que la lecture est soumis aux permissions du fichier (ACL).Les permissions d’accès suivantes sont octroyées quand le privilège est accordé :

• READ_CONTROL
• ACCESS_SYSTEM_SECURITY
• FILE_GENERIC_READ
• FILE_TRAVERSE

Mais comme c’est assez compliqué de donner les droits fins, on peut également octroyer ce privilège en attribuant le droit utilisateur suivant :

• BACK UP FILES AND DIRECTORIES

C’est d’ailleurs ce que l’on fait via le groupe « Backup Operators » ; toutefois, cette méthode est fortement déconseillée au niveau de l’annuaire étant donné qu’elle donnerait un accès à tous les systèmes (un système compromis pourrait permettre de remonter jusqu’au contrôleur de domaine et d’extraire la base de comptes), à moins de circonscrire le compte exclusivement aux contrôleurs de domaine.

Je vous laisse découvrir cet appétissant chapitre auprès de l’éditeur : https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/back-up-files-and-directories !

Le principal problème : la restauration des liens.

Dans l’annuaire, un objet peut avoir plusieurs liens avec d’autres objets, comme être membre d’un groupe AD, manager d’un objet AD ou encore avoir une PSO assignée. Les liens existent alors sous l’une des trois formes possibles : forward link (que l’on peut éditer), backward link et From-To Link (à l’attention de nos lecteurs les plus aguerris à l’univers Nintendo, apportons la précision qu’il n’est pas ici question de chercher la princesse dans un autre château, désolé).

Mais qu’est-ce donc que ces « link », vous demandez-vous ? En quelques mots (ou avec un gros dessin juste après), Les attributs liés sont des paires d’attributs dans lesquelles le système calcule les valeurs d’un attribut (backward-link) en fonction des valeurs définies sur l’autre attribut (forward-link) dans toute la forêt.

Les « back link » sont associés au « forward link » et mis à jour par le système uniquement : ainsi, lorsque Jetro Delavaine a été configuré comme gestionnaire (manager) d’Ella Padbole, le « Forwark Link » de Jetro a été mis à jour avec le DistinguishedName d’Ella et le « back link » d’Ella Padbole a été actualisé par Active Directory avec le DistinguishedName de Jetro.

Tout le problème d’une restauration d’objet est donc de reconstruire tous ses liens (et à lien possible nul n’éternue…).

Je vous invite à en découvrir davantage sur le monde merveilleux des attributs et des liens, avec ou sans la triforce (référence pour geek cinquantenaire), ici : https://learn.microsoft.com/en-us/windows/win32/ad/linked-attributes

La corbeille Active Directory

La corbeille Active Directory permet de simplifier le processus de restauration d’un objet. Dans le plan de récupération, il est important de tenir compte de l’activation, ou non, de cette dernière. A partir de là, quoi dire ? Elle influe directement sur le processus de vie d’un objet (processus partant de la création de ce dernier jusqu’à sa suppression de la base de données). Ne pas l’activer, c’est comme refuser d’apprendre à nager et vouloir battre Michael Phelps^[4]. La corbeille permet de passer l’objet supprimé dans un état intermédiaire : il est alors déplacé dans un conteneur spécifique (deleted objects) que seuls les administrateurs peuvent lire. Ce système permet de maintenir les liens en place et ainsi de « restaurer » un objet sans recourir à une procédure autoritaire (assez pénible à faire).

^[4] faudrait courir vraiment très très vite…

Je vous invite à creuser le sujet, si pour vous c’est quelque-chose de nouveau, ici : https://learn.microsoft.com/fr-fr/windows-server/identity/ad-ds/get-started/adac/active-directory-recycle-bin?tabs=adac

Et pour ceux qui ne connaissent M. Phelps (pas celui qui fait exploser les cassettes), c’est ici : https://fr.wikipedia.org/wiki/Michael_Phelps

Cycle de vie d’un objet

Comme je sais que tout le monde préfère un bon schéma à mille mots (et que je l’ai déjà fait, de toute façon), voici comment le cycle de vie d’un objet peut être résumé :

Comme le montre le schéma, l’utilisation de la corbeille AD simplifie grandement le processus de récupération des objets et double la durée pendant laquelle une récupération est possible (deux fois la TSL). Toutefois, il ne répondra aux besoins d’une perte de contrôleur de domaine.

Petite aparté, bien obligatoire puisque je n’en ai pas parlé avant : la TSL, qui n’a rien à voir avec un accès internet par voix cuivrée mais est acronyme pour Tombstone Lifetime, représente l’intervalle, en jour, pendant laquelle un objet est conservé avant sa suppression. Il s’agit d’un attribut de votre domaine que l’on peut parametré et dont la valeur par défaut est, sur les systèmes récents, de 180 jours.

Vous pouvez en apprendre plus sur la TSL et son lien avec la corbeille AD ici : https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/database-garbage-collection-caculation-of-allowed-intervals

Fonctionnement de la suppression dans Active Directory

Connaitre le fonctionnement de la suppression d’un objet dans la base de données peut également vous aider à prendre les meilleures décisions pour vos scénarios de récupération. L’exemple ci-après illustre le cas de la suppression complète du compte de Jetro Delavaine, membre du groupe GS-Team-Luc avec sa collègue Ella Padbole.

Fonctionnement de la base NTDIS.DIT

Pour rappel, le fichier NTDS.DIT contient deux tables distinctes pour gérer les objets et leurs liaisons : la table Datatable, qui contient tous les objets et attributs de l’annuaire, et la table Link-Table, qui gèrent les liens entre les objets, comme l’appartenance aux groupes par exemple.

Au début du processus de suppression, l’état dans nos tables est donc le suivant :

Datatable

Link-Table

Suppression de Ella Padbol

Dans le cas où la corbeille AD est activée, l’objet est alors déplacé dans le conteneur Deleted Objects pour toute la durée de la TSL (180 jours par défaut pour un annuaire n’ayant pas connu de contrôleur de domaine Windows Server 2003).

L’objet devient alors invisible pour tout le monde, à moins de regarder directement dans le conteneur Deleted Objects. Des indicateurs sont positionnés dans les deux tables pour signaler l’état de l’objet – les liens sont conservés mais inactifs. L’état de nos tables devient alors :

Datatable

Link-Table

Note : Si la corbeille AD n’est pas activée, cette étape est sautée et l’on passe directement à la suivante.

Expiration de la TSL (corbeille AD)

Une fois atteint les 180 jours de la TSL, l’objet passe automatiquement dans la condition tombstone, à nouveau pour toute la durée de la TSL. Les liens présents dans la table link-table sont supprimés et le nom de l’objet se voit ajouter la valeur \0ADEL:GUID en bout de chaine. L’attribut isDeleted ne change pas.

L’état de nos tables devient alors :

Datatable

Link-Table

Note : à partir de cet instant, seule une restauration autoritaire depuis une sauvegarde permettra de récupérer l’objet.

Suppression définitive (phase 1)

L’objet restera en tombstone pendant toute la durée de ls TLS ; une fois celle-ci dépassée, l’objet est marqué pour suppression de la base de données (attribut isRecycled).

L’état de nos tables devient alors :

Datatable

Link-Table

Suppression définitive (phase 2)

Toutes les douze heures, le processus de nettoyage de la base de données est lancé sur les contrôleurs de domaine : tous les objets marqués de l’attribut isRecycled sont alors supprimés définitivement. L’état de nos tables devient alors :

Datatable

Link-Table

Sauvegarder Active Directory

Il existe plusieurs méthodes pour sauvegarder Active Directory : manuellement, avec les outils de Windows Server ou avec une solution tierce de sauvegarde.

Sauvegarde manuelle (aka export)

Une sauvegarde manuelle d’Active Directory est possible, en particulier pour la base de données.

Pour réaliser la sauvegarde :

1. Lancer un shell en mode administrateur
2. Exécuter la commande NTDSUTIL
3. Activer l’instance NTDS en exécutant la commande :
   • activate instance ntds
4. Faire un snapshot de l’instance :
   • Snapshot
   • Create
5. Vérifier que le snapshot est présent :
   • List all
6. Repérer l’ID du snapshot, puis le monter sur le système :
   • Mount snapshotID
7. Le snapshot est monté à racine du disque (c:\$SNAP_*)
8. Aller dans le dossier du snapshot et copier dans votre emplacement de sauvegarde :
   • Le dossier NTDS,
   • Le dossier SYSVOL,
   • Le dossier PolicyDefinitions (si vous n’utilisez pas le central store)
9. Une fois la copie terminée, démonter le snapshot :
   • Unmount snapshotID
10. Finalement, supprimer le snapshot :
    • Delete snapshotID

Sauvegarder avec Windows Backup

Windows Backup est la méthode officielle de sauvegarde reconnue par Microsoft. Simple à mettre en œuvre, elle requiert la mise à disposition d’un volume dédié pour la sauvegarde. Pour bien sécuriser ce dernier, le disque devra être chiffré ainsi que la sauvegarde, lorsque cette dernière est déplacée.

Pour sauvegarder avec Windows Backup :

1. Installer la fonctionnalité Windows Server Backup sur le contrôleur de domaine
2. Lancer la console Windows Server Backup
3. Configurer une nouvelle planification de sauvegarde, à la fréquence de votre choix, avec les options suivantes :
   1. Sauvegarde personnalisée : System State
   1. Destination : le volume dédié à la sauvegarde
   1. VSS : oui, backup Full

Vous devrez contrôler la bonne exécution de la sauvegarde par vous-même.

Sauvegarde avec une solution tierce

Il existe pléthore de solutions de sauvegarde qui permettent de réaliser cette opération. Toutefois, vous devez veiller à ce que ces dernières le fassent correctement sans mettre en péril vos données ou la sécurité de l’annuaire…

Tout d’abord, il est important de se rappeler qu’un snapshot de volume, sur un hyperviseur, n’est pas une sauvegarde. En effet, comme expliqué précédemment, la sauvegarde implique la duplication de l’instance NTDS et l’instanciation des modifications durant ce laps de temps dans un fichier dédié : un snapshot n’informe jamais les systèmes de son opération ! Dans le cas d’une base de données (et cela est vrai pour d’autres types de bases de données comme SQL par exemple), vous risquez de perdre l’intégralité de vos données lors de la restauration de la banque de données…

Pour que la sauvegarde soit effectuée correctement, elle devra faire appel au VSS Provider, un composant clé du Volume Shadow Copy Service (VSS), une technologie de Microsoft Windows qui permet de créer des copies instantanées (snapshots) des fichiers ou des volumes, même lorsqu’ils sont en cours d’utilisation. Il joue un rôle crucial dans la gestion des sauvegardes et des restaurations, en assurant que les données sont capturées de manière cohérente et fiable, même lorsque les applications sont en cours d’exécution.

Toutefois, l’utilisation du VSS Provider peut induire l’utilisation d’un compte de service qui devra disposer des bons droits sur les contrôleurs de domaine, droit souvent octroyé en mettant le compte de service dans le groupe « backup operators » ou « admins du domaine » – aucune des approches n’est satisfaisante au regard de la sécurité…

Le meilleur moyen reste alors de faire une sauvegarde locale avec Windows Server Backup.

Pour un contrôleur de domaine virtualisé :

1. Faire une sauvegarde du system state avec windows backup
2. Faire un snapshot de la VM avec votre solution Tier

Pour un contrôleur de domaine physique :

1. Faire une sauvegarde complète au moyen d’un agent de sauvegarde installé sur le système.

Comment vérifier la sauvegarde

Pour vérifier une sauvegarde, procédé à un test de restauration d’un contrôleur de domaine dans un environnement isolé.

Vous pouvez également contrôler que votre système de sauvegarde opère de la bonne façon en récupérant la date de dernière sauvegarde de le base NTDIS via la commande suivante :

repadmin /showbackup

Conclusion

J’espère que cet article vous aura permis de mieux comprendre le fonctionnement de la sauvegarde Active Directory et de la manière dont les objets sont gérés. Si vous souhaitez en savoir plus, n’hésitez pas à me contacter !