Thursday, October 15, 2015

FR (French) - Active Directory - NTP et la synchronisation horaire

English abstract: I examine EventID 12 in which the domain controller (with PDCe role) cannot connect to an external time source, how to configure the time service, and adjust settings if the PDCe role is transferred to another domain controller.


***

Je venais d'installer une paire de contrôleurs de domaine (désormais abrégé en "DC"), le premier avec une interface anglaise et le second avec une interface française, et, pour vérifier que tout allait bien, j'ai exécuté (entre autres commandes) DCDIAG.

Parmi les différentes vérifications effectuées, DCDIAG rapporte des avertissements enregistrés dans le journal "Système" de l'Observateur d'événements. Après le démarrage d'un DC, ces enregistrements peuvent être assez nombreux et souvent les problèmes relevés se résolvent tout seuls une fois que tous les services démarrent et que le DC entame le processus de "réplication" avec ses partenaires.

Un de ces avertissements se rattache à la "source de temps" dont voici les principaux détails (cliquer sur l'image pour l'agrandir) :



Et voici de quoi il s'agit...

L'identité des ordinateurs clients se vérifie avec le protocole Kerberos qui utilise un système de tickets horodatés que je ne présenterai pas en détail ici. Il suffit de savoir que, par défaut, ce système d'authentification tolère une déviation maximale de 5 minutes entre l'horloge des noeuds en question. Si, donc, l'horloge d'un poste client marque 1h00 et l'horloge du DC qui l'authenifie marque 1h15 (soit une différence de 15 minutes) l'authentification est vouée à l'échec. Ce serait également un problème pour les serveurs membres qui sont, du point de vue de l'authentication, des clients des DC aussi.

En principe, de tels écarts d'horloge ne devraient pas se produire.

  • Les clients (au sens large) obtiennent l'heure du DC qui les authentifie.
  • Les DC obtiennent l'heure du DC tenant le rôle du PDCe (émulateur de PDC).
  • Les PDCe (dans une forêt à plusieurs domaines) obtiennent l'heure du PDCe du domaine racine de la forêt.
  • Le PDCe du domaine racine obtient l'heure exacte d'une source externe dite "fiable".

En fait, s'il y a des problèmes de communication entre noeuds, l'heure pourrait dévier de plus de cinq minutes par rapport à l'heure juste.

En outre, il faut, chez le PDCe du domaine racine, une configuration manuelle afin d'obtenir l'heure de la source externe.

A cela, je dois ajouter les remarques suivantes :

  1. La synchronisation avec une source de temps externe est souhaitable mais non pas indispensable. Kerberos requiert que l'heure soit la même entre membres du domaine (avec une déviation maximale de 5 minutes par défaut). L'heure affichée par le PDCe pourrait être 1h05, et l'heure selon telle horloge atomique 1h45, sans que cela provoque la moindre défaillance dans l'authentification.
  2. C'est le protocole NTP "Network Time Protocol" qui gère l'heure pour Windows Server. NTP recourt au temps universel coordonné ("TUC" ou "UTC" en anglais) ce qui permet à des DC se trouvant dans des fuseaux horaires différents de fonctionner ensemble. Les paramètres pour l'heure locale existent dans le registre et convertissent le TUC en heure locale pour l'affichage dans la barre des tâches en bas et à droite de l'écran (par exemple). NTP utilise le port 123.


Malgré ma première remarque ci-dessus, il vaudrait mieux que l'heure affichée à l'écran des ordinateurs corresponde bien à l'heure juste. Nous pouvons atteindre cet objectif en configurant le PDCe du domaine racine de sorte qu'il obtienne l'heure d'une source de temps externe fiable.

Voici un site canadien qui propose une liste des sources :

http://www.nrc-cnrc.gc.ca/fra/services/heure/synchronisation_reseau.html


Et voici une liste des sources aux Etats-Unis :

http://tf.nist.gov/tf-cgi/servers.cgi


Nous pouvons vérifier l'heure exacte à ce site :

www.heure.com


Note : ces ressources sont loin d'être les seules. J'invite le lecteur à en chercher qui conviennent le mieux à sa situation géographique. En effet, il est préférable d'utiliser une source à proximité - à supposer bien sûr des liens Internet de qualité égale. Il faut s'assurer d'ailleurs que la source soit bien fiable - ce que le site américain montre dans une certaine mesure (si le site était toujours occupé, nous ferions bien d'en choisir un autre).


