L’horloge Windows dérive : le correctif NTP que l’on oublie

Ce qu’est vraiment la dérive horaire (et pourquoi Windows est particulier)

La dérive horaire, c’est l’horloge système qui s’écarte de l’heure « vraie ». Ça sonne philosophique jusqu’à ce que vous essayiez de valider un certificat marqué « pas encore valide » ou « expiré » parce que votre machine croit que nous sommes mardi dernier. La dérive est normale ; les cristaux sont imparfaits, les changements de température existent, et les machines virtuelles dépendent de l’ordonnancement avec sa gigue et des vCPU en pause.

Ce qui n’est pas normal, c’est la dérive non bornée. NTP (Network Time Protocol) existe pour que les machines puissent s’ajuster en continu. Mais Windows n’est pas un client NTP générique comme on l’imagine souvent. Le service Windows Time (w32time) est conçu principalement pour maintenir la cohérence d’un domaine Windows, pas pour remporter un concours de précision.

Dans un environnement Active Directory, la conception « correcte » est une hiérarchie : les postes et serveurs membres se synchronisent depuis les contrôleurs de domaine, les contrôleurs de domaine se synchronisent vers le haut, et l’émulateur PDC du root de la forêt est celui que vous traitez comme autorité temporelle (avec des sources NTP externes). Si vous battez en brèche ce modèle en pointant des membres de domaine au hasard vers des serveurs NTP externes, vous pouvez créer un « split-brain » horaire et passer le reste de la journée à expliquer pourquoi Kerberos est furieux.

De plus : Windows a des opinions sur le stepping vs le slewing (sauter l’heure vs ajuster progressivement), sur les intervalles d’interrogation, et sur la mise en attente du temps quand une source est instable. En outre, les hyperviseurs et les outils invités « corrigent » souvent l’heure aussi — parfois par la force. Deux gardiens du temps dans une même machine, ce n’est pas de la redondance ; c’est un litige de garde.

Blague #1 : La dérive horaire, c’est comme la dette technique : elle se compound en silence jusqu’à votre prochaine panne, et alors tout le monde a soudainement des opinions très tranchées.

Faits et historique à utiliser dans un postmortem

Ce ne sont pas des anecdotes pour le plaisir. Ce sont les petits éléments de contexte qui vous aident à choisir le bon correctif et à le défendre lors d’une revue de changement.

1. NTP est ancien (années 1980) et éprouvé. Il précède la plupart des systèmes qu’il maintient aujourd’hui honnêtes. Le protocole a évolué pour tolérer la gigue réseau et les horloges imparfaites.
2. Windows Time (w32time) a priorisé la cohérence de domaine. Microsoft l’a construit pour garder Kerberos et AD heureux, pas pour rivaliser avec des démons NTP haute précision utilisés en laboratoire.
3. Kerberos a une tolérance stricte de décalage d’horloge. Si le client et le DC diffèrent de plus qu’une petite fenêtre, l’authentification échoue d’une manière qui ressemble à des « problèmes aléatoires de connexion ».
4. La virtualisation a rendu la dérive plus fréquente. Les VM peuvent être mises en pause, migrées, désordonnancées ou reprises depuis des snapshots ; tout cela peut perturber une horloge naïve.
5. La confusion SNTP vs NTP persiste. Beaucoup de systèmes répondent en style « NTP simple » mais n’implémentent pas entièrement les algorithmes de discipline NTP. w32time s’est historiquement comporté plus proche de SNTP dans certains scénarios.
6. Les secondes intercalaires sont un vrai danger opérationnel. Différentes plateformes les gèrent différemment (sauter à la seconde intercalaire, la lisser, ou l’ignorer). Un traitement incohérent peut créer de petites mais nettes divergences temporelles.
7. La synchronisation temporelle est à la fois un primitif de fiabilité et de sécurité. L’audit, la forensique, les durées de validité des jetons et la validation des certificats supposent tous que les horloges ne mentent pas.
8. Certains environnements interdisent le NTP sortant. Les entreprises restreignent souvent UDP/123. Cela force des sources temporelles internes — et rend la hiérarchie non négociable.
9. Les horloges matérielles varient énormément. Les oscillateurs bon marché dévient ; la température affecte la fréquence ; et les ordinateurs portables qui se mettent en veille/réveillent rendent la tenue du temps « créative ».

Playbook de diagnostic rapide (premier/deuxième/troisième)

Si l’heure dérive, ne commencez pas par changer les paramètres. Commencez par déterminer quelle autorité temporelle le système suit réellement et si plusieurs autorités se battent. Voici le chemin le plus rapide vers le goulot d’étranglement.

