Active Directory : haute disponibilité NTP pour le PDC Emulator (éviter le SPOF du service de temps)

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.

Sommaire

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

ValeurBits activésEffet à l’annonceScénario recommandé
0x5TimeServer (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.
0xAAlwaysTimeServer (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 modes NTP et NT5DS ; 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 :

FlagSignificationQuand l’utiliserExemple
0x1SpecialPoll : utilise SpecialPollInterval (sondage à intervalles fixes).Recommandé en mode NTP contrôlé.ntp1.exemple.net,0x1
0x2UseAsFallbackOnly : seulement si les autres pairs échouent.Pour un pair « secours ».ntp4.exemple.net,0xA (0x8+0x2)
0x4SymmetricActive : négociation symétrique (rare en client Windows).Cas particuliers (appliances spécifiques). 
0x8Client : 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

  1. 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.
  2. Configurer le PDC‑E et au moins un DC par site avec ces pairs (flags 0x9) et placer Type sur NTP. Sur les autres DC, laisser NT5DS 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.
  3. Régler AnnounceFlags sur les DC racines : 0xA (ou 0x5 selon la topologie). Laisser 0x0 ailleurs.
  4. Redémarrer le service W32Time sur les machines modifiées puis exécuter w32tm /resync.
  5. 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 ou 0xA), un DC supplémentaire « Reliable » avec les mêmes pairs.
  • Sites distants : un DC « Reliable » par site, AnnounceFlags=0xA si le WAN est instable, sinon 0x5. 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ètreEmplacementRôleValeur conseillée (ex.)Commentaire
TypeHKLM\...\W32Time\ParametersMode de synchroNTP sur PDC‑E et DC « Reliable »; NT5DS ailleursNTP = sources explicites ; NT5DS = hiérarchie AD.
NtpServerHKLM\...\W32Time\ParametersListe de pairsntp1,0x9 ntp2,0x9 ntp3,0x93+ sources indépendantes.
SpecialPollIntervalHKLM\...\W32Time\TimeProviders\NtpClientIntervalle de sondage3600 (1h)Ajuster à 900–3600 s selon la stabilité.
AnnounceFlagsHKLM\...\W32Time\ConfigAnnonce DC & fiabilité0x5 ou 0xASuivant la stabilité du site.
MaxPosPhaseCorrection / MaxNegPhaseCorrectionHKLM\...\W32Time\ConfigCorrections max3600–86400 (sec)Empêche les bonds excessifs.
EventLoggingHKLM\...\W32Time\ConfigNiveau de log1 (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

  1. 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.
  2. 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 puis w32tm /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).
  3. 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).
  4. 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 du NtpServer (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, puis nltest /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 avec NtpServer renseigné (0x9) et SpecialPollInterval 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 et SpecialPollInterval de 15–60 min.
  • Plusieurs DC « Reliable » (AnnounceFlags=0x5 ou 0xA) partageant les mêmes pairs.
  • Clients en NT5DS ou NTP vers DC : basculement automatique.
  • Supervision w32tm /monitor, journaux W32Time, tests de bascule planifiés.
Sommaire