Active Directory est une application très robuste, comme il se doit pour un élément aussi fondamental de l'infrastructure informatique d'une entreprise. Mais l'architecture qui lui confère cette robustesse la rend également difficile à comprendre. Ce manque de compréhension conduit souvent à formuler des hypothèses erronées dans votre stratégie de reprise, ce qui peut entraîner une panne d'Active Directory sans qu'il soit possible de revenir à la normale.
Lorsque l'équipe d'ingénierie et d'exploitation Active Directory élabore son plan de reprise, la tendance naturelle est de penser en premier lieu à la reprise des contrôleurs de domaine (DC). C'est une bonne première étape, qui repose sur deux raisons très pratiques. Premièrement, les DC ont toujours été les composants Active Directory les plus sujets aux pannes. Deuxièmement, la reprise et la reconstruction des serveurs constituent l'une des tâches opérationnelles les plus anciennes du manuel d'exploitation ; il est donc naturel de l'appliquer à cette situation.
Mais dans le cas d'Active Directory, l'équipe ne va souvent pas plus loin et ne prévoit pas l'autre type de sinistre auquel Active Directory peut être confronté : la corruption logique des données AD.
La toile de la réplication
Ce qui rend Active Directory difficile à comprendre et à dépanner sur le plan opérationnel tient en partie à la complexité de son modèle de données logique. J’ai toujours abordé AD à travers ce que j’appelle plusieurs « paires de lunettes ». La première, et la plus évidente, concerne le réseau des contrôleurs de domaine (DC) physiques et leur état de santé. On a tendance à se concentrer sur les DC d’une forêt, car ce sont les éléments tangibles d’Active Directory. Viennent ensuite mes « lunettes des sites ». À travers celles-ci, j’observe la topologie des sites du réseau d’entreprise et la manière dont les données sont constamment répliquées entre les contrôleurs de domaine : les sites dotés d’une bonne connectivité (qui peuvent ou non héberger un contrôleur de domaine), les liaisons de site permettant de relier les sites de la manière la plus adaptée aux besoins des utilisateurs et des applications qui utilisent les sites AD, ainsi que le réglage fin de ces liaisons de site à l’aide du coût des liaisons et de la priorité DNS afin de privilégier certains contrôleurs de domaine par rapport à d’autres.
Mais la réalité est plus complexe qu’un simple schéma d’architecture du site. Si vous examinez de près la réplication à l’aide d’un outil tel qu’ADREPLSTATUS ou Repadmin, la véritable complexité d’Active Directory se révèle. Chaque contrôleur de domaine héberge plusieurs partitions d’annuaire contenant des données importantes, et les différentes architectures de forêt déterminent quelles partitions un contrôleur de domaine héberge. Chacune de ces partitions est connectée à plusieurs autres contrôleurs de domaine situés ailleurs dans le domaine ou la forêt. Je vois cela comme une pelote composée de centaines de fils multicolores reliant les picots d’un panneau perforé. Certains fils ne relient que quelques picots, tandis que d’autres relient tous les picots du panneau. C’est un véritable miracle que cela fonctionne, sans parler du fait que cela fonctionne si bien.
Mais ce mécanisme fonctionne aussi bien pour les mauvaises données que pour les bonnes. En cas de corruption logique des données, les données corrompues seront répliquées par tous les DC du domaine ou de la forêt. Dans les cas où la corruption logique est grave (comme la désactivation du compte du centre de données dans AD via la console standard Utilisateurs et ordinateurs), une reprise après sinistre d'AD doit être effectuée. Le processus de restauration de Microsoft comprend plus de 50 étapes manuelles, ce qui le rend lent, sujet aux erreurs et insuffisant pour les besoins de l'entreprise. La complexité de la procédure est suffisamment importante pour que Microsoft la propose dans le cadre d'ADRES (AD Recovery Execution Service), un engagement de service de 5 jours qui se concentre sur les problèmes de restauration d'AD.
De nombreuses entreprises ont mis en place des sites de reprise après sinistre dans Active Directory afin de fournir des DC de basculement aux utilisateurs et aux services en cas de défaillance du DC normal. Cependant, les sites de reprise après sinistre ou le nombre de DC dont vous disposez ne vous aideront pas en cas de corruption logique - ils rendront même la reprise plus compliquée.
C'est là que vous avez le choix entre une procédure manuelle à suivre ou une solution automatisée qui le fera pour vous.