***

Maintenant, configurons notre PDCe pour qu'il obtienne l'heure d'une source externe.

Voici les paramètres NTP tels que nous les voyons dans le registre avant configuration...

DC3 (anglais) :



DC4 (français) - PDCe :



Les paramètres à noter sont indiqués par de points rouges :

  1. L'endroit dans le registre où nous pouvons observer les paramètres qui nous intéressent et en particulier :
  2. NTPServer
  3. Type

Ce sont là les valeurs par défaut - et le simple fait de désigner un DC comme PDCe ne configure nullement les valeurs appropriées. Nous devons les configurer avec les commandes présentées ci-dessous. Note : nous pouvons vérifier le détenteur des rôles FSMO avec cette commande : netdom query fsmo



La commande suivante configure le PDCe pour qu'il cherche l'heure chez une source externe ("time.nist.gov" dans notre cas) :

w32tm /config /manualpeerlist:"time.nist.gov",0x8 /syncfromflags:manual


Dans d'autres documents, j'ai observé aussi la commande présentée avec deux paramètres supplémentaires :

w32tm /config /manualpeerlist:"time.nist.gov",0x8 /syncfromflags:manual /reliable:yes /update


Le changement s'observe tout de suite dans le registre du PDCe (DC4) :




En revanche, les paramètres de l'autre DC ne changent pas :




Ensuite, nous devons faire redémarrer le service w32tm:

net stop w32time
net start w32time

Et synchroniser l'heure avec la source externe:

w32tm /resync

Voilà ! Nous y sommes. Notre PDCe est configuré pour obtenir l'heure exacte d'une source externe. Au lieu des messages d'erreur présentés au début de cet article, nous avons de simples messages d'information nous faisant savoir que :




***

Maintenant, je déplace le rôle du PDCe vers DC3 :

C:\>ntdsutil
ntdsutil: roles
fsmo maintenance: connections
server connections: connect to server DC3
Liaison à DC3...
Connecté à DC3 en utilisant les informations d'identification d'un utilisateur connecté localement.
server connections: quit
fsmo maintenance: transfer pdc

[...]

Les paramètres dans le registre s'ajustent-ils en conséquence ?

Non, les paramètres ne changent pas (ce sont les mêmes que ceux que vous voyez dans les prises d'écran ci-dessus).

Il faut régler cela manuellement.

Je saisis ces commandes à DC4 (l'ancient PDCe) :

w32tm /config /syncfromflags:domhier /update

net stop w32time
net start w32time


Allons voir les changements dans le registre :



Le paramètre "Type" reprend sa valeur originale (NT5DS au lieu de NTP) alors que le paramètre pour "NtpServer" ne change pas. C'est le paramètre "Type" qui détermine la pertinence du paramètre "NtpServer" . Si "Type" est égal à NT5DS, le DC utilise la hiérarchie de domaine (domhier) pour savoir l'heure qu'il est. Cela est valable même si le paramètre "NtpServer" retient la valeur "time.nist.gov,0x8" (dans notre exemple).



Je saisis ces commandes à DC3 (nouveau PDCe) pour qu'il obtienne l'heure exacte d'une source externe :

w32tm /config /manualpeerlist:"time.nist.gov",0x8 /syncfromflags:manual /reliable:yes /update

net stop w32time && net start w32time

w32tm /resync /rediscover

Note : ce sont des variations des commandes saisies plus tôt mais qui produisent le même effet.


Nous pouvons constater que le paramètre "Type" de DC3 est maintenant "NTP" :




***

Désormais, DC3 (le nouveau PDCe) obtiendra l'heure de la source externe et DC4 obtiendra l'heure de DC 3 (comme tout autre DC). Les autres clients, tant serveurs que stations de travail, obtiendront l'heure du DC qui les authentifie au moment de l'ouverture d'une session sur le réseau. Cela vaut, bien entendu, pour les membres du domaine. Ce système de synchronisation horaire ne serait pas valable pour les clients qui ne s'authentifient pas auprès d'un DC.

No comments:

Post a Comment