Dans un environnement multi‑forêts Active Directory, l’accès à Internet des contrôleurs de domaine est un risque majeur. Ce guide explique quelles forêts doivent rester hors ligne et comment gérer mises à jour, temps, PKI et supervision sans exposer vos DC.
Sommaire
Quelles forêts Active Directory doivent rester sans accès Internet ?
Problématique
Votre organisation exploite plusieurs forêts Active Directory :
- Forêt mère (organisation parent forest) : identités « standard » des utilisateurs et comptes de service non privilégiés.
- Forêt de ressources (resource forest) : serveurs applicatifs et ressources partagées.
- Forêt d’accès restreint (restricted access forest, aussi appelée forêt « bastion »/PAW/ESAE) : comptes et postes d’administration hautement privilégiés.
Objectif : déterminer quelles forêts (donc quels contrôleurs de domaine, y compris ceux qui détiennent des rôles FSMO) doivent être totalement isolées d’Internet. Contrainte : les profils « Internet » et « DMZ » du Pare‑feu Windows sont désactivés ; les DC fonctionnent donc avec le profil « Domaine » uniquement.
Réponses et solutions synthétiques
| Question | Synthèse de la réponse | Informations complémentaires utiles |
|---|---|---|
| Quelle(s) forêt(s) ne doivent jamais avoir Internet ? | Idéalement les trois forêts n’ont pas besoin d’un accès direct à Internet ; au minimum la forêt d’accès restreint doit en être totalement coupée. | Le modèle « red forest/ESAE » recommande une séparation physique ou logique stricte (VLAN/VRF dédiés) pour la forêt d’accès restreint. Les mises à jour se font via une source interne approuvée (WSUS en mode déconnecté, dépôt SMB signé, etc.). |
| Si la forêt mère et la forêt de ressources sont également sans Internet, cela s’applique‑t‑il à tous les contrôleurs de domaine, y compris ceux qui portent les rôles FSMO ? | Oui. L’isolation concerne chaque contrôleur de domaine. Les détenteurs de rôles FSMO n’ont aucun besoin de routage vers Internet. | Maintenez une zone tampon pour les rares flux externes requis (NTP de référence, accès CRL publiques par relais, télémetrie si vraiment nécessaire) via des proxys en DMZ, jamais depuis les DC. |
| Seule la forêt d’accès restreint pourrait‑elle avoir Internet ? | Non. C’est précisément celle qui ne doit jamais y avoir accès. Si une forêt de production a un besoin métier ponctuel de sortir, utilisez un proxy HTTP(S) filtré et journalisé pour des serveurs intermédiaires — pas pour les DC. | Réduisez la surface d’attaque : aucune navigation Web ni résolution DNS publique depuis les DC. Séparez strictement les flux AD (LDAP/Kerberos, réplication) des flux applicatifs orientés Internet. |
Pourquoi la coupure Internet des contrôleurs de domaine est essentielle
Menaces et vecteurs d’attaque
- Exploitation des piles réseau : tout trafic sortant des DC augmente le risque d’exposition à des 0‑day, à des attaques de type man‑in‑the‑middle ou à des interceptions TLS mal configurées.
- Mouvement latéral : si un DC atteint Internet, un attaquant peut recevoir des charges utiles, exfiltrer des secrets (hash NTLM, tickets Kerberos, clés de session), ou établir un canal C2 discret.
- Confusion DNS : la récursion DNS publique depuis un DC est un anti‑patron. Elle ouvre la porte au DNS rebinding, au détournement d’enregistrements et à la fuite d’informations sur votre topologie interne.
- Élévation indirecte : des mises à jour non maîtrisées (téléchargées directement sur Internet) peuvent introduire des binaires signés malveillants, des pilotes vulnérables ou des compléments non approuvés.
Principes de conception
- Moindre connectivité : « ce qui n’est pas nécessaire est interdit ». Par défaut, aucun flux sortant depuis les DC.
- Admin tiering : séparer l’administration privilégiée dans une forêt bastion et des postes PAW, eux‑mêmes isolés de toute sortie Internet.
- Chaîne d’approvisionnement interne : mises à jour, signatures, packages, référentiels et scripts doivent provenir de miroirs internes de confiance.
- Observabilité sans exposition : collecter les journaux vers un SIEM interne ou un collecteur en zone sécurisée, via des flux unidirectionnels si possible.
Règles de connectivité recommandées pour les DC
Flux autorisés et flux interdits
| Catégorie | Protocoles / Ports | Direction | Statut | Commentaires |
|---|---|---|---|---|
| Authentification | Kerberos TCP/UDP 88, LDAP/LDAPS 389/636, LDAP GC 3268/3269 | Interne seulement | Autorisé | Limiter aux sous‑réseaux de la forêt. Pas d’exposition DMZ/Internet. |
| Réplication | RPC 135 + ports dynamiques (49152–65535), SMB 445 | Interne seulement | Autorisé | Contrôler finement via ACLs réseau inter‑sites. |
| DNS interne | UDP/TCP 53 | Interne seulement | Autorisé | Pas de récursion vers Internet ; désactiver les racines publiques sur les DC. |
| Temps | NTP UDP 123 | Interne vers source de référence | Autorisé | Hiérarchie interne : PDC Emulator synchronisé sur une horloge locale/GPS. |
| Mises à jour | HTTP/HTTPS vers WSUS interne ou file SMB signée | Interne seulement | Autorisé | Mode déconnecté ; aucun trafic direct Internet. |
| Web | HTTP/HTTPS 80/443 | Sortant vers Internet | Interdit | Pas de navigation, pas d’accès direct aux référentiels publics. |
| Résolution publique | DNS UDP/TCP 53 vers résolveurs publics | Sortant | Interdit | Utiliser des résolveurs dédiés en DMZ pour les serveurs applicatifs, jamais depuis les DC. |
Paramètres Pare‑feu Windows côté DC
- Profil Domaine : bloqué par défaut en sortie, n’ouvrir que les ports nécessaires aux flux listés.
- Désactiver explicitement la récursion DNS sur les DC DNS ou rediriger vers des résolveurs internes non exposés.
- Créer des règles par service et par sous‑réseau (par exemple « Autoriser Kerberos depuis VLAN Admin uniquement »).
- Interdire SMB sortant hors des réseaux AD (ex. vers DMZ) pour réduire le risque de relais NTLM.
Points clés sur les rôles FSMO
Les détenteurs FSMO (Schema Master, Domain Naming Master, RID Master, PDC Emulator, Infrastructure Master) sont des DC comme les autres sur le plan réseau : ils ne requièrent aucun accès Internet. Les précautions supplémentaires sont :
- PDC Emulator et temps : définir une source NTP interne de haute précision (récepteur GPS, maître de temps datacenter). Aucun NTP Internet direct.
- Partitionnement : si possible, placer les rôles critiques sur des DC dédiés à forte sécurité physique.
- Surveillance accrue : déclencher des alertes dédiées sur leurs journaux, réplication et latence.
Gestion des mises à jour et des logiciels en environnement isolé
Chaîne d’approvisionnement interne
- Miroir de correctifs : déployer WSUS en mode déconnecté ou un miroir de dépôts dans une zone maîtrisée ayant un accès Internet strictement limité.
- Transfert contrôlé : synchroniser périodiquement les paquets vers une zone intermédiaire puis vers les segments AD via un canal air‑gapped (supports chiffrés, QR de checksum), avec validation cryptographique.
- Validation : tester en pré‑production, ensuite déployer par anneaux (pilote → large → général) avec GPO et maintenance planifiée.
Logiciels, scripts et drivers
- Utiliser une forge interne (Git, dépôt d’artefacts) avec signatures et revue de code.
- Refuser tout exécutable non signé ou non approuvé ; appliquer l’AppLocker ou Windows Defender Application Control sur les DC.
Services critiques hors ligne : PKI, temps et référentiels
PKI d’entreprise
- Racine hors ligne : la CA racine est déconnectée en permanence. Elle émet des sous‑CA d’entreprise connectées uniquement au réseau interne.
- CRL/AIA internes : publier CRL et AIA sur HTTP(s)/LDAP internes accessibles aux DC et serveurs. Si des CRL publiques sont nécessaires pour des trusts ou des intégrations, relayer via un proxy en DMZ, jamais directement depuis les DC.
Temps et synchronisation
- Le PDC Emulator du domaine racine synchronise sur une horloge de référence interne (GPS/NTP maître local).
- Les autres DC se synchronisent sur ce PDC ; les membres se synchronisent sur les DC locaux.
Surveillance et journalisation sans exposition
Collecte des journaux
- Activer l’audit avancé :
4624connexions,4625échecs,4768/4769Kerberos,4688création de processus,4672privilèges spéciaux. - Centraliser via Windows Event Forwarding (pull) ou un agent unique vers un SIEM interne situé en zone sécurisée.
- Segmenter les flux : pas de remontée directe Internet depuis les DC.
Détection et remédiation
- Règles de détection sur anomalies Kerberos (S4U2Self inhabituels, TGT volumineux), réplication AD (DCShadow), pass‑the‑hash/pass‑the‑ticket.
- Procédures break‑glass : comptes d’urgence stockés hors ligne, rotation régulière, contrôles d’accès stricts.
Segmentation réseau et architecture de référence
Zones et sauts contrôlés
[Administrateurs PAW] --(RDP/WinRM via saut)-- [Jump Servers Admin]
|
[Forêt bastion]
|
Flux AD (LDAP/Kerberos)
|
[Forêt mère] <----> [Forêt de ressources]
|
[DMZ: reverse-proxy / egress proxy dédiés]
|
Internet (aucun DC)
Matrice de décision par forêt
| Forêt | Accès Internet direct | Mises à jour | DNS | NTP | Notes |
|---|---|---|---|---|---|
| Accès restreint (bastion/ESAE) | Jamais | WSUS/dépôt interne déconnecté | Interne uniquement, pas de récursion | Source interne dédiée | Isolation physique/VLAN recommandé |
| Mère (identités) | Non requis | WSUS interne | Interne uniquement | Hiérarchie AD | Limiter strictement les flux inter‑sites |
| Ressources | Non requis | WSUS interne | Interne, forwarders internes | Hiérarchie AD | Les applis sortent via egress proxy DMZ, pas les DC |
Cas particuliers et intégrations
Interopérabilité avec des services externes
- Annuaire hybride : héberger la synchronisation sur un serveur dédié dans une zone contrôlée, jamais sur un DC, avec un egress proxy journalisé.
- Télémetrie de sécurité : si certains capteurs nécessitent un accès sortant, déployer des relais/proxys en zone intermédiaire ; les DC n’initient aucun flux Internet.
- Validation de certificats publics : mettre en cache les CRL/OCSP via des relais en DMZ et republier en interne.
DMZ et applications exposées
- Publier les applications via reverse‑proxies en DMZ (WAF, inspection TLS). Les serveurs applicatifs ne communiquent avec les DC qu’en interne, par des ports précisément filtrés.
- Pas de trust AD avec des zones non maîtrisées.
Procédure de mise en œuvre par étapes
Préparation
- Inventorier les DC, rôles FSMO, sites et sous‑réseaux, dépendances NTP/DNS/PKI, chemins de mises à jour.
- Cartographier les flux et supprimer les accès sortants opportunistes sur les DC.
Durcissement réseau
- Appliquer un contrôle d’egress « deny‑all » sur les VLAN DC (routeurs/pare‑feu).
- Mettre en place des listes de contrôle pour LDAP/Kerberos/DNS/NTP intra‑forêt uniquement.
- Créer des sauts d’administration et imposer les PAW pour toute opération privilégiée.
Approvisionnement logiciel
- Déployer WSUS en mode déconnecté ou un miroir de paquets, avec signature et vérification d’intégrité systématique.
- Établir un cycle de correctifs avec fenêtres de maintenance et retour arrière documenté.
Observabilité
- Activer l’audit avancé et l’expédition vers un collecteur interne.
- Définir des indicateurs de compromission liés aux DC (changements de GPO, création d’objets sensibles, modifications de délégations Kerberos).
Validation
- Tests de continuité : authentification, réplication, résolution DNS interne, dérive NTP.
- Tests d’intrusion centrés AD : tentative de relay NTLM, abaissement de signatures LDAP, attaques DCShadow simulées.
Modèle de GPO et contrôles techniques
Paramètres essentiels
- Pare‑feu Windows : blocage sortant par défaut, règles entrantes minimales par service, journalisation des connexions refusées.
- DNS sur DC : désactiver la récursion ; purger les root hints ; n’autoriser que des transferts de zones vers des partenaires internes explicitement listés.
- SMB : signer et chiffrer les communications SMB ; interdire NTLMv1 et restreindre NTLM via stratégies de sécurité.
- LDAP : exiger le canal signé et le scellement LDAP, et privilégier LDAPS.
- WDAC/AppLocker sur les DC pour restreindre l’exécution aux binaires approuvés.
Comptes et postes d’administration
- Postes PAW dédiés, sans navigateur grand public, sans messagerie, sans Internet.
- Privileged Access Management : Just‑Enough‑Administration et Just‑In‑Time, délégations minimales.
- Rotation régulière des mots de passe de comptes sensibles, usage de gMSA pour les services.
Bonnes pratiques à retenir
Moindre connectivité
- Les contrôleurs de domaine n’ont pas besoin d’Internet. Toute exception passe par une zone DMZ ou un proxy dédié avec inspection et journalisation.
- Isoler l’administration dans la forêt ESAE afin de limiter le mouvement latéral.
Gestion des mises à jour
- Déployer un WSUS interne ou un miroir de dépôts logiciels.
- Valider les correctifs en pré‑production avant diffusion aux DC isolés.
Services critiques hors ligne
- Autorité de certification racine hors ligne, CRL distribuées en interne.
- NTP interne synchronisé sur une horloge de référence locale.
Surveillance et journalisation
- Activer l’audit avancé (4688, 4624, 4769, etc.).
- Exporter les journaux vers un SIEM hébergé sur un réseau sécurisé, accessible aux analystes SOC.
Segmentation réseau
- VLAN/VRF distincts pour chaque forêt ; pare‑feu inter‑VLAN contrôlant précisément LDAP/Kerberos/SMB.
- Aucun routage direct des DC vers Internet ; uniquement les flux internes nécessaires à la réplication.
FAQ opérationnelle
Les DC ont‑ils besoin d’Internet pour vérifier des certificats ?
Non, pas directement. Mettez en place des relais CRL/OCSP internes synchronisés depuis l’extérieur par une zone tampon. Les DC ne doivent jamais joindre Internet pour cela.
Comment gérer une application qui exige une résolution DNS publique ?
Les DC n’hébergent pas la récursion. Utilisez des résolveurs dédiés en DMZ, puis autorisez uniquement les serveurs applicatifs à les interroger. Les DC restent strictement internes.
Faut‑il une exception Internet pour un DC FSMO ?
Non. Aucun rôle FSMO ne justifie un accès Internet. Le PDC Emulator requiert une source NTP fiable mais interne.
Et si des équipes ont besoin de naviguer pour administrer ?
La navigation se fait depuis des postes non privilégiés ou via des bastions dédiés, jamais depuis les PAW ni les DC. Séparer clairement administration et usage bureautique.
Checklist de conformité rapide
- Pas de route par défaut vers Internet sur les VLAN DC.
- Récursion DNS désactivée sur les DC.
- WSUS/dépôt interne opérationnel et signé en mode déconnecté.
- Hiérarchie NTP interne configurée, dérive < ±5 min garantie.
- Flux AD limités aux ports nécessaires, journaux collectés dans un SIEM.
- Forêt bastion isolée, PAW sans Internet, sauts d’admin obligatoires.
- Plans de tests : réplication, authentification, restauration, red team.
Conclusion
En appliquant l’isolation Internet à toutes les forêts — et en particulier à la forêt d’accès restreint — vous réduisez drastiquement la surface d’attaque d’Active Directory. Combinez segmentation, chaîne d’approvisionnement interne, supervision rigoureuse et pratiques d’administration à privilèges réduits ; vos DC ne deviendront plus des passerelles vers l’extérieur mais le cœur sécurisé de votre identité d’entreprise.