NTP entre bureaux : la petite chose qui casse AD, VPN et les certificats

Pourquoi le temps casse tout (AD, VPN, TLS)

NTP n’est pas de la « hygiène d’infrastructure ». C’est une dépendance de confiance. Au moment où deux systèmes ne sont pas d’accord sur l’heure, ils ne sont plus d’accord sur le fait qu’un événement a eu lieu.
Les systèmes d’authentification ne négocient pas avec l’incertitude ; ils la rejettent.

Active Directory et Kerberos : le décalage d’horloge est une fonction de sécurité

Les tickets Kerberos ont des horodatages. Pas comme un détail mignon — les horodatages font partie du modèle de protection contre la relecture.
Si l’heure du client est trop éloignée de celle du contrôleur de domaine, les tickets sont considérés comme dangereux et sont rejetés.
Sous Windows, vous verrez des variations de « KRB_AP_ERR_SKEW » ou « The time difference between the client and server is too great. »

Par défaut, AD tolère un décalage limité (généralement cinq minutes). Cinq minutes paraissent généreuses jusqu’à ce que vous réalisiez combien il est facile pour un hôte VM,
un portable en veille et un pare-feu de succursale faisant un NAT « utile » d’empiler de petits décalages en un gros.

VPN et SSO : le jeton qui « a expiré » avant d’avoir été émis

Les piles VPN modernes sont liées aux fournisseurs d’identité : assertions SAML, tokens OIDC, cookies signés, vérifications d’état de l’appareil à courte durée de vie.
Ceux-ci dépendent du temps. Un jeton valide 60 secondes est un bon contrôle de sécurité jusqu’à ce que votre succursale soit à +90 secondes dans le futur.

Le mode d’échec est prévisible : les utilisateurs s’authentifient quelque part, puis la passerelle VPN rejette l’assertion suivante comme « pas encore valide »
ou « expirée ». Tout le monde blâme l’IdP. L’IdP est innocent. Vos horloges ne le sont pas.

Certificats TLS : « pas encore valide » est une dérive temporelle, pas un drame PKI

TLS a une règle brutalement simple : les certificats ont des fenêtres de validité. Si l’heure d’un nœud est incorrecte, le certificat peut être rejeté même s’il a été émis correctement.
« x509: certificate has expired or is not yet valid » est l’équivalent TLS de « ta montre te ment ».

Les systèmes distribués sont sensibles au temps même quand ils prétendent ne pas l’être

On peut construire des systèmes distribués sans horloges strictement synchronisées, mais il faut quand même la monotonie et un accord raisonnable sur l’heure murale pour :
corrélation des logs, réponse aux incidents, facturation, validation de tokens, tâches planifiées et pistes d’audit.
La question n’est pas « avons-nous besoin de NTP ? » mais « quelle quantité de défaillance sommes-nous prêts à accepter quand NTP se dégrade ? »

Blague n°1 : La synchronisation temporelle, c’est comme le fil dentaire — tout le monde reconnaît que c’est nécessaire, et la plupart s’en occupent seulement après que quelque chose commence à saigner.

Comment NTP fonctionne réellement sur un WAN

NTP est simple comme TCP est « simple » : un petit protocole avec beaucoup de cas limites opérationnels.
Sur plusieurs bureaux, vous tomberez sur le trio désagréable : latence asymétrique, perte de paquets et appareils qui se croient plus malins que l’heure.

Offset, délai, jitter : trois nombres qui décident de votre journée

Quand un client NTP interroge un serveur, il tente d’estimer la différence entre son horloge et celle du serveur (offset).
Il mesure aussi le délai aller-retour réseau (delay). Au fil du temps il observe la variance (jitter).
Si le délai est élevé mais stable, NTP peut encore fonctionner. Si le jitter est élevé, votre estimation d’offset devient bruyante et le client peut refuser de faire un pas.

Stepping vs slewing : la différence entre « correct » et « sûr »

Une horloge peut être corrigée en faisant un step (saut instantané) ou un slew (ajustement progressif de la fréquence).
Le stepping est rapide et souvent nécessaire quand une machine démarre avec une heure erronée. Il est aussi dangereux en production :
un pas en arrière peut casser des bases de données, confondre des logs et faire exécuter deux fois des tâches planifiées.

Une configuration raisonnable permet le stepping au démarrage (ou quand l’offset est énorme) et le slewing en fonctionnement normal.
Chrony gère généralement cela mieux que l’ancien ntpd dans des réseaux désordonnés. Sur Windows, w32time a ses propres règles et limites ;
traitez-le comme un citoyen spécial, pas comme un clone Linux.

Le stratum n’est pas « qualité », c’est « distance »

Le stratum indique à quelle distance un serveur se trouve d’une horloge de référence. Stratum 1 est connecté directement à une source de référence (GPS, horloge atomique, radio).
Stratum 2 se synchronise sur un stratum 1, etc. Un stratum plus bas n’est pas automatiquement « meilleur » si le chemin est non fiable.
Un serveur stratum 3 avec une connectivité stable peut battre un stratum 1 à travers un WAN fragile.

Réalité WAN : asymétrie et filtrage

