Introduction
Après quelques années d’expérience sur les environnements de domaine Microsoft, j’ai été confronté à un certain nombre de problèmes liés à Active Directory. Dans certains cas, les problèmes n’ont pas été sans conséquence et ont perturbé l’activité de l’entreprise.
Sans doute par manque de préparation et pris par le stress de la situation, certains administrateurs n’ont pas choisi la bonne solution.
Il faut bien comprendre qu’une bonne préparation est essentielle pour gérer ce type de situation. Les points-clés de la préparation sont une bonne connaissance de son environnement et un minimum de compréhension des mécanismes de réplication d’Active Directory. Chaque administrateur Active Directory devrait réaliser des tests périodiques de restauration et documenter ces éléments. Ces tests lui permettront à la fois de maîtriser les éléments et de pallier au stress que peut occasionner ce type de situation.
C’est une partie de cette expérience que je voudrais traduire dans cette documentation afin de vous permettre de vous préparer au mieux à un éventuel sinistre.
De quoi est composé Active Directory ?
L’annuaire LDAP et la base de données Active Directory
Active Directory est composé d’un annuaire LDAP contenant des objets (utilisateurs, ordinateurs, groupes, Zone DNS,…). Chaque objet possède des attributs. Par exemple un utilisateur possède l’attribut « SamAccountName » qui correspond à son login. Parmi ses propriétés, chaque objet dispose d’une valeur « USNCreated » et « USNChanged » jouant un rôle important dans la réplication.
Une forêt Active Directory dispose de plusieurs partitions pour stocker ces objets. Certaines de ces partitions sont répliquées entre tous les DC de la forêt, d’autres peuvent être répliquées juste entre les contrôleurs de domaine du domaine concerné.
Nous retrouvons au minimum les partitions suivantes répliquées sur l’ensemble des contrôleurs de domaine de la forêt :
- la partition de schéma,
- la partition de configuration.
La partition du domaine est répliquée sur les contrôleurs du domaine du même domaine. Si vous n’avez plus de contrôleur de domaine viable pour un domaine, il ne fonctionnera plus. Si au moins un contrôleur de domaine de ce domaine ne réplique pas avec les serveurs des autres domaines votre domaine devient orphelin et sera perdu.
L’annuaire Active Directory est stocké par défaut dans le dossier c:\windows\ntds.
La réplication de l’annuaire
La réplication Active Directory est la synchronisation des objets et des attributs des objets entre l’ensemble des contrôleurs de domaine. Le mécanisme de réplication multi maitre permet de modifier un élément sur n’importe quel contrôleur de domaine. Les attributs USN permettent de suivre les évolutions des objets. Chaque contrôleur de domaine connaît sa dernière valeur USN (dernière modification) et la dernière valeur répliquée avec les autres contrôleurs de domaines. Si par erreur un contrôleur de domaine devait redémarrer dans un état précédent (utilisation d’une image Ghost ou de snapshot), les autres contrôleurs de domaines le supposeront comme étant plus loin dans la réplication que la réalité. Les modifications effectuées depuis la création de l’image restaurée ne seront pas reprises. Ce phénomène peut créer une corruption de la base de données AD appelé « USN Rollback ». Afin d’éviter ce problème il est nécessaire d’utiliser la restauration de l’état du système pour restaurer un contrôleur de domaine. Quand vous restaurez l’état du système l’identifiant de la dernière modification est réinitialisé ce qui permet au contrôleur de domaine restauré de reprendre les modifications depuis l’horodatage de la sauvegarde. Néanmoins l’image restaurée doit être récente et ne pas dépasser le TombStone LifeTime.
Tombstone LifeTime : lors de la suppression d’un objet, il est conservé dans un conteneur stockant les éléments supprimés pendant un certain temps. Ce temps est le « TombStone LifeTime » qui permet de garantir que les autres contrôleurs de domaine seront notifiés de la suppression prochaine de l’objet. L’objet supprimé va perdre ses différents attributs avant de disparaître. Une fois disparu il n’existera plus d’informations de son existence et si vous restaurer une image ancienne de votre contrôleur de domaine où le compte existe encore, cela provoquera un problème d’intégrité dans l’annuaire. Dans ce cas vous risquez de constater que vos contrôleurs de domaines refusent de répliquer avec celui qui a été restauré. Un message d’erreur apparaît dans l’observateur d’événement indiquant que la dernière réplication est trop ancienne.
Il est tout de même possible de récupérer un élément ou un ensemble d’éléments supprimés récemment. Cette restauration s’appelle une restauration autoritaire d’Active Directory, car elle va prendre le dessus sur les autres contrôleurs de domaines qui disposent de l’information de suppression. Parmi les mécanismes qui permettront de restaurer un objet Active Directory nous verrons :
- La restauration autoritaire d’un objet AD via la restauration de l’état du système (toutes versions)
- L’utilisation de la corbeille Active Directory (à partir de 2008R2)
- L’utilisation des « snapshot » Active Directory à ne pas confondre avec les clichés des machines virtuelles (à partir de Windows 2008).
Néanmoins Active Directory ce n’est pas que l’annuaire LDAP, c’est également des stratégies de groupes (Group Policy Object) et des scripts d’ouverture de sessions qui sont stockés dans des dossiers partagés. Il y a donc en plus de la réplication AD, la réplication de fichiers.Ces 2 mécanismes sont différents et sont souvent source de confusion. Chaque contrôleur de domaine dispose d’un dossier partagé « Sysvol » et d’un dossier « Netlogon » identique aux autres contrôleurs de domaine du même domaine.
Pourquoi rentrer dans ce type de détail ? Nous verrons un peu plus loin nous parlerons de restauration autoritaire (ou non) pour « Sysvol » et de restauration autoritaire AD, et ce n’est pas la même chose.
Les stratégies de groupes et les scripts de connexion (Netlogon et Sysvol)
-
Principe
Les stratégies de groupes (GPO) et les scripts d’ouverture de session sont stockés dans 2 partages : « SYSVOL » et « NETLOGON ». Par défaut ils se trouvent dans le dossier « c:\windows\sysvol ». Ces dossiers sont répliqués sur les contrôleurs de domaine du même domaine. Les postes clients accèdent à ces partages pour charger les paramètres de configuration.
Ces dossiers sont répliqués par des mécanismes de copie de fichier. Il existe 2 types de réplication que nous présenterons au prochain paragraphe.
-
Réplication NTFRS ou DFS-R
La réplication NTFRS (NT File Replication Service) est apparue avec Windows NT et existe encore sous Windows 2012. Néanmoins à partir de Windows 2003 R2 le système DFS peut s’appuyer sur DFS-R pour répliquer des dossiers partagés.
Avez-vous remarqué que sur 2003 vous pouvez rencontrer 2 consoles différentes pour gérer DFS ?
Mais ce n’est que dans la version 2008 que DFS-R est exploité pour la synchronisation de SYSVOL et là encore, pas par défaut. Seul un domaine créé avec un niveau fonctionnel de domaine Windows 2008 ou supérieur utilise par défaut la réplication DFS-R.
Un domaine ayant un niveau inférieur à 2008 lors la création utilise par défaut NTFRS même s’il a été migré vers 2008R2.
- Quelle réplication sysvol est utilisée sur mon réseau ?
Sur un contrôleur de domaine, ouvrez une « invite de commande » DOS, et tapez « dfrsmig /GetGlobalState ». Si le message indique que vous êtes en mode « éliminer » ou « rediriger » alors SYSVOL est synchronisé avec DFS /R.. Si le message est « Démarrer » ou « préparer » alors votre dossier Sysvol utilise encore la réplication NTFRS. Dans le cas de « rediriger » ou « préparer » la migration NTFRS sysvol vers DFS-R a commencé mais elle n’est pas terminée.
Pourquoi ces détails sur la réplication de fichier ?
Nous verrons un peu plus tard que la restauration d’une forêt complète va légèrement différer entre les 2 types de réplication.
-
Comment passer d’une réplication Sysvol par NtFRS à une réplication par DFS-R
L’outil permettant de migrer d’une réplication NTFRS vers DFS est « dfsrmig ». L’opération est simple et l’outil s’assure à chaque étape que tous les contrôleurs du domaine atteignent un état cohérent.
Le guide suivant est un article sur la migration de la réplication NTFRS vers DFS-R pour SYSVOL :
