Pourquoi synchroniser l’heure ?
Au sein d’un domaine Active Directory, tous les postes de travail et serveurs membre synchronisent leur horloge auprès du contrôleur de domaine ayant le rôle d’émulateur PDC (Primary Domain Controller) que joue le rôle de serveur de temps pour le domaine.
Le bon fonctionnement de certains protocoles comme Kerbros v5, utilisé pour authentifier les utilisateurs au sein du domaine et assurer l’accès aux ressources partagées, est fortement dépendant de la synchronisation horaire entre les machines.
En effet, la RFC 4120 stipule que le décalage acceptable entre deux hôtes est de l’ordre de 5 minutes environ.
Each host on the network MUST have a clock which is "loosely synchronized" to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection. The degree of "looseness" can be configured on a per-server basis, but it is typically on the order of 5 minutes.
C’est d’ailleurs cette valeur qui est positionnée par défaut depuis Windows 2000 sur le service Kerberos (cf. article KB837361 de la base de connaissance Microsoft).
Lorsque le décalage entre deux postes dépasse les 5 minutes, aucune authentification n’est possible via le protocole Kerberos. Ceci est particulièrement gênant lorsque la machine décalée correspond à un contrôleur de domaine ou à un serveur de fichiers.
Il convient donc de s’assurer que tous les postes et serveurs sont capables de joindre l’émulateur PDC et de mettre à jour leur horloge (lorsque cela n’est pas le cas, des erreurs W32Time sont générées par le service de temps Windows sur les postes de travail).
Il est également très important de synchroniser l’émulateur PDC avec une source de temps externe valide de manière à ce que l’heure propagée au sein du domaine soit la plus proche possible de l’heure exacte.
Or de trop nombreuses entreprises ne font pas attention à ce point qui n’est pourtant pas un détail car une juste synchronisation de l’horloge simplifie la vie des utilisateurs qui sont très friands de services Web où l’horodatage a une importance certaine (tweeter, myspace ou facebook pour ne pas les nommer).
D’un point de vue IT, la synchronisation de tous les équipements informatique (postes de travail, serveurs, mais aussi NAS, pare-feu et autres équipements réseau) auprès d’une seule et même source de temps permet de simplifier énormément les opérations de dépannage car les fichiers de logs sont alors parfaitement synchrones.
Quelle source de temps utiliser ?
Par défaut tout poste Windows est configuré pour synchroniser son horloge auprès du serveur “time.windows.com”.
De nombreux serveurs NTP “libres” sont accessibles en France et dans le monde (notamment les serveurs NTP des grandes universités françaises). De plus la plupart des FAI proposent à leurs clients un service de synchronisation de temps.
Il est néanmoins un projet qui se distingue de tous les autres par son ampleur : NTP Pool Project. Ce projet a pour objectif de proposer gratuitement un cluster de serveurs de temps gigantesque (1873 serveurs de temps à l’heure où j’écris ces lignes).
L’avantage de ce projet est qu’il propose également une configuration régionalisée par continent et par pays. Ainsi pour synchroniser votre PDC avec des serveurs de temps uniquement situés en France (env. 130 serveurs), il suffit de configurer le serveur pour pointer vers la liste de FQDN suivants :
-
0.fr.pool.ntp.org
-
1.fr.pool.ntp.org
-
2.fr.pool.ntp.org
-
3.fr.pool.ntp.org
Comment procéder ?
Pour reconfigurer l’horloge d’un poste sous Windows et notamment celle d’un émulateur PDC, les commandes suivantes peuvent être utilisées :
-
La commande net time fonctionne sur un contrôleur de domaine Windows 2000, 2003 et Windows 2008 (cette commande est maintenant obsolète avec Windows Server 2008 R2)
-
La commande w32tm doit impérativement être utilisée si le contrôleur de domaine exécute Windows Server 2008 R2
Avec la commande net time, voici la commande à saisir pour reconfigurer l’horloge du serveur de temps (PDC) vers le cluster “pool.ntp.org” français :
net time /setsntp:"0.fr.pool.ntp.org 1.fr.pool.ntp.org 2.fr.pool.ntp.org"
Pour vérifier la modification il est possible d’exécuter la commande net time /querysntp. Pour forcer la resynchronisation du PDC, il suffit de redémarrer le service de temps Windows (net stop w32time | net start w32time).
Sur un contrôleur de domaine Windows Server 2008 R2, la commande suivante doit être exécutée pour arriver au même résultat :
w32tm /config /update /manualpeerlist:"0.fr.pool.ntp.org,0x8 1.fr.pool.ntp.org,0x8 2.fr.pool.ntp.org,0x8 3.fr.pool.ntp.org,0x8" /syncfromflags:MANUAL
Cette commande doit être suivie des commandes suivantes pour que la configuration soit prise en compte et la resynchronisation initiée :
-
w32tm /config /update
-
w32tm /resync
Remarque : Il est également possible de le service de temps Windows pour forcer la resynchronisation (net stop w32time | net start w32time).
Les points à valider
Quelques points doivent être validés avant d’effectuer la modification sur l’émulateur PDC :
-
Le port du protocole NTP doit être ouvert depuis l’émulateur PDC vers Internet (il s’agit du port UDP 123)
-
Si le contrôleur de domaine est virtualisé, il convient de désactiver la synchronisation horaire entre la machine virtuelle et l’hôte physique (sinon l’heure synchronisée à travers le réseau sera toujours réécrite par celle de la machine hôte).
Voici un exemple pour un contrôleur de domaine (émulateur PDC) virtualisé avec Hyper-V 2.0 (version d’Hyper-V intégrée à Windows Server 2008 R2) :
Comment mettre à jour les clients ?
En ce qui concerne les postes membres du domaine, aucune opération manuelle n’est nécessaire, le service de temps Windows étant capable d’effectuer les mises à jour automatiquement.
Pour les postes configurés en groupe de travail, il convient d’exécuter la commande suivante, puis de redémarrer le service de temps Windows :
w32tm /config /update /manualpeerlist:"ntp.ad.lan,0x8"
/syncfromflags:MANUAL,DOMHIER
Remarque : Il est conseillé de créer une entrée DNS de type CNAME (alias) pointant vers l’émulateur PDC (par exemple ntp.domainead.local). Cela permet de pouvoir reconfigurer très simplement tous les postes de travail hors domaine en cas de bascule du rôle FSMO.
Dans le scénario idéal, tous les équipements réseau (commutateurs, routeurs, pare-feu, imprimantes réseau, bornes WiFi, serveurs NAS…) doivent également pointer vers le FQDN ntp.domainead.local de manière à assurer un horodatage cohérent.
Pour aller plus loin…
Quelques liens utiles pour aller plus loin :