NTP suppose que le délai réseau est à peu près symétrique. Sur des liens inter-bureaux, il ne l’est souvent pas.
L’SD-WAN peut réordonner les paquets. Les liens de secours LTE peuvent provoquer des pics de latence. Les pare-feu stateful peuvent considérer UDP/123 comme une suggestion.
Une seule règle de « durcissement de sécurité » qui bloque UDP/123 sortant depuis les VLANs de succursale peut créer une île de dérive.

« Utiliser simplement les pools publics » n’est pas une conception d’entreprise

Les pools NTP publics sont excellents pour l’Internet public. Les entreprises sont différentes : vous avez besoin d’un comportement prévisible, de règles de pare-feu strictes,
de dépendances déterministes, de contrôle de changement auditables et de supervision.
Utilisez des sources externes avec précaution en périphérie, puis distribuez l’heure en interne avec vos propres serveurs.

Faits et historique intéressants (parce que ça explique les pièges)

• NTP est ancien—par conception : le protocole date du début des années 1980 et a évolué pour survivre aux réseaux peu fiables.
• Les secondes intercalaires sont politiques : les secondes intercalaires existent parce que la rotation de la Terre n’est pas constante, et les organismes de normalisation débattent encore pour savoir s’il faut les supprimer.
• Kerberos a hérité de sa tolérance de skew : la fenêtre de décalage de « quelques minutes » vient d’un équilibre entre sécurité (prévention de la relecture) et imperfection des horloges réelles.
• Le stratum n’est pas un insigne : c’est un nombre de sauts depuis une horloge de référence ; l’Internet est plein de serveurs bas-stratum qui sont erronés.
• Les premiers domaines Windows étaient sensibles au temps avant que le « Zero Trust » soit à la mode : l’authentification de domaine dépend de l’heure depuis longtemps, elle est juste plus visible maintenant.
• La virtualisation a rendu l’heure plus difficile : les horloges invitées peuvent dériver si l’hôte est surchargé ou si la synchronisation est mal configurée à la fois dans l’invité et l’hyperviseur.
• NTP peut être instrumentalisé : des serveurs mal configurés ont été utilisés pour des attaques par réflexion/amplification, ce qui explique pourquoi les équipes sécurité bloquent parfois NTP.
• Monotone et horloge murale sont des outils différents : l’OS garde les deux ; vos logs d’app utilisent l’heure murale tandis que les planificateurs et timeouts préfèrent le monotone.

Architecture qui survit aux bureaux, liens et auditeurs

Ce que vous voulez : une petite hiérarchie temporelle interne

L’objectif est ennuyeux : chaque système dans chaque bureau s’accorde sur l’heure dans une marge étroite, même si le WAN est instable.
On y arrive avec une hiérarchie :

• Références externes : quelques sources en amont bien choisies (pool public, NTP de l’ISP, GPS au siège) alimentant un petit ensemble de serveurs internes.
• Serveurs temporels internes : au moins deux par région ou site majeur, joignables par tous les clients.
• Succursales : les clients se synchronisent depuis des serveurs internes, pas depuis Internet. Les grandes succursales peuvent exécuter un relais NTP local pour la résilience.
• Contrôleurs de domaine : suivez correctement la hiérarchie temporelle AD au lieu de faire du freelance.

Règle spécifique AD : le PDC Emulator est le « boss du temps »

Dans un domaine AD, le temps circule selon une hiérarchie spécifique. Typiquement :
le titulaire du rôle PDC Emulator doit être configuré pour se synchroniser avec des sources externes fiables (ou une source interne avec GPS),
et les autres DC se synchronisent depuis la hiérarchie de domaine. Les membres du domaine se synchronisent depuis les DC.

Si vous laissez plusieurs DC tirer l’heure depuis des sources aléatoires, vous avez créé des autorités concurrentes. Vous aurez des décalages intermittents et vous détesterez votre vie.

Pattern pour succursale : cache NTP local quand le WAN est peu fiable

Pour les petites succursales avec un WAN stable, pointer les clients vers deux serveurs régionaux internes suffit.
Pour les succursales à connectivité intermittente, ajoutez un serveur temporel local (ou utilisez le DC de la succursale s’il est fiable et géré correctement) qui :

• se synchronise sur le siège/les upstreams régionaux quand le lien est actif,
• sert les clients locaux en continu,
• a des limites raisonnables pour ne pas dériver indépendamment dans l’absurde.

Posture de sécurité : NTS est bien ; NTP contrôlé est nécessaire

Si votre environnement le permet, NTS (Network Time Security) apporte une protection cryptographique pour NTP.
Beaucoup d’environnements d’entreprise n’y sont pas encore, surtout avec un mix Windows, équipements réseau et appliances.
Faites donc la deuxième meilleure chose :

• limiter qui peut interroger et qui peut servir l’heure,
• utiliser des serveurs internes,
• surveiller les offsets et la sélection des sources,
• traiter NTP comme une dépendance d’authentification.

Virtualisation et cloud : choisir une seule référence temporelle par couche

Le classique piège est la double synchronisation : les outils de l’hyperviseur essayant de fixer l’heure de l’invité pendant que chrony/ntpd l’ajuste aussi.
Choisissez-en un. Habituellement : désactivez « set time » dans les outils hyperviseur, gardez le client NTP de l’invité activé, et assurez-vous que l’hôte lui-même est synchronisé.
L’exception est quand le fournisseur documente explicitement le contraire pour une plateforme spécifique ; alors suivez la plateforme, pas vos instincts.

