Votre contrôleur de domaine qui détient le rôle PDC Emulator concentre des fonctions AD sensibles. Voici comment le durcir sans idées reçues : ports, GPO, segmentation Tier‑0, chiffrement, sauvegardes, journalisation et procédures prêtes à l’emploi.
Problématique
L’utilisateur s’interrogeait sur :
- Les mesures de sécurité à appliquer spécifiquement au contrôleur de domaine (DC) qui porte le rôle FSMO PDC Emulator.
- Les restrictions réseau ou stratégies de groupe supplémentaires à envisager (blocage des ports 80/443/53, ouverture sélective, chiffrement des terminaux, etc.).
Messages clés en une minute
- Le PDC Emulator reste un DC comme les autres : même niveau de durcissement, mêmes GPO, mêmes mises à jour, même supervision.
- Ne bloquez jamais arbitrairement les ports AD (LDAP/LDAPS, Kerberos, RPC, SMB, DNS, NTP, GC, DFSR). Restreindre 80/443 est possible si et seulement si aucune fonction ne les utilise — et alors, pour tous les DC.
- Chiffrez le système avec BitLocker pour protéger NTDS.dit et les clés Kerberos.
- Placez tous les DC (dont le PDC) en Tier‑0 : accès exclusif via des postes d’administration durcis.
- Surveillez les événements AD/Kerberos/DNS critiques et sauvegardez fréquemment l’état système.
- Le PDC gère surtout l’heure, les changements de mots de passe, et les verrouillages de comptes ; pas de règle de sécurité « magique » dédiée à ce rôle.
Solutions dégagées
| Axe | Recommandations synthétiques |
|---|---|
| Parité de configuration | Le PDC Emulator reste un DC comme les autres : appliquez exactement les mêmes stratégies de durcissement (GPO « Domain Controllers », baseline CIS/Microsoft, mises à jour, antivirus, surveillance). Les GPO liées aux DC se répliquent automatiquement ; il n’existe pas de paramétrage de sécurité réservé au seul rôle PDC. |
| Ports et pare‑feu | Ne bloquez pas arbitrairement les ports requis par Active Directory : RPC (135 + dynamique 49152‑65535), LDAP/LDAPS (389/636), Kerberos (88), SMB (445), DNS (53), NTP (123), GC (3268/3269), DFSR (5722). Restreindre d’autres ports (80/443) est possible si aucune fonction ne les utilise, mais la règle doit alors s’appliquer à tous les DC. |
| Chiffrement / protection physique | Chiffrez le volume système (BitLocker) sur l’ensemble des DC, afin de protéger la base NTDS.dit et les clés privées Kerberos en cas de vol. |
| Segmentation réseau (Tier‑0) | Isolez tous les DC (dont le PDC) dans un segment Tier‑0 avec pare‑feu inter‑tiers strict ; seules les stations d’administration durcies y accèdent. |
| Surveillance renforcée | Surveillez les journaux du PDC pour les événements : 4624/4625 (authentifications), 4740 (verrouillage), 4720‑4726 (gestion des comptes), 4732‑4733/4728‑4729 (membres de groupes), 5136 (modifications AD), DNS/Kerberos critiques. |
| Sauvegardes | Effectuez des sauvegardes de l’état système fréquentes, en particulier sur le PDC Emulator, car il détient les rôles FSMO critiques. |
| Services spécifiques au PDC | Vérifiez la synchronisation horaire (le PDC du domaine racine est la source NTP interne), la gestion des verrous de compte et la gestion prioritaire des changements de mot de passe. Pas de règle de sécurité supplémentaire requise, mais visez la haute disponibilité (un DC secondaire prêt à devenir source de temps de secours). |
Mesures de durcissement transverses pour tous les contrôleurs de domaine
- Baselines & mises à jour : appliquez une baseline reconnue (Microsoft/CIS) adaptée aux DC, patchs de sécurité au plus tôt, redémarrages planifiés, et inventaire des correctifs.
- Réduction de surface d’attaque : désactivez Print Spooler, WebClient, services IIS non utilisés, SMBv1. Limitez les rôles installés au strict nécessaire (DNS, AD DS, DFSR si utilisé).
- Authentification : privilégiez AES pour Kerberos, désactivez DES et réduisez progressivement RC4. Durcissez NTLM : auditez puis restreignez NTLM, activez « Send NTLMv2 response only ».
- Restriction d’ouverture de session : Deny log on locally et Deny log on through Remote Desktop Services pour tout compte non‑admin ; seules des identités Tier‑0 via des postes d’administration durcis sont autorisées.
- EDR/AV : activez un EDR adapté aux DC et configurez les exclusions spécifiques (voir plus bas).
- LSA Protection : activez RunAsPPL pour LSASS et, si pris en charge, les protections VBS/HVCI sur les hôtes.
- Journalisation avancée : activez l’Advanced Audit Policy, augmentez la taille des journaux Sécurité, DNS, Directory Services, DFSR et mettez en place la collecte centralisée (WEF/SIEM).
Pare‑feu et ports réseau indispensables
Un DC — y compris le PDC — doit communiquer sur un socle de ports bien défini. Les bloquer à l’aveugle cause des pannes aléatoires, y compris de changement de mot de passe et de verrouillage de comptes.
| Service | Ports | Direction | Usage | Remarques |
|---|---|---|---|---|
| Kerberos (KDC) | TCP/UDP 88 | Entrant/Sortant | Authentification | Préférez AES ; synchronisation horaire indispensable. |
| LDAP | TCP/UDP 389 | Entrant | Annuaire | Exiger la signature ; planifier la migration vers LDAPS. |
| LDAPS | TCP 636 | Entrant | LDAP chiffré | Certificat DC valide (EKU Server Auth). |
| Global Catalog | TCP 3268/3269 | Entrant | Requêtes multi‑domaines | 3269 pour GC chiffré. |
| DNS | TCP/UDP 53 | Entrant/Sortant | Résolution et enregistrements SRV | Restreindre récursion et transferts. |
| RPC Endpoint Mapper | TCP 135 | Entrant/Sortant | Découverte des services RPC | Indispensable à AD DS/DFSR/WMI. |
| RPC dynamiques | TCP 49152‑65535 | Entrant/Sortant | Replic., WMI, AD Web Services, etc. | Plage par défaut sur Windows récents. |
| SMB | TCP 445 | Entrant/Sortant | SYSVOL/NETLOGON | Signature SMB obligatoire sur DC. |
| DFSR | TCP 5722 | Entrant/Sortant | Réplication SYSVOL (DFSR) | Si DFSR utilisé (recommandé). |
| NTP | UDP 123 | Entrant/Sortant | Service de temps | Critique pour Kerberos et PDC. |
| RDP (admin) | TCP 3389 | Entrant | Administration | Limiter aux PAW et au segment Tier‑0. |
| WinRM (WEF/gestion) | TCP 5985/5986 | Entrant | PowerShell Remoting / WEF | Privilégiez 5986 (TLS). |
À propos des ports 80/443 : ils peuvent être fermés sur les DC si vous n’y hébergez pas de service HTTP(S) (IIS, API d’agent, etc.). Faites‑le de façon homogène sur tous les DC et vérifiez les dépendances (WSUS, EDR cloud, télémétrie, CRL/OCSP, etc.).
Réduction contrôlée des ports RPC dynamiques
Vous pouvez réduire la plage RPC dynamique pour faciliter le filtrage inter‑sites. Cependant, restreindre trop agressivement augmente le risque d’échecs de réplication ou d’instrumentation (WMI). Procédez par étapes :
- Allouez une plage dédiée (par ex.
TCP 55000‑56000) dans le pare‑feu entre DC et serveurs d’administration. - Documentez / supervisez les refus pour ajuster la capacité.
- Testez systématiquement la réplication, l’édition de GPO et les requêtes LDAP/GC après tout changement.
Spécificités du rôle PDC Emulator
Le PDC n’introduit pas d’exigences de sécurité « exotiques ». Il assume cependant des rôles prioritaires :
- Service de temps : le PDC du domaine racine forestier est la source de temps interne. Les autres DC et membres se synchronisent via la hiérarchie de domaine.
- Mot de passe & verrouillage : les changements de mots de passe sont préférentiellement traités par le PDC, tout comme la logique de verrouillage de compte. En cas de « bad password », un DC peut interroger le PDC pour vérifier le mot de passe le plus récent.
- Édition de GPO : par défaut, les consoles GPMC se connectent au PDC pour l’édition afin d’éviter les conflits de versions.
- Compat héritée : rôle maître navigateur et interactions avec anciens clients (rare aujourd’hui).
Bonnes pratiques de temps (W32Time)
Sur le PDC du domaine racine :
w32tm /config /manualpeerlist:"<vos_pairs_NTP>" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync /force
w32tm /query /status
Sur les autres DC et membres :
w32tm /config /syncfromflags:domhier /update
w32tm /resync
Assurez‑vous que UDP 123 est autorisé selon le flux défini et prévoyez un DC de secours prêt à reprendre la fiabilité (/reliable:yes) si le PDC est indisponible.
Haute disponibilité du rôle PDC
- Placez le PDC sur un hôte robuste (hyperviseur dédié, stockage redondé, alerte matérielle).
- Préparez la prise de rôle contrôlée : désignez un DC de secours et documentez la commande
Move-ADDirectoryServerOperationMasterRole -OperationMasterRole PDCEmulator. - En cas d’incident majeur, seize le rôle et recomposez ensuite ; évitez tout retour à un snapshot antérieur.
Segmentation réseau et gestion des accès privilégiés (Tier‑0)
La protection d’AD repose sur une séparation stricte :
- Tier‑0 : DC, PKI racine/émission, AAD Connect (si présent), serveurs PAM/Privileged Identity et bastions.
- Accès : seuls des Privileged Access Workstations (PAW) durcis, multi‑facteur, peuvent atteindre le Tier‑0 (RDP/WinRM/PowerShell).
- Pare‑feu inter‑tiers : liste blanche stricte ; tout le reste est refusé par défaut.
- Comptes : admins dédiés (Domain Admins, Enterprise Admins) non réutilisés en dehors du Tier‑0 ; utilisez des comptes « temps limité » (JIT) quand possible.
Renforcement LDAP et Kerberos
- LDAPS : déployez des certificats serveurs valides sur les DC et forcez LDAPS pour les applications. Activez la signature LDAP côté serveur (Require Signing) et la Channel Binding selon la compatibilité (When supported puis Always).
- Kerberos : désactivez DES, privilégiez AES128/256 ; s’assurer que les comptes de service utilisent des clés AES (gMSA recommandé). Gardez une tolérance d’horloge adaptée (par défaut 5 min) et auditez les échecs KDC.
- NTLM : passez par une phase Audit puis restreignez progressivement (« Deny for domain accounts », « Deny to remote servers », etc.) selon votre compatibilité.
DNS du contrôleur de domaine
- Mises à jour dynamiques : « Secure only » sur les zones AD‑intégrées.
- Transferts de zone : désactivés ou limités explicitement à des pairs autorisés.
- Récursion : désactivée si le DC n’est pas résolveur pour les postes ; sinon, utilisez des forwarders et restreignez par ACL/pare‑feu.
- Journalisation : activez une journalisation DNS adaptée (diagnostic), avec rétention suffisante.
Surveillance, alerting et événements à suivre de près
| Journal | ID | Signification | Action/alerte |
|---|---|---|---|
| Sécurité | 4624/4625 | Connexions réussies/échouées | Détecter les rafales d’échecs, comptes sensibles. |
| Sécurité | 4740 | Verrouillage de compte | Corréler source/contrôleur, alerter sur anomalies. |
| Sécurité | 4720‑4726 | Création/suppression de comptes | Alerte immédiate hors fenêtres de changement. |
| Sécurité | 4728‑4729 / 4732‑4733 | Ajout/retrait dans des groupes (domain local/global) | Surveiller DA/EA/BA, groupes d’applications. |
| Directory Services | 2886/2887/2889 | Clients LDAP non signés/simple bind | Plan de remédiation LDAPS, blocage progressif. |
| Directory Services | 1644 | Requêtes LDAP coûteuses | Optimiser index/filtrage, revoir applis. |
| DNS Server | 5501+ | Erreurs de résolution/MAJ dynamiques | Diagnostic réseau, sécurisation zones. |
| DFSR | 4112/5002 | Réplication SYSVOL en échec | Corriger connectivité, espace disque, backlog. |
| KDC | 16x / 4771 | Échecs Kerberos (horloge, types de chiffrement) | Vérifier temps, politiques de chiffrement. |
Antivirus/EDR : exclusions adaptées aux DC
Un EDR/antivirus est indispensable, mais mal configuré, il peut dégrader AD. Ajoutez des exclusions raisonnables (à adapter selon l’éditeur) :
- Base AD :
%SystemRoot%\NTDS\NTDS.dit,%SystemRoot%\NTDS\*.log,%SystemRoot%\NTDS\*.chk,%SystemRoot%\NTDS\Temp.edb. - SYSVOL/NETLOGON :
%SystemRoot%\SYSVOL\*. - DFSR :
%SystemDrive%\System Volume Information\DFSR\*. - Fichiers transaction et processus AD DS : lsass.exe (surveillance compatible PPL), dfsr.exe, ntdsutil.
Conservez néanmoins l’anti‑malware actif et la télémétrie EDR riche sur les DC, avec des règles spécifiques pour les outils d’admin légitimes (PSExec, PowerShell) en audit first.
Sauvegardes, PRA et scénarios d’incident
- État système quotidien sur tous les DC, avec rétention adaptée et copies hors ligne. Testez les restaurations bare‑metal et authoritative (environnement de pré‑prod).
- Active Directory Recycle Bin activée pour les restaurations de niveau objet sans démarrer en DSRM.
- Perte du PDC : si le DC est irrécupérable, seize le rôle PDC depuis un autre DC sain, puis reconstruisez un nouveau DC et rééquilibrez les rôles FSMO.
- Snapshots VM : ne jamais revenir à un snapshot ancien d’un DC en production. Utilisez des sauvegardes compatibles VM‑Generation ID/VSS.
GPO ciblées sur le PDC (si vous devez faire une exception)
La règle d’or : évitez d’éditer la GPO « Default Domain Controllers ». Créez des GPO dédiées liées à l’OU « Domain Controllers » et, pour cibler le seul PDC, utilisez un filtrage WMI :
SELECT * FROM Win32_ComputerSystem WHERE DomainRole = 5
Ou un security filtering s’appuyant sur un groupe contenant dynamiquement le PDC actuel. Documentez toute exception et limitez‑la dans le temps.
Procédures et scripts utiles
| Objectif | Commande / Script | Notes |
|---|---|---|
| Identifier le PDC | (Get-ADDomain).PDCEmulator ou netdom query fsmo | À intégrer dans vos scripts d’inventaire. |
| Basculer le rôle PDC | Move-ADDirectoryServerOperationMasterRole -OperationMasterRole PDCEmulator | Basculer à froid pendant une fenêtre de maintenance. |
| Vérifier la réplication | repadmin /replsummary, dcdiag /v | Inclure dans le runbook de changement de rôle. |
| Durcir RDP côté DC | New-NetFirewallRule -DisplayName "RDP Admin Tier-0" -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress <PAW/Tier0 CIDR> -Action Allow | Audit → Appliquer → Surveiller. |
| Exiger la signature LDAP | GPO : « Domain controller: LDAP server signing requirements » = Require signing | Phase de compatibilité préalable pour les applis. |
| Exiger SMB signé | GPO : « Microsoft network server: Digitally sign communications (always) » = Enabled | Actif par défaut sur DC, vérifiez l’héritage. |
Checklist de déploiement/contrôle
- Baselines DC appliquées et dérives surveillées.
- BitLocker actif ; clés de récupération stockées en sécurité (coffre/PKI) et testées.
- Services inutiles désactivés (Spooler, WebClient, IIS, SMBv1…).
- LDAPS fonctionnel ; signature et channel binding configurées.
- Kerberos en AES ; DES désactivé, RC4 réduit au minimum.
- NTLM en mode audit puis restriction progressive.
- Pare‑feu : ports AD requis ouverts, 80/443 fermés si non utilisés, règles RDP/WinRM limitées au Tier‑0.
- Temps : PDC du domaine racine synchronisé sur des pairs de confiance ; DC/membres en domhier.
- DNS : MAJ dynamiques sécurisées, transferts limités, récursion contrôlée.
- Journaux étendus, WEF/EDR vers SIEM, alertes sur événements critiques.
- Sauvegardes état système quotidiennes + tests de restauration.
- Tier‑0 : segmentation stricte, PAW obligatoires, MFA.
- Runbooks : bascule/seize FSMO, perte du PDC, reprise de service, communication d’incident.
FAQ rapides
Faut‑il des GPO « spéciales PDC » ? Non. Les GPO « Domain Controllers » s’appliquent à tous les DC. Ciblez le PDC uniquement si une exception est absolument nécessaire et documentée.
Puis‑je fermer 80/443 ? Oui si aucun service ne les utilise (WSUS, EDR cloud, CRL/OCSP, API agents). Si vous les fermez, faites‑le sur tous les DC et validez les dépendances.
Le PDC doit‑il être isolé dans une OU à part ? Pas nécessaire. Pour des exceptions ciblées, utilisez un filtrage WMI/security filtering plutôt que de créer une OU distincte.
Le PDC doit‑il être physique ? Pas obligatoirement. La virtualisation est acceptable si vous respectez les bonnes pratiques (pas de snapshots de retour arrière, sauvegardes VSS compatibles, ressources garanties).
Conclusion
Le rôle d’émulateur PDC ne justifie aucune mesure supplémentaire isolée. La sécurité d’AD passe par un durcissement homogène de l’ensemble des contrôleurs de domaine, une segmentation Tier‑0 stricte, une gestion rigoureuse des ports requis, le chiffrement, la supervision continue et des sauvegardes éprouvées. Concentrez‑vous sur la qualité d’exécution : des GPO bien pensées, des journaux exploitables, des procédures testées et une hygiène d’administration exemplaire. C’est ce qui protège réellement votre PDC… et tout votre Active Directory.
Informations complémentaires utiles
- GPO ciblées : si vous deviez tout de même appliquer un paramètre unique au PDC, placez‑le dans une GPO dédiée liée à l’OU « Domain Controllers » avec filtre WMI/security filtering ; évitez d’éditer la GPO « Default Domain Controllers ».
- Authentification privilégiée : implémentez ESAE/Tiering ou des Privileged Access Workstations pour limiter l’exposition des comptes d’administration.
- Renforcement LDAP : activez LDAPS et signez/chiffrez le trafic LDAP via GPO (« Domain controller: LDAP server signing requirements »).
- Contrôle de périphériques : désactivez ou restreignez les lecteurs amovibles/USB sur tous les DC.
- Limitation des services : supprimez ou désactivez tout rôle ou fonctionnalité Windows non indispensable (IIS, DFS Namespaces inutilisés, etc.).
En résumé : appliquez un durcissement homogène à tous les DC, puis sécurisez l’infrastructure AD globalement selon les bonnes pratiques. Le PDC n’appelle pas une « super‑sécurité » unique ; il appelle une excellence opérationnelle sans compromis.