Premier : confirmer le symptôme et l’étendue

• Est-ce un seul hôte, une seule OU, un seul site, ou « tout le domaine » ?
• La dérive est-elle continue, ou saute-t-elle après une reprise/migration ?
• Quel est l’impact : authentification (Kerberos), TLS, tâches planifiées, ou journaux ?

Deuxième : identifier la source de temps active et la dernière synchronisation

• Sur la machine affectée : que dit w32tm /query /status pour Source et Last Successful Sync Time ?
• Sur les membres de domaine : se synchronisent-ils depuis le domaine (attendu), ou depuis un pair externe (généralement incorrect) ?
• Sur les DC : l’émulateur PDC se synchronise-t-il en externe, et les autres DC se synchronisent-ils depuis lui ?

Troisième : cherchez des fournisseurs de temps concurrents

• Hyper-V : le service d’intégration de synchronisation du temps est-il activé ?
• VMware : les fonctions de synchronisation de VMware Tools sont-elles activées ?
• Veeam/outils de sauvegarde : des restaurations/snapshots provoquent-ils des sauts temporels ?
• GPO/baseline de sécurité : une stratégie a-t-elle modifié les paramètres NTP ou désactivé des fournisseurs ?

Si vous ne retenez qu’une chose : la dérive horaire est généralement un problème de plan de contrôle, pas un problème de physique. Réparez la chaîne d’autorité et les conflits cessent. Ensuite, la physique devient gérable.

La hiérarchie temporelle Windows : qui doit se synchroniser sur quoi

Dans un domaine Windows, arrêtez de penser la « configuration du serveur NTP » comme quelque chose que vous appliquez à chaque machine. Cette approche produit un domaine où chaque nœud croit avoir une horloge différente, et Kerberos commence à rejeter les tickets parce que votre parc ne s’accorde pas sur la minute qu’il est.

Membres du domaine (postes, serveurs membres)

Ils doivent se synchroniser depuis le domaine. Cela signifie typiquement qu’ils utilisent le mode NT5DS, qui dit à Windows de suivre automatiquement la hiérarchie de domaine. Leur « serveur NTP » n’est pas une pool publique ; c’est le DC avec lequel ils parlent.

Contrôleurs de domaine

Les DC non PDC doivent se synchroniser depuis la hiérarchie du domaine (ultimement depuis l’émulateur PDC). Ils ne devraient pas tous être pointés vers Internet. Cela crée des fluctuations de source temporelle et rend la raisonnement sur la correction plus difficile.

Émulateur PDC de la racine de forêt (le grand patron)

C’est lui qui doit avoir des sources en amont explicites et fiables. Si vous configurez des NTP externes, faites-le ici. Si vous êtes dans un environnement régulé, utilisez des appliances stratum-1/2 internes ou des sources GPS. Sinon, choisissez quelques serveurs NTP stables internes et laissez-les joindre l’amont — puis pointez le PDC vers ceux-ci.

Machines autonomes (non jointes au domaine)

Ici, c’est la loi du Far West. Configurer des pairs directement est acceptable — mais vous devez quand même surveiller l’interférence de l’hyperviseur et des intervalles d’interrogation déraisonnables.

Le correctif NTP que l’on oublie : sources temporelles concurrentes

La plupart des incidents de « dérive Windows » que j’ai vus n’ont pas été résolus en ajoutant plus de serveurs NTP. Ils ont été résolus en supprimant la deuxième (et la troisième) source temporelle qui sabordait en silence la discipline de w32time.

Le combat classique : w32time vs synchronisation invité hyperviseur

Les hyperviseurs offrent souvent un mécanisme de synchronisation « utile ». Il peut être très bien pour des VM utilitaires Linux non jointes au domaine et catastrophique pour des serveurs Windows joints au domaine. Pourquoi ? Parce qu’il a tendance à step l’horloge (la faire sauter), surtout après une pause/reprise, une restauration de snapshot, ou une migration à chaud. Pendant ce temps, w32time essaie de slew progressivement basé sur des échantillons NTP. On finit avec :

• Des sauts temporels soudains périodiques (l’outil VM corrige)
• Puis une correction lente de dérive (w32time tente de stabiliser)
• Puis un autre saut (l’outil corrige à nouveau)

De l’extérieur, on dirait « NTP est cassé ». En réalité, il est simplement sapé.

Autre combat : une GPO qui définit des pairs NTP sur les membres de domaine