Citation (idée paraphrasée), attribuée à John Allspaw : « La fiabilité vient de la conception de systèmes qui supposent l’échec, puis de la pratique de la réponse. »

Mode opératoire de diagnostic rapide

Quand « AD est cassé » et « le VPN est en panne » apparaissent la même heure, vérifiez l’heure avant de vérifier autre chose.
Pas parce que le temps est toujours la cause, mais parce que c’est rapide à infirmer et catastrophique quand c’est vrai.

Première étape : confirmer la réalité temporelle sur un client en échec et une autorité

• Sur le client : vérifier l’heure courante, le fuseau horaire et l’état de synchronisation NTP.
• Sur un contrôleur de domaine (ou une passerelle VPN) : vérifier ses sources NTP et son offset.
• Comparer l’heure murale avec une référence connue et bonne (votre serveur NTP interne, pas votre téléphone).

Deuxième étape : vérifier l’atteignabilité NTP et quel serveur le client croit utiliser

• UDP/123 est-il autorisé dans les deux sens ?
• Le client est-il configuré pour des serveurs temporels internes, ou est-il revenu sur quelque chose d’étrange ?
• Une politique SD-WAN réécrit-elle ou limite-t-elle le débit de UDP/123 ?

Troisième étape : déterminer si le problème est une dérive, un pas ou une sélection de source

• Gros offset (minutes/heures) : machine démarrée avec une mauvaise heure, problème d’horloge CMOS, réinitialisation VM, ou NTP bloqué pendant un moment.
• Petit offset mais croissant : le service temporel ne discipline pas l’horloge (bloqué), ou l’oscillateur est défectueux.
• Offset qui oscille : plusieurs sources temporelles en conflit, ou jitter/asymétrie réseau qui perturbent la sélection.

Quatrième étape : décider du rayon d’impact

• Si une seule succursale est décalée : traitez cela comme un problème de WAN/pare-feu/local NTP de la succursale.
• Si tous les bureaux sont décalés : suspectez le haut de votre hiérarchie temporelle (configuration du PDC emulator, serveurs NTP internes, atteignabilité des upstreams).
• Si seuls les utilisateurs VPN échouent : vérifiez l’heure de la passerelle VPN et les fenêtres de validité des assertions IdP.

Tâches pratiques : commandes, sorties, décisions

Ce sont les vérifications qui paient le loyer. Chaque tâche inclut une commande, à quoi ressemble le « bon » et le « mauvais », et la décision suivante.
Les commandes sont montrées avec des sorties d’exemple ; adaptez les noms d’hôte à votre environnement.

Task 1: Check the current clock and time zone (Linux)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 09:14:22 UTC
           Universal time: Sun 2025-12-28 09:14:22 UTC
                 RTC time: Sun 2025-12-28 09:14:21
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que cela signifie : « System clock synchronized: yes » est un bon signe ; « NTP service: active » indique que votre client fonctionne.
Si le fuseau horaire est incorrect, les logs et la validation de certificats peuvent encore sembler incorrects même si NTP est correct.
Décision : Si synchronized est « no », passez immédiatement à la vérification du démon NTP et de l’atteignabilité.

Task 2: Check chrony tracking (Linux)

cr0x@server:~$ chronyc tracking
Reference ID    : 10.20.1.10 (ntp-hq-1)
Stratum         : 3
Ref time (UTC)  : Sun Dec 28 09:14:18 2025
System time     : 0.000183421 seconds fast of NTP time
Last offset     : +0.000091233 seconds
RMS offset      : 0.000512344 seconds
Frequency       : 12.345 ppm fast
Residual freq   : -0.210 ppm
Skew            : 0.900 ppm
Root delay      : 0.012345 seconds
Root dispersion : 0.001234 seconds
Update interval : 64.0 seconds
Leap status     : Normal

Ce que cela signifie : des offsets inférieurs à la milliseconde sont excellents ; des dizaines de millisecondes sont habituellement acceptables ; des centaines de millisecondes peuvent être tolérables ;
des secondes posent problème pour l’auth. Décision : Si « Leap status » n’est pas normal ou si le stratum saute, inspectez les sources ensuite.

Task 3: Inspect NTP sources and selection (chrony)

cr0x@server:~$ chronyc sources -v
210 Number of sources = 2

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined.
| /   Reachability register (octal) - valid samples are marked '377'.
||    ----
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp-hq-1                      2   6   377    35   +0.182ms[ +0.210ms] +/-  1.2ms
^+ ntp-hq-2                      2   6   377    34   -0.311ms[ -0.290ms] +/-  1.6ms

Ce que cela signifie : reach « 377 » signifie des sondages récents réussis ; « ^* » est la source actuelle.
Si reach est « 0 » ou faible, les paquets ne reviennent pas. Décision : Un reach faible vous pousse immédiatement à vérifier pare-feu/WAN.

Task 4: Verify NTP UDP/123 connectivity (Linux)

