Active Directory ne nécessite pas huit machines virtuelles pour démarrer. Voici un guide clair et actionnable pour dimensionner le nombre de VM, décider quand passer au multi‑forêts, contrer les menaces, et collecter les preuves dans les journaux—sans complexifier inutilement votre architecture.
Nombre minimal de machines virtuelles pour une architecture Active Directory
Vue d’ensemble
Il n’existe aucune règle rigide imposant un grand nombre de serveurs. Vous pouvez commencer avec un seul contrôleur de domaine dans une seule forêt et un seul domaine. En production, la bonne pratique est de déployer au moins deux contrôleurs de domaine (DC) par domaine pour la haute disponibilité, l’équilibrage de charge LDAP, la tolérance aux pannes et la résilience face aux mises à jour et aux redémarrages.
Chaque nouvelle forêt établit une frontière d’administration indépendante. Elle n’est requise que lorsqu’il faut isoler fortement des identités ou des environnements : séparation de tenants, exigences de conformité (ISO 27001, secteurs réglementés), zones de confiance distinctes, ou adoption d’une stratégie de privilèges renforcés inspirée des modèles ESAE et Privileged Access Strategy.
Les applications (messagerie, bases de données, partage de fichiers) sont idéalement hébergées hors des DC pour limiter la surface d’attaque et les interactions logicielles. Les exceptions sont possibles en labo, en maquette ou dans de très petites structures avec contraintes fortes, mais la séparation reste la recommandation par défaut.
Scénarios et minima réalistes
| Scénario | Forêts / Domaine | DC minimum | VM applicatives | Quand l’adopter ? | Notes de conception |
|---|---|---|---|---|---|
| Petite organisation | Une / Un | Deux | De zéro à n | Besoins simples, budget maîtrisé | Deux DC suffisent pour la tolérance aux pannes. DNS intégré aux DC, sauvegardes régulières, pas de multi‑forêts. |
| Forêt ressources dédiée | Deux / Deux ou plus | Quatre | De un à n | Séparer identités et services | Forêt identité et forêt services : privilégier des approbations unidirectionnelles minimisant les privilèges. |
| Forêt d’accès restreint de type ESAE | Trois / Trois ou plus | Six | De un à n | Administration hautement isolée, exigences de conformité élevées | Tiering des comptes, postes d’admin dédiés, contrôles durcis, politiques d’approbations minimales. |
Ces chiffres sont indicatifs : ajustez-les selon la taille de votre parc, vos SLA, et vos exigences de sécurité.
Arbre décisionnel simple
- Avez-vous des contraintes de conformité fortes ou des tiers peu fiables ? Si oui, envisagez la séparation en plusieurs forêts (au minimum une forêt identités + une forêt ressources).
- Vos administrateurs opèrent sur des postes dédiés et vous souhaitez cloisonner les privilèges ? Envisagez une forêt d’administration dédiée et une stratégie de tiering.
- Sinon, démarrez simple : une forêt, un domaine, deux DC, et des serveurs applicatifs séparés.
Rôles, redondance et placements
- Deux DC par domaine permettent de répartir les rôles FSMO et d’assurer la continuité des opérations. Hébergez au moins un Global Catalog par site majeur.
- Sites et réplication : définissez des Sites AD alignés sur votre réseau (latence, bande passante). Limitez les liens de réplication inter‑sites coûteux.
- RODC : pour les agences éloignées peu sûres, déployez des Read‑Only Domain Controllers afin de réduire l’exposition des secrets.
- DNS : faites cohabiter DNS avec les DC. Les clients doivent interroger les DNS AD, pas des DNS publics.
- Virtualisation : Active Directory est virtualisable de manière sûre. Évitez les restaurations de snapshots non contrôlées, utilisez des sauvegardes prises en charge, vérifiez la prise en charge de la génération de VM par l’hyperviseur, et synchronisez l’heure via le PDC Emulator avec des sources NTP fiables.
Dimensionnement pragmatique
| Composant | Point de départ | À affiner par la suite | Indicateurs à surveiller |
|---|---|---|---|
| CPU | Deux vCPU par DC | Augmenter si pics LDAP/NTDS | Utilisation CPU, latence LDAP |
| Mémoire | Huit à seize Go par DC | Selon la taille de la base NTDS | Cache DS, pages en faute, temps de réponse |
| Disque | Stockage rapide pour NTDS et SYSVOL | Journal distinct si possible | Latence IO, fragmentation, espace libre |
| Réseau | Routage stable entre sites | QoS sur réplication si WAN | Temps de réplication, erreurs RPC |
Bonnes pratiques incontournables
- Séparez DC et serveurs applicatifs en production.
- Deux contrôleurs au minimum par domaine pour la continuité d’activité.
- Un Global Catalog par site principal, deux si le site est critique.
- Backups réguliers du System State de chaque DC et tests de restauration.
- Pas de snapshots sauvages de DC : documentez des procédures de restauration compatibles AD DS.
- Gestion des comptes privilégiés : comptes dédiés, double contrôle, MFA, et postes d’administration (PAW).
Menaces ciblées par une architecture multi‑forêts
La séparation logique en plusieurs forêts limite la portée d’un incident et complique les mouvements latéraux. Elle ne remplace pas une hygiène de base, mais réduit le rayon d’explosion.
| Catégorie de menace | Impact d’une séparation par forêts | Pourquoi cela fonctionne |
|---|---|---|
| Logiciels malveillants et rançongiciels | Propagation freinée d’un environnement à l’autre | Confiance, groupes et secrets ne sont pas réutilisables entre forêts |
| Menaces internes | Un compte compromis est cantonné à sa forêt | Frontières d’administration distinctes, sessions d’admin isolées |
| Vol ou cassage d’identifiants | Les comptes privilégiés sont gérés ailleurs, moins exploitables | Les hachages, tickets et politiques ne traversent pas la frontière forestière |
| Pass‑the‑Hash et Pass‑the‑Ticket | Les hachages et tickets d’une forêt sont inutiles dans une autre | Domaines et forêts ont des secrets chiffrés et clés distincts |
| Déni de service sur les DC | Un DC saturé n’interrompt pas les autres forêts | Plans de réplication et de noms totalement séparés |
Plus la topologie est segmentée, plus vous ralentissez l’escalade de privilèges et la propagation. L’objectif n’est pas la complexité pour la complexité, mais la compartimentation raisonnée.
Détection et preuve des menaces via les journaux
Activer l’audit avancé
Définissez une GPO au niveau Domain Controllers et Domain pour activer l’audit avancé :
- Stratégies locales → Configuration de l’ordinateur → Paramètres Windows → Paramètres de sécurité → Stratégies d’audit avancé.
- Cibles principales : Logon, Account Logon, Account Management, Directory Service Access, Directory Service Changes et Directory Service Replication.
- Activez la journalisation des échecs et réussites pour obtenir des preuves exploitables.
Événements clés à surveiller
| Event ID | Source | Ce que cela indique | Alerting conseillé |
|---|---|---|---|
| 4624 / 4625 | Security | Connexions réussies / échouées | Seuils anormaux par hôte, par compte et par géographie |
| 4768 / 4769 | Kerberos | Tickets TGT / service émis | Détecter Kerberoasting (TGS massifs, RC4, comptes de service ciblés) |
| 4740 | Security | Compte verrouillé | Brute force, compte orphelin dans un service |
| 4672 | Security | Connexion avec privilèges spéciaux | Sessions admin hors créneaux ou hors PAW |
| 4728 à 4732 | Security | Ajout à des groupes privilégiés | Alerte immédiate, approbation à deux personnes |
| 5136 / 5137 | Directory Service | Création / modification d’objets AD | Surveiller créations d’admins, GPO soudaines, délégations étendues |
| 4741 / 4742 | Security | Création / modification de compte ordinateur | Spikes de jonctions au domaine non planifiées |
| 4662 | Security | Accès à des objets protégés | Lecture massive d’attributs sensibles, DCSync non autorisé |
| 4928 / 4929 | Security | Modifications de partitions d’annuaire | Changements inattendus de schéma ou de configuration |
Outils recommandés
- Microsoft Defender for Identity ou solutions équivalentes pour corréler les événements AD et détecter les mouvements latéraux.
- Sysmon pour enrichir la télémétrie (processus, réseau, création de fichiers), avec une configuration de règles adaptée.
- SIEM (Sentinel, Splunk, QRadar, etc.) pour l’agrégation multi‑sources, les tableaux de bord et les alertes en temps réel.
Playbooks d’investigation express
| Scénario | Indices | Journaux à consulter | Actions immédiates |
|---|---|---|---|
| Escalade de privilèges | Ajout soudain à Domain Admins ou Administrators | 4728 à 4732, 4672, 5136 | Geler le compte, valider l’approbation, vérifier provenance des sessions |
| Kerberoasting | Multiples 4769 sur le même SPN, algorithmes faibles | 4768, 4769, journaux SIEM | Forcer rotation des mots de passe gMSA, imposer AES, réduire droits des comptes de service |
| DCSync illicite | Lectures massives d’attributs sensibles | 4662 avec GUID d’objets secrets, 5136 | Révoquer délégations, auditer ACL, isoler la machine émettrice |
| Brute force | Multiples 4625 puis 4740 | 4624/4625, 4740 | Bloquer l’IP source, exiger MFA, reseter les comptes ciblés |
Pratiques complémentaires
- PAW pour l’administration : postes dédiés, durcis, sans accès Internet, comptes segmentés.
- Mises à jour régulières du système et des applications, fenêtres de maintenance planifiées et testées.
- Mots de passe robustes, gestion des secrets et, si possible, authentification multifacteur pour tout compte sensible.
- LAPS ou équivalent pour gérer les mots de passe locaux des postes et serveurs membres.
- gMSA pour les comptes de service afin de réduire l’exposition des secrets et simplifier les rotations.
Informations complémentaires utiles
- Stratégie d’accès privilégié : inspirez‑vous des modèles ESAE et des approches de Privileged Access modernes (tiering, bastions, sessions éphémères, contrôle d’accès conditionnel).
- Référentiels : NIST 800‑53 et CIS Controls v8 (notamment contrôles 4, 5, 6) pour cadrer la gouvernance, l’inventaire des actifs, la gestion des vulnérabilités et des privilèges.
- Modèle à trois niveaux : Tier 0 pour le cœur AD et les comptes d’administration, Tier 1 pour les serveurs applicatifs, Tier 2 pour les postes utilisateurs. Les comptes ne doivent jamais franchir les tiers sans médiation.
Méthode de déploiement progressive
- Phase initiale : une forêt, un domaine, deux DC, DNS intégré, sauvegardes System State. Créez des groupes d’admin restreints et mettez en place PAW.
- Phase de consolidation : séparez les serveurs applicatifs, normalisez les GPO, activez l’audit avancé, branchez un SIEM. Mettez en œuvre LAPS et gMSA.
- Phase d’isolation : si nécessaire, ajoutez une forêt ressources ou une forêt d’administration. Définissez des approbations ciblées, révisez les ACL, déployez des RODC en agences exposées.
Erreurs fréquentes à éviter
- Sous‑estimer la sauvegarde : pas de PRA testé, pas de restauration des DC en environnement bac à sable.
- Multiplier les forêts sans gouvernance : complexité et coûts exponentiels sans bénéfice net.
- Héberger des applications critiques sur des DC : augmente la surface d’attaque et complique les mises à jour.
- Laisser les postes d’admin réaliser des tâches bureautiques : mélange des usages, risque d’exposition aux malwares.
- Ignorer la synchronisation temporelle : dérives d’horloge perturbant Kerberos et la réplication.
Checklist rapide de mise en œuvre
| Élément | Contrôle | Statut |
|---|---|---|
| Deux DC par domaine | Rôles FSMO répartis, GC présent | À vérifier |
| DNS AD opérationnel | Clients pointent vers DNS internes | À vérifier |
| Audit avancé actif | Catégories Logon, Account, Directory | À vérifier |
| SIEM branché | Alertes sur événements critiques | À vérifier |
| Sauvegardes testées | Restauration System State validée | À vérifier |
| PAW déployés | Comptes admins dédiés, MFA | À vérifier |
| Gouvernance des forêts | Approvals, trusts, délégations documentés | À vérifier |
| RODC si agences | Filtrage des mots de passe, cache | À vérifier |
Questions fréquentes
Faut‑il absolument une forêt par zone de sécurité
Non. Une seule forêt avec des politiques de sécurité strictes, des ACL appropriées, des PAW et des contrôles d’accès conditionnel peut suffire. Une nouvelle forêt apporte surtout une barrière d’administration pour des cas d’usage très contraints.
Combien de DC par site
Pour un site critique, ciblez au moins deux DC, tous deux Global Catalog. Pour un site secondaire à faible dépendance, un DC (ou un RODC) peut suffire si l’interconnexion réseau vers un site majeur est fiable et redondée. Évaluez le coût d’un arrêt local versus la complexité supplémentaire.
Virtualisation et snapshots
La virtualisation des DC est supportée lorsqu’elle respecte les bonnes pratiques de sauvegarde et de restauration. Évitez les retours en arrière non coordonnés. Privilégiez des sauvegardes cohérentes et testez vos restaurations dans un bac à sable avant toute action en production.
Quand créer une forêt d’administration dédiée
Quand la surface d’attaque ou la criticité des actifs impose un isolement fort : comptes Tier 0 gérés ailleurs, exigences réglementaires, accès d’administrateurs externes, ou exposition accrue à des menaces avancées.
Peut‑on démarrer avec un seul DC
Oui, pour un Proof of Concept ou un environnement de test. En production, ajoutez rapidement un second DC pour assurer la continuité de service, la maintenance sans interruption et la résilience face aux incidents.
Conclusion opérationnelle
Active Directory n’exige pas une flotte massive de VM : la simplicité maîtrisée est votre alliée. Démarrez avec une forêt unique et deux DC par domaine, séparez les applications des DC, et utilisez le multi‑forêts uniquement lorsqu’un besoin de compartimentation fort le justifie. Renforcez la détection via l’audit avancé, un SIEM et des postes d’administration dédiés. Vous obtiendrez une architecture lisible, évolutive et prête à résister aux menaces modernes.
Ressources internes à consulter ensuite
- Plan d’adressage des sites AD, liens de réplication et coûts associés.
- Politique de rotation des secrets : gMSA, LAPS, clés Kerberos et mots de passe d’administrateurs.
- Procédures PRA : restauration System State, réaffectation FSMO, reconstruction d’un DC.
- Modèle de délégation et d’approbations entre forêts : principes de moindre privilège.
- Catalogue des alertes SIEM associées aux Event IDs critiques.
En résumé, la multiplication des VM et des forêts n’a de sens que pour atteindre un niveau de sécurité et de compartimentation aligné sur vos risques. À défaut, un design simple à deux DC reste l’option la plus robuste et économique.