Quelqu’un écrit une politique bien intentionnée : « Toutes les machines Windows doivent se synchroniser sur time.company.local. » Ils l’appliquent à toutes les OU. Félicitations : vous venez d’outrepasser la hiérarchie de domaine et de créer une dépendance sur un seul serveur (ou pire, sur une IP qui n’est pas accessible depuis chaque site). Les membres de domaine ne devraient pas avoir besoin de pairs explicites. Ils ont besoin d’une chaîne temporelle de domaine fonctionnelle.

Le conflit subtil : « optimisation » en changeant les intervalles d’interrogation

Des gens voient de la dérive et augmentent la fréquence d’interrogation en pensant que plus d’échantillons vaut mieux. Parfois oui. Souvent non : ça augmente la charge, déclenche un rate limiting en amont, et fait que w32time considère la source comme instable. Ou ça maintient l’horloge en oscillation parce que vous corrigez trop fort.

Que faire : choisissez une autorité par couche. Désactivez ou contraignez les autres. Gardez la hiérarchie propre. Si vous avez besoin de synchronisation hyperviseur, utilisez-la de manière intentionnelle (typiquement pour le PDC émulateur vous ne voulez pas de stepping par l’hyperviseur ; pour certaines charges isolées, vous pourriez).

Idée fiabilité paraphrasée : John Allspaw soutient que la fiabilité vient de la compréhension de la manière dont les systèmes échouent en conditions réelles, pas de la foi dans les diagrammes du chemin heureux.

Tâches pratiques avec commandes : vérifier, décider, corriger

Vous ne corrigez pas la dérive par intuition. Vous la corrigez en lisant ce que le système pense faire, puis en changeant une chose à la fois et en validant. Ci‑dessous des tâches pratiques. Chaque tâche inclut (1) une commande, (2) un exemple de sortie, (3) ce que cela signifie, et (4) la décision à prendre.

Task 1: Check the active time source on a Windows machine

cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0312500s
Root Dispersion: 0.1015625s
ReferenceId: 0xC0A8010A (source IP:  192.168.1.10)
Last Successful Sync Time: 2/5/2026 9:42:11 AM
Source: DC01.corp.local
Poll Interval: 10 (1024s)

Sens : La machine se synchronise sur DC01. C’est généralement correct pour un membre de domaine. Poll Interval montre la fréquence d’interrogation.

Décision : Si c’est un membre de domaine et que la source est un DC, bien. S’il pointe vers un serveur NTP externe ou « Local CMOS Clock », vous avez un problème de configuration/autorité.

Task 2: Identify whether the machine is domain-hierarchy mode or manual peers

cr0x@server:~$ w32tm /query /configuration
[TimeProviders]
NtpClient (Local)
DllName: C:\Windows\system32\w32time.dll
Enabled: 1
InputProvider: 1

[Parameters]
NtpServer: time.company.local,0x9
Type: NTP

Sens : Type: NTP signifie que des pairs manuels sont configurés. Sur un membre de domaine, cela remplace souvent la hiérarchie de domaine prévue.

Décision : Pour les membres de domaine : remettez Type à NT5DS (hiérarchie de domaine). Pour l’émulateur PDC : des pairs manuels sont appropriés.

Task 3: Force a resync and see if it succeeds

cr0x@server:~$ w32tm /resync /force
Sending resync command to local computer...
The command completed successfully.

Sens : Le client a contacté sa source et a mis à jour l’heure (ou croit l’avoir fait).

Décision : Si le resync échoue, allez directement vérifier la connectivité, le pare‑feu et les journaux d’événements. S’il réussit mais que la dérive continue, suspectez des sources temporelles concurrentes ou un amont défectueux.

Task 4: Measure offset to a specific peer

cr0x@server:~$ w32tm /stripchart /computer:DC01.corp.local /samples:5 /dataonly
09:45:01, +00.0123456s
09:45:03, +00.0119023s
09:45:05, +00.0121011s
09:45:07, +00.0124420s
09:45:09, +00.0122104s

Sens : Le client a environ 12ms d’avance sur DC01. C’est acceptable pour la plupart des besoins d’entreprise.

Décision : Si vous voyez des offsets en secondes, vous êtes en territoire où Kerberos peut se casser. Si les offsets varient fortement d’un échantillon à l’autre, suspectez la gigue réseau, un amont instable, ou des effets de pause/reprise VM.

Task 5: Confirm the Windows Time service is running

cr0x@server:~$ sc query w32time
SERVICE_NAME: w32time
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Sens : Le service est en cours d’exécution.

Décision : S’il est STOPPED ou instable, corrigez cela d’abord (politique, dépendances, ou corruption). Pas de service, pas de synchronisation.