cr0x@server:~$ nc -vu -w 2 ntp-hq-1 123
Connection to ntp-hq-1 123 port [udp/ntp] succeeded!

Ce que cela signifie : cela prouve seulement que le port n’est pas immédiatement bloqué ; cela ne prouve pas que les réponses NTP sont correctes.
Décision : Si cela échoue depuis un sous-réseau de succursale mais fonctionne depuis le siège, vous avez un problème de politique réseau, pas de démon temporel.

Task 5: Check if something else is using UDP/123 or blocking it (Linux)

cr0x@server:~$ sudo ss -ulpn | grep ':123'
UNCONN 0      0            0.0.0.0:123        0.0.0.0:*    users:(("chronyd",pid=812,fd=6))
UNCONN 0      0               [::]:123           [::]:*    users:(("chronyd",pid=812,fd=7))

Ce que cela signifie : chronyd est lié à UDP/123 et peut servir l’heure.
Si vous voyez plusieurs démons en concurrence (chronyd et ntpd), c’est un signe de mauvaise configuration.
Décision : Si le démon attendu n’écoute pas, corrigez le service avant de chasser des fantômes WAN.

Task 6: Confirm time sync status and peers (systemd-timesyncd)

cr0x@server:~$ timedatectl timesync-status
       Server: 10.20.1.10 (ntp-hq-1)
Poll interval: 1min 4s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 3
    Reference: 8A0E5F9C
    Precision: 1us (-24)
Root distance: 1.123ms
       Offset: +212us
        Delay: 502us
       Jitter: 147us
 Packet count: 178
    Frequency: +12.3ppm

Ce que cela signifie : bien pour des clients simples ; si votre environnement est désordonné (jitter WAN, succursales),
chrony est généralement le meilleur choix. Décision : Si l’offset est grand et n’améliore pas, vous avez besoin de meilleures sources ou de moins de jitter.

Task 7: Check Windows time status on a domain member (run in PowerShell)

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.1093750s
ReferenceId: 0x0A14010A (source IP: 10.20.1.10)
Last Successful Sync Time: 12/28/2025 9:12:41 AM
Source: ntp-hq-1
Poll Interval: 6 (64s)

Ce que cela signifie : « Source » doit être une source temporelle de domaine (typiquement un DC) ou votre hôte NTP interne approuvé.
Si c’est « Local CMOS Clock » ou un serveur public, vous courez un risque de dérive. Décision : Corrigez la hiérarchie temporelle avant de toucher aux paramètres Kerberos.

Task 8: Check which Windows server is the time source (domain member)

cr0x@server:~$ w32tm /query /source
ntp-hq-1

Ce que cela signifie : confirmation rapide de ce que la machine pense. Décision : Si cela pointe vers un serveur injoignable,
corrigez le routage/le pare-feu ou mettez à jour la GPO/configuration temporelle.

Task 9: Verify AD time hierarchy settings on the PDC Emulator

cr0x@server:~$ w32tm /query /configuration
[Configuration]
EventLogFlags: 2 (Local)
AnnounceFlags: 5 (Local)
TimeJumpAuditOffset: 28800 (Local)
MinPollInterval: 6 (Local)
MaxPollInterval: 10 (Local)
MaxNegPhaseCorrection: 172800 (Local)
MaxPosPhaseCorrection: 172800 (Local)

[TimeProviders]
NtpClient (Local)
DllName: C:\Windows\system32\w32time.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)

NtpServer (Local)
Enabled: 1 (Local)

Ce que cela signifie : vous vérifiez si la machine est configurée pour agir comme serveur NTP et si le client est activé.
Décision : Si le PDC n’est pas configuré pour se synchroniser à une source fiable, corrigez cela d’abord ; tout le reste héritera de l’erreur.

Task 10: Force a resync on Windows and interpret errors

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

Ce que cela signifie : si cela échoue avec « no time data was available », votre client ne peut pas atteindre une source valide.
Décision : Une resynchronisation réussie mais des erreurs d’auth persistantes suggèrent que l’autorité (DC/passerelle VPN) est incorrecte, pas le client.

Task 11: Detect time jumps and NTP corrections in logs (Linux)

cr0x@server:~$ sudo journalctl -u chronyd --since "2 hours ago" | tail -n 12
Dec 28 07:22:10 branch-app-7 chronyd[812]: Selected source 10.20.1.10
Dec 28 07:22:42 branch-app-7 chronyd[812]: System clock wrong by 1.832 seconds, adjustment started
Dec 28 07:23:14 branch-app-7 chronyd[812]: System clock synchronized
Dec 28 07:58:15 branch-app-7 chronyd[812]: Source 10.20.1.10 replaced with 10.20.1.11
Dec 28 07:58:47 branch-app-7 chronyd[812]: System clock wrong by 0.412 seconds, adjustment started

Ce que cela signifie : des messages répétés « System clock wrong by X seconds » indiquent une instabilité — soit l’horloge locale dérive, soit l’amont est instable.
Décision : Si les corrections correspondent à des événements WAN, envisagez une source temporelle locale en succursale ou une meilleure politique WAN pour UDP/123.

Task 12: Confirm NTP server is serving and who is querying (Linux server)

