Horloge des serveurs : vérifiez votre synchronisation NTP

Les connexions échouent alors que les comptes sont valides, et les journaux racontent les événements dans le mauvais ordre. Vérifiez les horloges avant de multiplier les changements sur l’annuaire ou l’application : voici les contrôles à demander et les corrections à encadrer.

Je commencerais par une question simple : qui donne l’heure à ce serveur, et quand l’a-t-il reçue pour la dernière fois ? Une capture de l’horloge dans la barre des tâches ne répond pas à la question. Le statut démarré du service non plus.

Remontez jusqu’à la source qui donne réellement l’heure

Choisissez un parcours critique : connexion au poste, accès au partage de fichiers ou ouverture de l’application métier. Relevez les machines impliquées et leur source de temps effective. Ajoutez les hyperviseurs, les équipements réseau et le collecteur de journaux au périmètre suivant.

Pour chaque machine, consignez son rôle, sa source sélectionnée, sa dernière synchronisation et la personne qui gère sa configuration. Remontez ensuite la chaîne. Si le serveur suit un relais interne, vérifiez aussi ce relais. Une liste de noms de serveurs NTP dans un fichier ne démontre pas leur utilisation.

Sur un domaine Active Directory, les membres suivent normalement la hiérarchie du domaine. L’émulateur PDC du domaine racine de la forêt occupe une place particulière : sa référence externe doit être configurée et vérifiée. Microsoft décrit ce fonctionnement dans sa documentation du service de temps Windows.

N’ajoutez donc pas un serveur public sur chaque poste pour régler un incident local. Retrouvez d’abord l’endroit où la chaîne cesse de fonctionner.

Relevez l’état avant de toucher aux réglages

Sur Windows, ouvrez une invite de commandes avec les droits adaptés et collectez ces informations :

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

Ces commandes exposent la source utilisée, l’état du service de temps et sa configuration effective. Conservez les sorties avec le nom de la machine. Comparez les paramètres appliqués aux paramètres attendus, notamment ceux gérés par stratégie de groupe.

Sur Linux, si chrony est le service installé, utilisez :

chronyc tracking
chronyc sources -v

Le manuel de chronyc détaille ces résultats. Dans sources, l’astérisque désigne la meilleure source sélectionnée. Un point d’interrogation signale une source non sélectionnable, pour plusieurs raisons possibles : injoignable, non synchronisée ou encore insuffisamment mesurée. Ce symbole ne désigne donc pas automatiquement une panne réseau.

Dans tracking, examinez aussi Leap status et System time. Ce dernier indique la correction restante entre l’horloge système et l’horloge NTP entretenue par chrony. Ne le confondez pas avec tous les autres écarts affichés.

Bon plan : commencez avec ces commandes de diagnostic et votre supervision existante. Achetez une prestation pour résoudre un écart identifié, pas pour obtenir un rapport qui confirme seulement que le service tourne.

Séparez le décalage d’affichage de la dérive réelle

Avant de comparer deux journaux, vérifiez leur fuseau et leur format d’horodatage. L’un peut afficher l’heure locale et l’autre UTC. Comparez le même événement avec les décalages de fuseau explicités. Ne modifiez pas l’horloge système pour faire coïncider visuellement deux écrans.

Une erreur d’authentification exige ensuite un contrôle des machines concernées, pas seulement du poste utilisateur. Le guide Microsoft de dépannage Kerberos associe notamment l’erreur KRB_AP_ERR_SKEW à une désynchronisation des horloges.

Demandez à l’équipe de conserver l’erreur exacte, le serveur contacté et les relevés de temps correspondants. Une connexion réussie après une correction constitue un résultat utile. Elle ne prouve pas que les autres serveurs suivent une référence correcte.

Évitez surtout d’élargir une tolérance d’authentification pour masquer une dérive. Faites corriger la source ou son accès. Sinon, le prochain diagnostic commencera avec un réglage exceptionnel dont personne ne se souvient.

Corrigez la cause avant de forcer l’horloge

Vérifiez la résolution du nom de la source, les règles réseau et la configuration réellement chargée. Pour Windows, la documentation du service précise l’usage du port UDP 123. Un accès web fonctionnel ne valide pas ce flux.

Demandez aussi qui pilote l’heure d’une machine virtuelle. Examinez les paramètres du système invité et les fonctions de synchronisation de l’hyperviseur selon sa documentation. Ne désactivez pas une fonction partout sur la foi d’une recette trouvée pour un autre environnement.

Une horloge fausse se corrige comme une dépendance de production, pas comme une préférence d’affichage.

Chrony corrige normalement l’heure progressivement. Son manuel avertit qu’un saut forcé avec makestep peut affecter certains logiciels. Avant une correction importante, demandez au responsable applicatif ce qui doit être arrêté, contrôlé ou relancé. Préparez la fenêtre et les vérifications métier.

Après l’intervention, relevez de nouveau la source et l’écart. Vérifiez les traitements attendus et l’ordre des événements enregistrés. Annotez la période de correction dans le dossier d’incident : elle compte pour interpréter les traces.

Surveillez la synchronisation, pas seulement le processus

Ajoutez à la supervision des contrôles sur la perte de synchronisation, l’ancienneté de la dernière mesure utile et l’écart observé. Faites définir les seuils selon les exigences des applications et la fréquence normale des échanges. Un seuil copié sans ces informations n’a pas de justification opérationnelle.

Contrôlez aussi les changements de source inattendus. Attribuez chaque alerte à une personne capable d’examiner la chaîne de temps et le réseau concerné. Le message doit nommer la machine, la source et le contrôle en échec.

Rattachez ces notifications à votre organisation des alertes de supervision. Si un relais commun tombe, rendez cette cause visible pour éviter que chacun enquête séparément sur son serveur.

Faites enfin tester la détection sur un périmètre de laboratoire. Interrompez l’accès à la source dans cet environnement, puis vérifiez l’alerte et son retour à la normale. Ne changez pas l’heure d’un contrôleur de domaine en production pour tester un voyant.

Faites cette semaine le contrôle d’une chaîne complète

Choisissez un service métier et son responsable. Le résultat attendu est une chaîne de temps comprise et des écarts attribués.

• Identifier les machines du parcours et leurs sources effectives.
• Remonter chaque relais jusqu’à la référence retenue.
• Conserver les états de synchronisation et les écarts relevés.
• Distinguer les problèmes de fuseau des dérives d’horloge.
• Attribuer chaque anomalie avec une échéance et une méthode de correction.
• Préparer les contrôles applicatifs avant toute correction importante.
• Vérifier que la supervision détecte une perte de synchronisation.

Si un prestataire administre ces serveurs, demandez ces preuves dans le prochain compte rendu d’exploitation. Faites préciser si la recherche de panne, la correction réseau et la validation applicative sont comprises dans sa prestation. Le bon de commande doit acheter la résolution du problème, pas seulement une remise à l’heure ponctuelle.