Task 6: Review time service events (quick filter)

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-Time-Service']]]" /c:5 /rd:true /f:text
Event[0]:
  Provider Name: Microsoft-Windows-Time-Service
  Event ID: 35
  Level: Error
  Description: The time service has not synchronized the system time for 86400 seconds because no time data was available.

Sens : w32time n’obtient pas d’échantillons utilisables. Ça peut être dû à un NTP bloqué, une source incorrecte, des problèmes DNS, ou un amont mort.

Décision : Validez le chemin réseau vers la source, puis la source elle‑même. Ne touchez pas aux intervalles d’interrogation tant que l’amont n’est pas sain.

Task 7: Check the domain controller time role (PDC emulator)

cr0x@server:~$ netdom query fsmo
Schema master               DC01.corp.local
Domain naming master        DC01.corp.local
PDC                         DC02.corp.local
RID pool manager            DC01.corp.local
Infrastructure master       DC01.corp.local
The command completed successfully.

Sens : DC02 est l’émulateur PDC pour le domaine (racine temporelle pour la hiérarchie du domaine en pratique).

Décision : Concentrez votre configuration NTP externe et votre surveillance sur DC02. Si vous avez configuré des pairs sur le mauvais DC, vous pouvez obtenir une autorité temporelle incohérente.

Task 8: Check which DC a client is using (and whether it’s sane)

cr0x@server:~$ nltest /dsgetdc:corp.local
           DC: \\DC03.corp.local
      Address: \\192.168.50.23
     Dom Guid: 9e2b7a9d-1a5b-4c42-9f1a-0d1c7e6c1a11
     Dom Name: corp.local
  Forest Name: corp.local
 Dc Site Name: BRANCH-01
Our Site Name: BRANCH-01
The command completed successfully.

Sens : Le client utilise un DC du site local (bien). S’il sélectionne un DC de site distant, la latence/gigue et le pare‑feu peuvent nuire à la stabilité temporelle.

Décision : Si le DC sélectionné est distant, vérifiez la configuration des Sites/Subnets AD. Les problèmes de temps commencent parfois parce que « votre topologie de site ment ».

Task 9: Verify UDP/123 connectivity to an NTP server (basic test)

cr0x@server:~$ w32tm /stripchart /computer:time.company.local /samples:3 /dataonly
09:47:01, +00.0000000s
09:47:03, +00.0000000s
09:47:05, +00.0000000s

Sens : Vous avez reçu des réponses. S’il bloque ou renvoie une erreur, UDP/123 peut être bloqué ou la résolution de nom est cassée.

Décision : Si c’est bloqué, corrigez les règles de pare‑feu entre la bonne couche de votre hiérarchie, pas depuis chaque point final vers Internet.

Task 10: Configure the PDC emulator to use manual peers (the right place to do it)

cr0x@server:~$ w32tm /config /manualpeerlist:"time1.company.local,0x8 time2.company.local,0x8" /syncfromflags:manual /reliable:yes /update
The command completed successfully.

Sens : Vous avez défini des pairs explicites, dit à Windows de les utiliser, et marqué cet hôte comme fiable pour les autres.

Décision : Faites cela sur l’émulateur PDC (généralement la racine de forêt). Ne le faites pas sur des DC au hasard et surtout pas sur des clients.

Task 11: Configure domain members back to domain hierarchy mode

cr0x@server:~$ w32tm /config /syncfromflags:domhier /update
The command completed successfully.

Sens : Le client suivra la hiérarchie AD.

Décision : Si votre environnement est joint au domaine, c’est le comportement par défaut souhaité sauf exception justifiée.

Task 12: Restart time service and force rediscovery (when config changes)

cr0x@server:~$ net stop w32time
The Windows Time service was stopped successfully.
cr0x@server:~$ net start w32time
The Windows Time service was started successfully.
cr0x@server:~$ w32tm /resync /rediscover
Sending resync command to local computer...
The command completed successfully.

Sens : Vous avez appliqué des changements de configuration et forcé la redécouverte des sources.

Décision : Utilisez ceci après avoir changé Type, les pairs, ou les paramètres GPO. S’il ne veut toujours pas se synchroniser, vous avez des problèmes en amont ou de connectivité.

Task 13: Confirm what the time service thinks its peers are

cr0x@server:~$ w32tm /query /peers
#Peers: 2

Peer: time1.company.local,0x8
State: Active
Time Remaining: 734s
Mode: 3 (Client)
Stratum: 2

Peer: time2.company.local,0x8
State: Active
Time Remaining: 734s
Mode: 3 (Client)
Stratum: 2

Sens : Le PDC voit deux pairs et ils sont actifs. Bien.

Décision : Si les pairs sont « Pending » ou « Unknown », résolvez la DNS, le pare‑feu, ou la santé du service NTP en amont.