cr0x@server:~$ sudo chronyc clients
Hostname                      NTP   Drop Int IntL Last     Cmd   Drop CmdL
===============================================================================
branch-fw-1                     12      0   6    -   42s       0      0    -
branch-dc-2                      8      0   6    -   38s       0      0    -
vpn-gw-1                         6      0   6    -   44s       0      0    -

Ce que cela signifie : votre serveur voit des clients ; les compteurs « Drop » montrent les paquets perdus.
Décision : Si une succursale échoue mais n’apparaît pas ici, elle n’atteint pas le serveur — problème de chemin réseau.

Task 13: Validate NTP server reachability from a branch router/firewall (Linux-based appliance)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 123 and host 10.20.1.10 -c 6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:14:10.111111 IP 10.60.8.2.49823 > 10.20.1.10.123: NTPv4, Client, length 48
09:14:10.145678 IP 10.20.1.10.123 > 10.60.8.2.49823: NTPv4, Server, length 48
09:14:11.111209 IP 10.60.8.2.49823 > 10.20.1.10.123: NTPv4, Client, length 48
09:14:11.146001 IP 10.20.1.10.123 > 10.60.8.2.49823: NTPv4, Server, length 48

Ce que cela signifie : requêtes et réponses sont visibles. Si vous ne voyez que des requêtes, les réponses sont supprimées (pare-feu stateful, ACL, NAT).
Décision : Corrigez la politique réseau avant d’ajuster chrony ; chrony ne peut pas discipliner une horloge sans paquets de retour.

Task 14: Check for VM guest time sync conflicts (Linux guest example)

cr0x@server:~$ systemctl is-enabled chronyd; systemctl is-enabled systemd-timesyncd
enabled
disabled

Ce que cela signifie : vous devriez exécuter un seul client de synchronisation temporelle. Décision : Si les deux sont activés, désactivez-en un et retestez la dérive.

Task 15: Detect certificate validity errors tied to clock drift (Linux client)

cr0x@server:~$ openssl s_client -connect vpn.example.internal:443 -servername vpn.example.internal 2>/dev/null | openssl x509 -noout -dates
notBefore=Dec 28 08:00:00 2025 GMT
notAfter=Mar 27 08:00:00 2026 GMT

Ce que cela signifie : comparez « notBefore » à l’heure UTC actuelle du client. Si le client est en retard, il peut voir « not yet valid ».
Décision : Ne faites pas de rotation de certificats pour « réparer » cela. Réparez l’heure, puis relancez la négociation TLS.

Task 16: Confirm firewall counters for UDP/123 (Linux nftables example)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    udp dport 123 ip saddr 10.60.0.0/16 accept
  }
}

Ce que cela signifie : vous autorisez NTP depuis les sous-réseaux de succursale. Si la règle n’est pas présente, votre serveur NTP peut ignorer silencieusement les succursales.
Décision : Rendre NTP explicite dans la politique de pare-feu ; « allow all from internal » est la manière d’échouer aux audits tout en manquant NTP.

Trois mini-récits d’entreprise (crédibles, douloureux, réparables)

Mini-récit 1 : L’incident causé par une fausse hypothèse

Une entreprise de taille moyenne a ouvert deux nouveaux bureaux après une acquisition. Ils avaient une forêt AD existante, des concentrateurs VPN au siège et une PKI interne correcte.
Le plan d’intégration avait bien pris en compte le DNS et le routage. Le temps était supposé « fonctionner tout seul » parce que le domaine Windows « gère ça ».

Le premier jour, les utilisateurs du nouveau bureau se sont plaints que la connexion prenait des plombes et parfois échouait. Les connexions VPN réussissaient, puis le client se déconnectait au bout d’une minute.
Pendant ce temps, quelques jump hosts Linux commençaient à lancer des erreurs TLS contre des APIs internes. Le canal d’incident s’est rempli de demi-vérités :
« la réplication AD est cassée. » « La CA a émis de mauvais certificats. » « Le firmware VPN est instable. »

Le vrai problème : le pare-feu de la succursale avait une politique par défaut qui bloquait UDP/123 sortant « pour la sécurité », et les nouveaux ordinateurs portables avaient été en veille pendant des semaines.
Ils se sont réveillés avec des horloges périmées, puis ont dérivé davantage parce que NTP ne pouvait pas atteindre les serveurs internes. Kerberos a commencé à rejeter les tickets, et la passerelle VPN —
qui validait des assertions à courte durée de vie — a semblé se comporter de façon aléatoire.

La réparation fut presque insultante de simplicité : autoriser UDP/123 depuis la succursale vers les serveurs NTP internes et appliquer la hiérarchie de domaine pour les clients Windows.
La partie difficile fut d’admettre que l’hypothèse était fausse. Le postmortem n’a pas été sur « quelqu’un a oublié une règle de pare-feu ». Il a porté sur le fait de traiter le temps comme une dépendance,
pas comme un bruit de fond.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a décidé d’« optimiser le trafic WAN ». Ils avaient des dizaines de petits sites connectés via SD-WAN et voulaient réduire le bruit.
Quelqu’un a remarqué que NTP était un flux constant et a imposé une politique : limiter le débit UDP/123 et allonger les intervalles de sondage sur les clients.
Sur le papier, c’était un gain : moins de trafic, moins de paquets, des graphiques plus propres.

