Petit retour d'expérience d'un client qui nous a signalé qu'un de ses serveurs affichait un décalage d'heure de 3 minutes avec le restant des machines du domaine.
En fait, si. Dans un domaine Active Directory, le temps a une importance capitale, et un décalage de temps de 300 secondes (5 minutes) suffit à empêcher les échanges faits entre un contrôleur de domaine et un client lors d'une authentification d'être valides, ce qui cause une instabilité des connexions puis une impossibilité d'accéder à aucune ressource, d'ouvrir une session... ce genre de choses amusantes.
Normalement, un contrôleur de domaine ou un serveur de temps tiers est configuré pour fournir une heure similaire partout autour de lui et s'assurer que ce cas ne se présente jamais.
Sauf que là, une petite subtilité était présente.
En effet, le serveur en question était une machine virtuelle. En se connectant dessus et à l'aide de la commande w32time, j'ai pu voir que sa source était "VMICTimeProvider". N'arrivant pas à forcer l'AD en tant que serveur de temps, je suis allé dans la configuration de l'invité côté Hyper-V : la machine avait de cochée l'option de partager son temps avec l'hôte de virtualisation. Hôte qui n'était pas dans le domaine. Et allait donc chercher son heure sur internet.
Et impossible, le serveur reprenait systématiquement l'hôte en tant que serveur de temps. Redémarrer la VM aurait eu certainement son effet, mais c'était un serveur important en pleine production. Alors après quelques recherches : direction le registre!
On va sur
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider\EnabledOn passe la valeur à 0, et on peut remettre à nouveau changer la source de temps pour celle du domaine!