Task 14: Check for virtualization time sync features that can step the clock (Hyper-V example)

cr0x@server:~$ powershell -NoProfile -Command "Get-VMIntegrationService -VMName 'APP01' | Where-Object {$_.Name -eq 'Time Synchronization'} | Format-List Name,Enabled"
Name    : Time Synchronization
Enabled : True

Sens : La synchronisation de l’heure Hyper-V est activée pour la VM APP01. Ça peut être acceptable, ou bien la raison cachée pour laquelle votre horloge saute.

Décision : Pour les serveurs Windows joints au domaine, envisagez de désactiver ce service d’intégration et laissez w32time faire son travail — surtout sur les DC. Faites‑le de façon intentionnelle, avec contrôle de changement, et vérifiez le comportement après les opérations de maintenance de l’hôte.

Task 15: Detect large time jumps via event logs (symptom hunting)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=1 or EventID=37) and Provider[@Name='Microsoft-Windows-Time-Service']]]" /c:10 /rd:true /f:text
Event[0]:
  Provider Name: Microsoft-Windows-Time-Service
  Event ID: 37
  Level: Warning
  Description: The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible.

Sens : Cela se corrèle souvent avec le début de la dérive : le client ne peut pas atteindre ses sources et commence à fonctionner en mode libre.

Décision : Si vous voyez ceci au moment où les incidents commencent, réparez la connectivité d’abord. Si ça coïncide avec des fenêtres de maintenance d’hôte, suspectez des changements de pare‑feu ou des ACL de routage.

Trois mini-récits d’entreprise tirés du terrain

1) L’incident causé par une fausse hypothèse : « NTP c’est comme le DNS ; pointez tout le monde vers la même machine. »

Une grande entreprise a déployé une GPO de « durcissement temporel ». L’intention était louable : rendre l’heure cohérente, faciliter les audits, réduire la dérive. L’hypothèse était aussi commune : « Si chaque point final pointe vers un hôte NTP central, nous aurons une source de vérité. »

Ils l’ont appliquée largement : clients, serveurs membres, même certains contrôleurs de domaine. Du jour au lendemain, le support a commencé à voir des échecs d’authentification. Pas tous en même temps. C’était pire dans les agences, et c’est venu par vagues. Les utilisateurs VPN ont été les plus touchés, car leur chemin réseau vers l’hôte NTP choisi était… compliqué.

Les échecs Kerberos ressemblaient à des problèmes de mot de passe. Les équipes applicatives cherchaient des certificats expirés. L’équipe de journalisation jurait que la pipeline SIEM avait « perdu des événements » parce que les horodatages étaient incohérents. Tout le monde accusait tout le monde, ce qui est souvent le signe d’un véritable incident.

Le vrai mode de panne : les membres de domaine ne suivaient plus la hiérarchie de domaine. Certains pouvaient atteindre le serveur NTP central, d’autres non. Quand ils ne pouvaient pas, ils fonctionnaient en libre. Pendant ce temps, ils s’authentifiaient contre des DC avec un temps issu d’un autre chemin. Split‑brain temporel, à l’échelle.

La correction a été ennuyeuse : remettre les clients et serveurs membres en NT5DS, configurer des pairs externes uniquement sur l’émulateur PDC, et s’assurer que les DC des sites avaient une connectivité propre vers l’amont dans le domaine. L’incident s’est terminé non pas par une commande héroïque, mais par un retour en arrière discret et une leçon : la hiérarchie de domaine n’est pas une architecture optionnelle ; c’est une partie du modèle de sécurité.

2) L’optimisation qui a mal tourné : « Interroger toutes les 64 secondes, pour que la dérive n’ait pas lieu. »

Une équipe soucieuse de performance a remarqué quelques serveurs Windows qui dérivaient de quelques centaines de millisecondes sur de longues périodes. Ils n’aimaient pas ça. Quelqu’un a trouvé des réglages de registre liés à l’intervalle d’interrogation, les a interprétés comme « plus rapide = mieux », et a poussé une interrogation agressive sur une flotte de serveurs applicatifs via la gestion de configuration.

Au début, les tableaux de bord semblaient excellents : mises à jour plus fréquentes, offsets à court terme réduits. Puis les serveurs temps amont ont commencé à agir « peu fiables ». Les clients ont commencé à journaliser des avertissements sur des sources inaccessibles ou ne fournissant pas d’heure exploitable. Certains équipements en amont ont commencé à limiter le débit des réponses NTP. Les pare‑feux internes ont signalé le motif de trafic comme suspect parce qu’il ressemblait à du bruit UDP à bas niveau.

