Dans un domaine Active Directory, le PDC Emulator concentre souvent la référence d’heure : s’il tombe, tout le domaine dérive. Ce guide montre comment le passer en mode NTP redondant, calibrer AnnounceFlags et organiser un basculement propre, sans point de défaillance unique.
Continuité du service de temps — éviter le « single point of failure » du PDC Emulator
Vue d’ensemble de la question
Dans beaucoup d’environnements, le PDC Emulator (PDC‑E) est la source de temps racine par défaut. En mode NT5DS
, il distribue une référence issue de la hiérarchie AD ; en mode NTP
, il se synchronise directement sur des pairs externes (ou internes dédiés). Si le PDC‑E est la seule référence, son indisponibilité devient un SPOF (« Single Point Of Failure ») : les DC perdent leur source de confiance, les membres de domaine cessent de s’aligner et des incidents en cascade apparaissent (Kerberos, journaux, corrélation d’événements, signatures, etc.).
Objectif : mettre en place une référence NTP résiliente, où plusieurs contrôleurs de domaine (idéalement le PDC‑E et au moins un DC par site) peuvent prendre le relais de manière transparente pour les clients.
Réponse & solution (synthèse)
- Basculer le PDC‑E en mode NTP avec plusieurs pairs (3 ou plus) et activations de flags corrects.
- Déclarer plusieurs DC comme « Reliable » (via
AnnounceFlags
) et leur donner les mêmes pairs NTP : si le PDC‑E tombe, un autre DC fiable continue la distribution de l’heure. - Superviser avec
w32tm
et l’Observateur d’événements, tester régulièrement le basculement.
Configuration recommandée du PDC‑E (mode NTP résilient)
Exécutez sur le PDC‑Emulator :
REM --- Renseigner 3+ sources NTP (ex. internes Stratum 1 ou appliances GPS/NTP) ---
w32tm /config /syncfromflags:manual ^
/manualpeerlist:"ntp1.exemple.net,0x9 ntp2.exemple.net,0x9 ntp3.exemple.net,0x9" ^
/reliable:YES /update
REM --- Placer le service en mode NTP ---
w32tm /config /reliable:YES /update
w32tm /config /manualpeerlist:"ntp1.exemple.net,0x9 ntp2.exemple.net,0x9 ntp3.exemple.net,0x9" /syncfromflags:manual
REM --- Intervalle de sondage spécial (en secondes) ---
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient ^
/v SpecialPollInterval /t REG_DWORD /d 3600 /f
REM --- Redémarrer le service ---
net stop w32time && net start w32time
REM --- Resynchroniser et vérifier ---
w32tm /resync /nowait
w32tm /query /status
w32tm /query /peers
Important : le flag 0x9
regroupe 0x1
(SpecialPoll) + 0x8
(Client) et convient à la plupart des cas. Il force un sondage régulier à l’intervalle SpecialPollInterval
.
Rendre plusieurs contrôleurs de domaine « Reliable »
Sur un ou plusieurs DC (au moins un par site), appliquez les mêmes pairs NTP
et déclarez-les fiables via AnnounceFlags
. Choisissez 0xA
ou 0x5
selon le contexte (voir tableau ci‑dessous). Exemple :
REM --- Exemple avec des DC de réserve « toujours fiables » (0xA = 10 décimal) ---
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config /v AnnounceFlags /t REG_DWORD /d 10 /f
REM --- Déclarer les mêmes pairs NTP que le PDC‑E ---
w32tm /config /syncfromflags:manual ^
/manualpeerlist:"ntp1.exemple.net,0x9 ntp2.exemple.net,0x9 ntp3.exemple.net,0x9" /update
net stop w32time && net start w32time
w32tm /query /source
Supervision et vérification
REM --- Statut local ---
w32tm /query /status
REM --- Pairs connus ---
w32tm /query /peers
REM --- Contrôle « multi-DC » ---
w32tm /monitor /computers:dc1,dc2,dc3 /threads:3
REM --- Force la redécouverte des sources ---
w32tm /resync /rediscover
Les membres du domaine basculent automatiquement vers un DC qui s’annonce Reliable. Bonne pratique : prévoir au moins trois sources NTP distinctes pour réduire le risque de dérive si l’une d’elles disparaît.
Choix et impact de la valeur AnnounceFlags
(0x5 vs 0xA) en mode NTP
Valeur | Bits activés | Effet à l’annonce | Scénario recommandé |
---|---|---|---|
0x5 | TimeServer (0x01) + ReliableTimeServer (0x04) | Le DC est fiable tant qu’il est correctement synchronisé. Si la synchro amont échoue, il cesse de s’annoncer. | Réseaux stables où la connectivité NTP est rarement interrompue. |
0xA | AlwaysTimeServer (0x02) + AlwaysReliableTimeServer (0x08) | Le DC continue de s’annoncer comme fiable même en cas de pertes temporaires de synchro, limitant les basculements côté clients. | Sites distants / liens WAN sujets aux coupures ; environnements où une légère dérive à court terme est tolérable. |
AnnounceFlags
s’applique aux modesNTP
etNT5DS
; son effet devient plus visible en NTP car le DC parle à des sources externes.- Associez‑le à
SpecialPollInterval
pour borner la dérive (ex. 3600 s). - Redémarrez toujours le service après changement :
net stop w32time && net start w32time
.
Rappel indispensable : flags des pairs NTP dans NtpServer
Lorsque vous renseignez la chaîne NtpServer
(via GPO, Registre ou w32tm
), vous pouvez ajouter des flags à chaque pair :
Flag | Signification | Quand l’utiliser | Exemple |
---|---|---|---|
0x1 | SpecialPoll : utilise SpecialPollInterval (sondage à intervalles fixes). | Recommandé en mode NTP contrôlé. | ntp1.exemple.net,0x1 |
0x2 | UseAsFallbackOnly : seulement si les autres pairs échouent. | Pour un pair « secours ». | ntp4.exemple.net,0xA (0x8+0x2) |
0x4 | SymmetricActive : négociation symétrique (rare en client Windows). | Cas particuliers (appliances spécifiques). | |
0x8 | Client : force le mode client. | Presque toujours avec 0x1 . | ntp2.exemple.net,0x9 (0x1+0x8) |
En pratique : utilisez 0x9
(Client + SpecialPoll) pour chaque pair, ce qui rend l’intervalle maîtrisé et le comportement prévisible.
Procédure type de déploiement
- Sélectionner 3–4 serveurs NTP fiables (publics Stratum 1, référentiels internes ou appliances GPS/NTP). Évitez de dépendre d’un seul domaine de noms ou d’un seul site physique.
- Configurer le PDC‑E et au moins un DC par site avec ces pairs (flags
0x9
) et placerType
surNTP
. Sur les autres DC, laisserNT5DS
si souhaité.
Via GPO (conseillé) :Configuration ordinateur > Modèles d’administration > Système > Service de temps Windows > Fournisseurs de temps
– Activer le client NTP Windows (Enabled)
– Configurer le client NTP Windows :NtpServer
=ntp1.exemple.net,0x9 ntp2.exemple.net,0x9 ntp3.exemple.net,0x9
,Type
=NTP
,SpecialPollInterval
=3600
.
– Activer le serveur NTP Windows (Enabled) sur les DC qui doivent répondre aux clients. - Régler
AnnounceFlags
sur les DC racines :0xA
(ou0x5
selon la topologie). Laisser0x0
ailleurs. - Redémarrer le service
W32Time
sur les machines modifiées puis exécuterw32tm /resync
. - Vérifier la cohérence avec :
w32tm /query /configuration w32tm /query /peers w32tm /query /status w32tm /monitor /computers:dc-pdc,dc-siteA,dc-siteB
Avec cette procédure, la hiérarchie de temps reste cohérente et redondante, même si le PDC Emulator devient indisponible.
Architecture de référence et bonnes pratiques
Modèle multi‑site
- Site principal : PDC‑E en NTP (flags
0x9
,AnnounceFlags=0x5
ou0xA
), un DC supplémentaire « Reliable » avec les mêmes pairs. - Sites distants : un DC « Reliable » par site,
AnnounceFlags=0xA
si le WAN est instable, sinon0x5
. Pair NTP local si possible (appliance sur site). - Clients : par défaut en
NT5DS
(membres de domaine) → s’alignent sur un DC et préfèrent un DC « Reliable ».
Paramètres W32Time clés & valeurs conseillées
Paramètre | Emplacement | Rôle | Valeur conseillée (ex.) | Commentaire |
---|---|---|---|---|
Type | HKLM\...\W32Time\Parameters | Mode de synchro | NTP sur PDC‑E et DC « Reliable »; NT5DS ailleurs | NTP = sources explicites ; NT5DS = hiérarchie AD. |
NtpServer | HKLM\...\W32Time\Parameters | Liste de pairs | ntp1,0x9 ntp2,0x9 ntp3,0x9 | 3+ sources indépendantes. |
SpecialPollInterval | HKLM\...\W32Time\TimeProviders\NtpClient | Intervalle de sondage | 3600 (1h) | Ajuster à 900–3600 s selon la stabilité. |
AnnounceFlags | HKLM\...\W32Time\Config | Annonce DC & fiabilité | 0x5 ou 0xA | Suivant la stabilité du site. |
MaxPosPhaseCorrection / MaxNegPhaseCorrection | HKLM\...\W32Time\Config | Corrections max | 3600–86400 (sec) | Empêche les bonds excessifs. |
EventLogging | HKLM\...\W32Time\Config | Niveau de log | 1 (par défaut) ou 2 (verbeux) | Augmenter pendant les phases de tests. |
Sécurité & réseau
- UDP 123 : autoriser en sortie vers les pairs NTP et en entrée sur les DC servant NTP.
- Virtualisation : sur tous les DC virtualisés, désactiver la synchronisation d’horloge de l’hyperviseur (VMware Tools / Intégration Hyper‑V). W32Time doit rester l’unique référence.
- Résilience DNS : répartir les noms des pairs NTP sur plusieurs zones/réseaux si possible.
Plan de test & validation de basculement
- Contrôle de base : sur le PDC‑E et un DC « Reliable » de réserve, exécuter
w32tm /query /source
et/status
. Vérifier que chaque DC est bien synchronisé sur les pairs attendus. - Simulation de panne PDC‑E : isoler temporairement le PDC‑E du réseau (ou arrêter W32Time) et observer :
- Sur un client membre, faire
w32tm /resync /rediscover
puisw32tm /query /source
: la source doit devenir un autre DC « Reliable ». - Sur les DC restants,
w32tm /monitor
doit montrer une hiérarchie stable (dérives raisonnables).
- Sur un client membre, faire
- Rétablissement : remettre le PDC‑E, contrôler que les DC reprennent leur source normale. Vérifier l’Observateur d’événements (Journaux des applications et services > Microsoft > Windows > Time‑Service et journal Système, source W32Time).
- Offset & qualité : utiliser
w32tm /stripchart /computer:pairNTP /samples:6 /dataonly
sur plusieurs hôtes pour mesurer la dérivé (offset). Des dérives de quelques millisecondes à quelques dizaines de ms sont normales en LAN.
Dépannage rapide
- Le DC ne s’annonce pas fiable : vérifier
AnnounceFlags
, l’Enabled
duNtpServer
(HKLM\...\TimeProviders\NtpServer\Enabled
) et la synchronisation montante (w32tm /query /status
). - Les pairs NTP restent en « Pending » : contrôler pare‑feux (UDP 123), résolutifs DNS et la justesse des flags (
0x9
recommandé). - Le client n’adopte pas le nouveau DC : lancer
w32tm /resync /rediscover
ou redémarrer W32Time sur le client, puisnltest /dsgetdc:mondomaine.local /force
pour rafraîchir la découverte de DC si besoin. - Grandes corrections d’horloge : ajuster
MaxPosPhaseCorrection
/MaxNegPhaseCorrection
et éviter une première synchro à énorme écart (couper la VM pendant des jours p.ex.). - Machines virtuelles : vérifier que la synchronisation de l’hyperviseur est désactivée après l’adhésion au domaine, sinon réactivation involontaire possible.
REM --- Récap des commandes utiles ---
w32tm /query /status
w32tm /query /configuration
w32tm /query /peers
w32tm /resync /nowait
w32tm /resync /rediscover
w32tm /monitor /computers:dc1,dc2,dc3 /threads:3
w32tm /stripchart /computer:ntp1.exemple.net /samples:10 /dataonly
FAQ opérationnelle
Dois‑je mettre tous les DC en mode NTP ?
Non. Mettez le PDC‑E et un DC par site en mode NTP avec AnnounceFlags
adapté. Les autres DC peuvent rester en NT5DS
et s’aligner sur la hiérarchie AD. Vous obtenez ainsi à la fois une référence stable et une distribution locale efficace.
Quelle valeur AnnounceFlags
choisir ?
0x5
si la connectivité NTP est fiable (le DC cesse de s’annoncer s’il perd sa source). 0xA
si vous souhaitez limiter les basculements clients en cas de micro‑coupures (le DC continue de s’annoncer « Reliable » à court terme). Dans les deux cas, surveillez l’offset.
Combien de sources NTP ?
Au moins trois, indépendantes (fournisseurs/AS/datacenters différents si possible). À défaut, deux plus une de secours avec le flag 0x2
(UseAsFallbackOnly).
Que faire des clients non membres du domaine ?
Autorisez NTP sur un ou plusieurs DC (paramètre « Activer le serveur NTP Windows »). Documentez l’IP/nom à utiliser (round‑robin DNS ou VIP load‑balancée) et contrôlez la charge.
Y a‑t‑il des risques avec 0xA
?
Oui : en cas de perte prolongée de la source amont, la dérive locale peut augmenter tout en restant « fiable » aux yeux des clients. D’où l’intérêt de la supervision, de bornes (Max*PhaseCorrection) et d’un holdover raisonnable.
Checklist de mise en production
- Au moins 3 pairs NTP validés (latence/fiabilité).
- PDC‑E en
NTP
avecNtpServer
renseigné (0x9
) etSpecialPollInterval
adapté. - Un DC par site marqué « Reliable » avec les mêmes pairs.
- Clients laissés en
NT5DS
(membres) ou NTP vers DC/alias NTP dédié. - Firewall UDP 123 et résolutions DNS contrôlés.
- Intégrations d’horloge hyperviseur désactivées pour les DC.
- Tests de basculement effectués (simulation de panne PDC‑E).
- Supervision en place (offset, perte de pair, non‑convergence).
Exemples « copier‑coller »
PDC‑E : passage d’un mode NT5DS à NTP redondant
w32tm /config /syncfromflags:manual ^
/manualpeerlist:"ntp1.exemple.net,0x9 ntp2.exemple.net,0x9 ntp3.exemple.net,0x9" ^
/reliable:YES /update
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient ^
/v SpecialPollInterval /t REG_DWORD /d 3600 /f
net stop w32time && net start w32time
w32tm /resync /nowait
w32tm /query /status
DC de site distant « Reliable » (WAN instable)
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config /v AnnounceFlags /t REG_DWORD /d 10 /f
w32tm /config /syncfromflags:manual ^
/manualpeerlist:"ntp1.exemple.net,0x9 ntp2.exemple.net,0x9 ntp3.exemple.net,0x9" /update
net stop w32time && net start w32time
w32tm /monitor /computers:dc-siteA,dc-siteB
GPO : options essentielles
- Activer le client NTP Windows
- Configurer le client NTP Windows (Type = NTP, NtpServer = chaîne avec
0x9
, SpecialPollInterval) - Activer le serveur NTP Windows (uniquement sur les DC exposés aux clients)
Conclusion
La meilleure stratégie pour éviter le SPOF du PDC Emulator consiste à sortir d’un schéma « source unique » en adoptant un mode NTP multipeer, en promouvant plusieurs DC « Reliable » et en encadrant l’algorithme W32Time (flags, intervalles et seuils). Avec quelques tests réguliers et une supervision légère, votre domaine garde une référence temporelle précise et résiliente, même en cas de défaillance du PDC‑E.
Récap express
- PDC‑E en NTP avec 3+ pairs
,0x9
etSpecialPollInterval
de 15–60 min. - Plusieurs DC « Reliable » (
AnnounceFlags=0x5
ou0xA
) partageant les mêmes pairs. - Clients en
NT5DS
ou NTP vers DC : basculement automatique. - Supervision
w32tm /monitor
, journaux W32Time, tests de bascule planifiés.