Puis le SD-WAN a commencé à faire ce que fait le SD-WAN : changements de chemin. Quelques succursales sont passées d’un MPLS à faible latence à un transport Internet plus hautement latent.
Les paquets NTP arrivaient en retard ou par rafales. Les clients avec des intervalles de sondage plus longs avaient moins d’échantillons, donc ils faisaient confiance à des mesures bruyantes.
Leurs offsets ont commencé à osciller. Certains ont sauté l’heure pendant les heures de travail. Cela a créé des bizarreries : des tâches cron lancées deux fois, des pipelines de logs mal ordonnés,
et quelques serveurs applicatifs ont échoué en mutual TLS parce que leurs horloges avaient sauté.

Le pire : rien de tout cela n’a déclenché des alertes « NTP down », parce que NTP n’était pas en panne. Il était dégradé. Le système « fonctionnait » comme une chaise bancale « fonctionne » jusqu’à ce qu’on s’y assoie vite.

Le retour en arrière fut simple : supprimer la limitation agressive, restaurer des sondages raisonnables, et ajouter des relais NTP locaux dans les quelques sites ayant le pire jitter.
La leçon est classique en opérations : optimiser une petite ressource peut déstabiliser une boucle de contrôle critique.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise globale exécutait un service temporel interne strict : deux serveurs NTP par région, GPS au siège, avec supervision sur offset et atteignabilité.
Chaque succursale avait des règles explicites de pare-feu pour UDP/123. Les clients Windows suivaient la hiérarchie de domaine ; Linux utilisait chrony avec deux sources internes.
Ce n’était pas glamour. C’était documenté, revu et testé lors de l’ouverture des bureaux.

Lors d’une importante panne d’ISP, une région a perdu l’accès aux références amont. NTP public était injoignable depuis ce segment.
Les serveurs temporels sont passés en mode « holdover » — continuant à servir l’heure, mais sans mise à jour depuis l’amont. C’est là que beaucoup de configurations dérapent.
La différence était que cette organisation avait des politiques : dérive maximale autorisée avant alerte, et un runbook expliquant exactement ce que l’on vérifie.

La supervision montrait des offsets augmentant lentement mais restant dans des limites acceptables. Les clients continuaient à s’authentifier parce que la hiérarchie locale restait cohérente.
Quand l’amont est revenu, les serveurs se sont resynchronisés prudemment sans sauter l’heure violemment. Personne dans le métier n’a remarqué.

La bonne pratique n’était pas un déploiement massif de NTS partout ni un achat matériel énorme. C’était faire du temps un service de première classe avec redondance et mesure.
Ennuyeux. Correct. Efficace.

Erreurs fréquentes : symptôme → cause racine → correction

1) Les utilisateurs reçoivent « The time difference between the client and server is too great »

Symptôme : les connexions AD échouent de façon intermittente, surtout après veille/hibernation ou après imaging.
Cause racine : dérive de l’horloge du client au-delà de la tolérance Kerberos ; NTP bloqué ou source temporelle incorrecte.
Correction : rétablir l’atteignabilité NTP vers les serveurs internes ; appliquer la hiérarchie temporelle du domaine ; resynchroniser et vérifier avec w32tm /query /status ou chronyc tracking.

2) Le VPN fonctionne pour certains, échoue pour d’autres avec des erreurs de validité de token

Symptôme : boucles d’authentification VPN, « assertion expired », ou coupures après un succès initial.
Cause racine : la passerelle VPN ou le connecteur IdP a une heure incorrecte ; les clients de succursale sont en avance/en retard.
Correction : vérifier les sources temporelles de la passerelle ; contrôler l’offset sur les passerelles et proxies IdP ; corriger NTP et éviter les changements d’heure manuels.

3) Erreurs TLS : « certificate not yet valid » juste après une rotation de certificat

Symptôme : le déploiement d’un nouveau certificat semble « cassé » dans un seul bureau.
Cause racine : les clients de ce bureau sont en retard ; la fenêtre de validité du certificat commence dans le « futur » par rapport à eux.
Correction : réparer d’abord NTP. Retester avec openssl x509 -noout -dates contre le service.

4) Un DC affiche une heure différente d’un autre

Symptôme : l’authentification réussit contre certains DC et échoue contre d’autres ; la réplication est bruyante.
Cause racine : plusieurs DC configurés avec des sources NTP indépendantes ; le PDC emulator ne joue pas son rôle d’autorité.
Correction : configurer le PDC pour se synchroniser sur des upstreams approuvés ; mettre les autres DC sur la hiérarchie de domaine ; auditer avec w32tm /monitor.

5) L’heure « semble correcte » mais l’offset est bruyant et change sans cesse de source

Symptôme : le client NTP bascule entre serveurs ; le jitter est élevé ; des pas d’horloge occasionnels.
Cause racine : jitter/asymétrie WAN ; shaping SD-WAN agressif ; trop peu d’échantillons à cause d’un sondage long ; amont instable.
Correction : utiliser deux sources internes proches ou plus ; réduire le jitter en corrigeant la politique réseau ; envisager un relais NTP local en succursale.

6) Quelqu’un « corrige » l’heure manuellement et aggrave la situation