Maintenant l’environnement avait un nouveau problème : lors d’une petite turbulence réseau, les clients décidaient rapidement que les sources étaient mauvaises et repartaient en libre, ou changeaient de source trop souvent. Au lieu d’une dérive lente et stable, ils avaient de l’oscillation. Certains serveurs ont fini par stepper l’heure plus agressivement quand ils ont finalement resynchronisé, ce qui est précisément ce que vous ne voulez pas dans des systèmes transactionnels.

La correction n’a pas été « augmenter encore l’interrogation ». Ce fut de revenir à des valeurs par défaut raisonnables, ajouter des sources temporelles internes plus fiables, et surveiller l’offset plutôt que d’essayer de l’éliminer complètement. La leçon : si vous poursuivez la précision sans comprendre les boucles de rétroaction, vous pouvez construire une horloge techniquement « plus active » et opérationnellement pire.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : « Traitez l’émulateur PDC comme une infrastructure critique. »

Une autre organisation avait une habitude qui ne recevait jamais d’applaudissements : ils surveillaient leur chaîne temporelle de domaine de la même manière que le DNS. L’émulateur PDC avait des pairs explicites, des sources en amont redondantes, et des alertes sur « temps depuis la dernière sync réussie » et des seuils d’offset. Ils avaient aussi une règle : les DC ne reçoivent pas le stepping temporel de l’hyperviseur. Jamais.

Pendant une fenêtre de maintenance du datacenter, ils ont déplacé un cluster de VM entre des hôtes. Quelques serveurs applicatifs ont vu des avertissements de saut d’heure. L’équipe opérations l’a remarqué immédiatement car les événements du service temps étaient déjà sur leur radar. Le risque majeur était les DC ; si le temps des DC partait en vrille, tout partait.

Ils ont vérifié l’émulateur PDC en premier. Il était stable et synchronisé. Ils ont vérifié quelques DC non PDC ; eux aussi étaient stables. Cela signifiait que l’épine dorsale temporelle du domaine était intacte. Ensuite ils ont vérifié une poignée de VM applicatives affectées et ont trouvé que la synchronisation hyperviseur avait été réactivée par une mise à jour de template.

La remédiation a été chirurgicale : désactiver la synchronisation temporelle d’intégration sur les serveurs Windows joints au domaine, resynchroniser, et passer à autre chose. Pas de reconfiguration massive, pas de GPO panique, pas de moment « tout le monde pointe vers pool.ntp.org ». La maintenance s’est terminée avec une note de ticket propre, et l’incident qui n’a jamais eu lieu est resté ainsi.

Blague #2 : Rien ne rend un comité de changement plus spirituel que de découvrir que « le temps lui‑même » est hors conformité.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: Kerberos errors, intermittent logon failures, “KRB_AP_ERR_SKEW”

Cause racine : L’heure du client diffère de celle du DC au‑delà de la tolérance, souvent parce que les clients utilisent des pairs NTP manuels tandis que les DC suivent la hiérarchie de domaine.

Correctif : Sur les clients/serveurs membres, définir /syncfromflags:domhier et supprimer les pairs manuels ; vérifier la chaîne temporelle DC et l’amont du PDC.

2) Symptom: Time is fine after reboot, drifts over hours/days

Cause racine : w32time ne se synchronise pas (UDP/123 vers la source choisie bloqué, ou source inaccessible), donc l’horloge tourne librement jusqu’à ce que la dérive soit visible.

Correctif : Utiliser w32tm /query /status et les journaux du Time-Service pour confirmer la dernière synchronisation ; réparer la connectivité et DNS ; puis resynchroniser.

3) Symptom: Sudden time jumps, especially after VM migration or snapshot revert

Cause racine : L’hyperviseur/outils invités synchronisent le temps en step, pendant que w32time tourne aussi.

Correctif : Désactiver la synchronisation temporelle invitée pour les serveurs Windows joints au domaine (surtout les DC), ou la configurer pour éviter le stepping ; ensuite valider avec des stripcharts et les journaux d’événements.

4) Symptom: Only one site/branch has drift problems

Cause racine : La topologie de site ou des règles de pare‑feu forcent les clients à synchroniser depuis des DC distants ; ou le DC local ne peut pas joindre le PDC/amont.

Correctif : Confirmer la sélection du DC avec nltest ; réparer AD Sites/Subnets ; assurer que les DC de site peuvent se synchroniser en amont ; éviter le NTP Internet direct depuis les agences.

5) Symptom: “The time provider NtpClient is configured… none of the sources are accessible”

Cause racine : Des pairs manuels définis mais inaccessibles ; parfois causé par un hôte NTP mis hors service ou une DNS obsolète.

Correctif : Supprimer les pairs morts ; utiliser au moins deux sources fiables sur le PDC ; valider la résolution de noms et le routage UDP/123.

6) Symptom: Time offset oscillates wildly (overcorrecting)

Cause racine : Interrogation/tuning trop agressifs ou amont instable ; parfois les deux.

Correctif : Revenir à une interrogation raisonnable ; stabiliser l’amont ; mesurer l’offset et la gigue plutôt que d’essayer de « verrouiller » l’heure parfaitement.

7) Symptom: Domain controllers disagree on time

Cause racine : Plus d’un DC configuré comme « source de temps fiable » ou plusieurs DC pointés manuellement vers des pairs externes différents.

Correctif : Faire de l’émulateur PDC la source fiable ; configurer des pairs externes uniquement là ; faire suivre aux autres DC la hiérarchie de domaine.

8) Symptom: Standalone server won’t stay in sync even with manual peers

Cause racine : Instabilité de l’horloge matérielle, bizarreries d’économie d’énergie, ou comportement pause/suspension de la VM ; NTP ne peut pas discipliner une horloge qui se fait stepper constamment par ailleurs.

Correctif : Désactiver les synchronisations temporelles concurrentes, éviter les restaurations de snapshot sans stratégie de correction temporelle, et surveiller les sauts ; envisager une configuration côté hôte si c’est une VM.

Listes de contrôle / plan pas à pas

Checklist A: Fix drift on a single domain member without breaking the domain

1. Exécuter w32tm /query /status et noter Source, Last Successful Sync Time, et Poll Interval.
2. Exécuter w32tm /query /configuration et confirmer si Type est NT5DS (préféré pour les membres de domaine).
3. Si Type: NTP sur un membre de domaine, le remettre :

   cr0x@server:~$ w32tm /config /syncfromflags:domhier /update
   The command completed successfully.
   

4. Redémarrer le service temps et redécouvrir :

   cr0x@server:~$ net stop w32time
   The Windows Time service was stopped successfully.
   cr0x@server:~$ net start w32time
   The Windows Time service was started successfully.
   cr0x@server:~$ w32tm /resync /rediscover
   Sending resync command to local computer...
   The command completed successfully.
   

5. Valider l’offset par rapport au DC choisi avec stripchart. Si l’offset est en secondes, escalader aux vérifications de la chaîne DC.
6. Vérifier si la synchronisation temporelle de virtualisation est activée. Si cette machine est jointe au domaine et voit des sauts après des opérations hôtes, désactiver la synchronisation hyperviseur (selon votre standard plateforme).
7. Surveiller les événements du Time-Service pendant l’heure suivante. Vous cherchez des avertissements « source inaccessible » et des corrections répétées.

Checklist B: Fix the domain time backbone (the correct enterprise approach)

1. Identifier l’émulateur PDC :

   cr0x@server:~$ netdom query fsmo
   Schema master               DC01.corp.local
   Domain naming master        DC01.corp.local
   PDC                         DC02.corp.local
   RID pool manager            DC01.corp.local
   Infrastructure master       DC01.corp.local
   The command completed successfully.
   

2. Sur l’émulateur PDC, vérifier la source actuelle et les pairs avec w32tm /query /status et /query /peers.
3. Configurer au moins deux pairs manuels sur le PDC et le marquer fiable :

   cr0x@server:~$ w32tm /config /manualpeerlist:"time1.company.local,0x8 time2.company.local,0x8" /syncfromflags:manual /reliable:yes /update
   The command completed successfully.
   

4. Redémarrer w32time et resynchroniser/redécouvrir sur le PDC.
5. Sur les autres DC, s’assurer qu’ils ne sont pas marqués fiables et qu’ils utilisent la hiérarchie de domaine.
6. Sur les clients/serveurs membres, supprimer toute GPO qui force des pairs manuels (sauf si la machine est intentionnellement autonome).
7. Vérifier dans chaque site que les clients sélectionnent des DC locaux (nltest) et que ces DC peuvent se synchroniser en amont.
8. Surveiller : alerter sur « temps depuis la dernière sync réussie », plus des seuils d’offset significatifs sur le PDC et quelques DC représentatifs par site.

Checklist C: Virtualization sanity rules (to stop time stepping)