Symptôme : les logs deviennent inutilisables, les tâches planifiées se déclenchent mal, les bases de données se plaignent, les incidents deviennent impossibles à reconstituer.
Cause racine : ajustement manuel de l’heure en production ; services de synchronisation temporelle en conflit ensuite.
Correction : arrêter le service temporel, corriger la configuration, redémarrer, permettre un step contrôlé seulement si nécessaire ; documenter un runbook pour correction sûre.

Blague n°2 : La seule chose plus fiable que la dérive temporelle, c’est quelqu’un qui insiste que ce ne peut pas être le temps parce que « NTP est activé ».

Listes de vérification / plan étape par étape

Étape par étape : construire un service temporel résilient inter-bureaux

1. Choisir des serveurs NTP internes autoritatifs : au moins deux par région majeure ou siège. Décidez où vivent les références amont.
2. Définir la politique amont : utiliser plusieurs sources externes ou des sources GPS. Éviter les dépendances amont uniques.
3. Verrouiller les règles de pare-feu : autoriser explicitement UDP/123 depuis les sous-réseaux clients vers les serveurs NTP internes ; refuser le service aux réseaux non fiables.
4. Rendre la hiérarchie AD correcte : configurer le PDC emulator avec des upstreams ; s’assurer que les autres DC utilisent la hiérarchie de domaine.
5. Standardiser les clients : Linux utilise chrony ; Windows utilise w32time ; désactiver la double synchronisation (outils invités vs démon NTP).
6. Définir la dérive acceptable : choisir des seuils d’alerte (exemple : alerter à 250ms, pager à 2s pour systèmes critiques ; plus strict pour DC et passerelles VPN).
7. Instrumenter et alerter : collecter offset/jitter/reach ; alerter sur la perte de source et sur la pente d’augmentation d’offset.
8. Tester les modes de défaillance : simuler une perte WAN pour une succursale ; confirmer que la succursale conserve une heure stable et récupère sans gros sauts.
9. Écrire le runbook : « quoi vérifier en premier » et « comment réparer en toute sécurité » pour l’astreinte et les équipes desktop.
10. Auditer trimestriellement : vérifier l’absence de serveurs NTP voyous, l’absence de NTP public sur les clients, et que les règles de pare-feu des succursales existent toujours.

Checklist d’ouverture d’une succursale (celle que vous utilisez vraiment)

• Confirmer que les VLAN de la succursale peuvent atteindre les serveurs NTP internes via UDP/123 dans les deux sens.
• Confirmer qu’au moins deux sources NTP sont configurées pour les serveurs et les équipements réseau critiques.
• Confirmer que le DC de la succursale (si présent) ne pointe pas vers un NTP Internet aléatoire ; il doit suivre la hiérarchie de domaine.
• Confirmer que la/les passerelle(s) VPN en région se synchronisent depuis la même hiérarchie interne.
• Confirmer que la supervision voit les offsets de la succursale dans les seuils dans l’heure qui suit l’ouverture.

Checklist de réponse à incident : quand l’auth échoue et que vous suspectez le temps

• Mesurer l’offset sur un client en échec et sur un DC/passerelle.
• Vérifier si les paquets NTP reviennent (tcpdump si nécessaire).
• Vérifier si le client utilise la bonne source temporelle.
• Réparer l’atteignabilité d’abord, puis resynchroniser ; éviter les steps manuels pendant les heures ouvrables sauf si absolument nécessaire.
• Après correction, retester le chemin d’auth original (émission de ticket Kerberos, connexion VPN, poignée de main TLS) pour confirmer la causalité.

Supervision et alerting qui détectent vraiment

« Service NTP actif » n’est pas de la supervision. C’est de la pensée magique avec des métriques.
Vous devez observer la boucle de contrôle : atteignabilité, offset, jitter et changements de source.

Ce qu’il faut mesurer

• Offset client : surtout sur les contrôleurs de domaine, passerelles VPN, proxies IdP et systèmes d’émission de certificats.
• Registre de reach : la baisse de chrony reach de 377 vers 0 est un indicateur précurseur.
• Changements de sélection de source : des basculements fréquents indiquent instabilité ou jitter réseau.
• Pas d’heure : tout pas sur un système critique doit déclencher une alerte, car il corrèle souvent avec des échecs visibles par les utilisateurs.
• Disponibilité amont : les serveurs NTP internes perdant toutes les sources amont devraient alerter avant que les clients ne dérivent trop.

Seuils d’alerte (valeurs par défaut argumentées)

• Contrôleurs de domaine : avertir à 100ms, pager à 1s, urgence à 5s.
• Passerelles VPN / connecteurs IdP : avertir à 200ms, pager à 2s (les tokens sont courts et les utilisateurs impatients).
• Serveurs généraux : avertir à 500ms, pager à 5s (sauf pour services crypto/auth sensibles).
• Postes de travail : ne pas pager, mais suivre et rapporter. Si tout un site dérive, traitez-le comme un problème de politique réseau.

Ce qu’il faut éviter

• Faire des alertes sur chaque pic transitoire de jitter. Vous habituerez tout le monde à ignorer les alertes.
• Utiliser un seul serveur NTP comme dépendance globale sans redondance.
• Laisser les équipes réseau/sécurité bloquer UDP/123 « temporairement » sans processus d’exception explicite.