1. Pour les contrôleurs de domaine : désactiver le stepping temporel invité de l’hyperviseur. Les DC doivent être disciplinés par la chaîne temporelle du domaine, pas par un hôte pouvant être décalé de secondes lors de maintenance.
2. Pour les serveurs membres du domaine : envisager fortement de désactiver la synchronisation hyperviseur sauf raison documentée de la conserver.
3. Pour les appliances autonomes et VM isolées : la synchronisation hyperviseur peut être acceptable, mais choisissez une méthode et tenez‑y‑vous.
4. Après toute modification de template, vérifier que le paramètre ne s’est pas rétabli (c’est une source fréquente de régression).

FAQ

1) Why does Windows time drift even when NTP is configured?

Parce que « configuré » n’est pas « effectif ». La machine peut ne pas atteindre sa source, utiliser la mauvaise source, ou un hyperviseur/outil peut stepper l’horloge à l’insu de w32time.

2) Should every Windows machine point to the same NTP server?

Non, pas dans un domaine. Les membres de domaine doivent suivre la hiérarchie de domaine. Configurer des pairs externes sur l’émulateur PDC (et seulement là, par défaut).

3) What’s the one thing people forget that causes the most pain?

Les sources temporelles concurrentes. Une fonctionnalité de synchronisation invité qui steppe l’heure plus w32time qui essaie de la discipliner est une recette pour le chaos dérive‑et‑saut.

4) Can I just disable w32time and rely on the hypervisor?

Pour les systèmes Windows joints au domaine, c’est généralement une mauvaise idée. Vous voulez que le service OS soit aligné avec le modèle de sécurité du domaine. La synchronisation hyperviseur peut être un supplément dans certains cas, mais ne remplacez pas le service temps sans précaution.

5) How do I know if the PDC emulator is the problem?

Si beaucoup de machines à travers les sites dérivent dans la même direction, ou si les DC ne sont pas d’accord, vérifiez le w32tm /query /status et les journaux d’événements du PDC. Si le PDC ne se synchronise pas de manière fiable, tout le domaine hérite de cette incertitude.

6) What offset is “too much”?

Pour l’activité d’entreprise générale, des dizaines de millisecondes sont acceptables. Une fois que vous atteignez des secondes, vous risquez des problèmes d’authentification et de validation de certificats. Pour le trading/télémétrie/contrôle industriel, les exigences peuvent être bien plus strictes.

7) Why do time issues show up as certificate errors?

Les certificats TLS ont des fenêtres de validité. Si votre horloge est fausse, un certificat parfaitement valide peut apparaître expiré ou pas encore valide. Ensuite on blâme la PKI, tandis que l’horloge rigole en silence.

8) Do I need “internet NTP” access from every server?

Généralement non. Il est plus propre d’avoir un petit nombre de sources temporelles internes qui ont un accès monté contrôlé, puis de distribuer l’heure via la hiérarchie de domaine.

9) If I run w32tm /resync and it succeeds, am I done?

Pas nécessairement. Une synchronisation ponctuelle ne prouve pas la stabilité. Vérifiez Last Successful Sync Time sur plusieurs heures, cherchez des événements « source inaccessible », et surveillez les sauts après des événements de cycle de vie VM.

10) What about leap seconds—do they still matter?

Oui, car différentes plateformes et sources en amont peuvent les traiter différemment. Votre objectif est la cohérence dans l’environnement. Si vous lissez (smear), faites‑le de façon cohérente ; si vous sautez (step), faites‑le de façon cohérente. Un comportement mixte crée des bizarreries.

Prochaines étapes à faire cette semaine

• Auditer votre hiérarchie. Identifiez l’émulateur PDC et confirmez qu’il a des pairs amont stables et redondants. Tout le monde ailleurs devrait majoritairement suivre la hiérarchie de domaine.
• Chasser les synchronisations temporelles concurrentes. Sur votre plateforme de virtualisation, vérifiez que les paramètres de stepping invité n’ont pas été activés par des templates ou des « paramètres par défaut utiles ». Portez une attention particulière aux contrôleurs de domaine.
• Supprimer les paramètres GPO globaux pour les pairs sur les membres de domaine. Si vous devez utiliser une GPO, ciblez‑la précisément : paramètres PDC pour le PDC, pas une liste de pairs « taille unique ».
• Instrumenter les signaux ennuyeux. Alarmez sur « temps depuis la dernière sync réussie » et sur des seuils d’offset significatifs pour le PDC et quelques DC représentatifs par site.
• Pratiquer le drill de resynchronisation. Assurez‑vous que votre équipe d’astreinte sait exécuter les commandes clés, les interpréter, et quand escalader aux équipes réseau ou virtualisation.

Si vous faites ces cinq choses, la plupart des tickets « dérive horaire Windows » disparaîtront. Pas parce que le temps devient simple, mais parce que vous aurez cessé de laisser trois systèmes différents se disputer sur l’heure qu’il est.