FAQ

1) Pourquoi AD se préoccupe-t-il autant du temps ?

Kerberos utilise des horodatages pour empêcher les attaques par rejeu. Si les horloges diffèrent trop, le système ne peut pas distinguer en toute sécurité « tard » de « rejoué », donc il rejette.

2) Est-ce que cinq minutes de skew est toujours la limite ?

C’est un défaut courant, pas une loi physique. Vous pouvez changer les tolérances, mais augmenter la tolérance de skew est généralement une mauvaise correction :
cela affaiblit la sécurité et masque le vrai problème (distribution du temps cassée).

3) Les succursales doivent-elles se synchroniser directement sur des NTP Internet ?

En général non. Cela complique le pare-feu, l’audit et la cohérence. Préférez des serveurs internes pour que tous les bureaux partagent la même hiérarchie et que vous puissiez la superviser.
Il existe des exceptions (très petits sites sans VPN et sans adhésion de domaine), mais ce sont des exceptions à documenter.

4) chrony vs ntpd vs systemd-timesyncd : que devrais-je utiliser ?

Pour les serveurs et les succursales avec vraie variabilité réseau, chrony est généralement le meilleur choix car il gère bien le jitter et la connectivité intermittente.
systemd-timesyncd convient pour des clients simples. ntpd peut fonctionner, mais dans beaucoup d’environnements modernes chrony est plus simple opérationnellement.

5) SD-WAN peut-il casser NTP même si « UDP est autorisé » ?

Oui. Le shaping, le policing, les changements de chemin et le routage asymétrique peuvent augmenter le jitter et déformer les estimations de délai.
NTP peut être joignable mais instable, ce qui est pire qu’une panne nette parce que cela produit un temps incohérent.

6) Comment gérer le temps dans des réseaux isolés sans Internet ?

Exécutez des serveurs NTP internes avec une référence locale (GPS ou oscillateur discipliné) ou une stratégie de holdover bien gérée.
L’essentiel est la cohérence : les clients doivent tous suivre la même hiérarchie interne et vous devez surveiller la dérive dans le temps.

7) Et les secondes intercalaires — cassent-elles des choses ?

Elles peuvent. Certains systèmes gèrent mal les secondes intercalaires, et des traitements incohérents entre appareils peuvent créer de brèves désaccords temporels.
Utiliser une source temporelle cohérente et des clients disciplinés réduit le risque ; évitez de mélanger des comportements temporels « spéciaux » dans votre flotte.

8) Pourquoi les certificats échouent quand le temps n’est décalé que d’un peu ?

Les certificats ont des fenêtres de validité strictes, et certains clients mettent en cache des décisions dépendantes du temps.
Une petite dérive peut suffire à franchir une frontière de validité, notamment juste après une rotation lorsque le « notBefore » est récent.

9) Dois-je autoriser les clients à utiliser les DC comme sources NTP, ou seulement des serveurs NTP dédiés ?

Les deux modèles peuvent fonctionner, mais choisissez-en un et appliquez-le. Beaucoup d’environnements utilisent les DC comme sources temporelles pour les membres du domaine
tout en s’assurant que le PDC emulator est le seul DC tirant l’heure de l’extérieur. Les serveurs NTP dédiés peuvent être plus propres pour les systèmes non-Windows et l’équipement réseau.

10) Si une machine est très décalée, est-il sûr de stepper l’heure immédiatement ?

La sécurité dépend de la charge de travail. Pour un portable, faire un step est généralement acceptable. Pour des bases de données, des brokers de messages et tout ce qui implique l’ordre sensible, le step peut être dangereux.
Préférez une correction contrôlée : réparer NTP, puis laisser le service temporel corriger convenablement, effectuer un step seulement si nécessaire et idéalement pendant une fenêtre de maintenance.

Étapes suivantes (la voie raisonnable)

Si vous gérez AD, VPN ou quoi que ce soit lié aux certificats, traitez le temps comme un service plateforme interne. Pas une fonctionnalité de fond. Un service.
Construisez une hiérarchie, restreignez-la, surveillez-la et testez ses modes de défaillance.

Actions pratiques que vous pouvez effectuer cette semaine :

1. Identifier le PDC emulator et vérifier que ses sources temporelles amont sont correctes et redondantes.
2. Choisir deux serveurs NTP internes par région et rendre l’atteignabilité UDP/123 explicite dans la politique de pare-feu.
3. Auditer quelques clients par bureau : confirmer leurs sources, offsets et qu’ils n’utilisent pas NTP public.
4. Ajouter des alertes sur l’offset et le reach (pas seulement la disponibilité du démon) pour les DC, passerelles VPN, composants IdP et serveurs NTP internes.
5. Exécuter un test de panne WAN de succursale : confirmer que le temps reste stable et que la récupération n’entraîne pas de grands sauts.

Faites cela et vous éviterez une catégorie de pannes qui ressemblent à « bizarreries de sécurité », « instabilité réseau » et « Windows qui fait Windows » ,
mais qui ont en réalité la même cause ennuyeuse : une dérive temporelle que vous n’avez pas mesurée.