D’abord, NTP (Network Time Protocol), est le protocole standard qui permet de garder les machines informatiques à l’heure via des requêtes réseaux. Les services NTP sont ainsi normalisés et maintiennent une qualité de l’heure sur le réseau, cela en étudiant la propagation.
Donc, il est ici question de la maîtrise des secondes intercalaires au sein du réseau en analysant les distances et en apportant de la précision.
Objectif
Fondamentalement, avec de tels algorithmes et de telles précisions, l’objectif est de n’avoir aucun retard ou quasiment pas.
La synchronisation du temps est essentielle dans un environnement informatique, particulièrement dans Active Directory, puisque c’est un environnement transactionnel.
L’idée globale est de garantir un bon fonctionnement des processus de base : l’authentification, la réplication des données et la cohérence des journaux d’événements.
Les strates ou la qualité du temps
Cette qualité est classée en fonction de sa distance avec les horloges atomiques. Les serveur NTP sont ordonnés en couches ou strate, du stratum 1 au stratum 15. L’indication stratum 16 est utilisée pour signifier un état non synchronisé d’un serveur NTP.
Ainsi, un serveur NTP de strate 2 se synchronise fatalement sur ceux des strate 1 et ainsi de suite.
Par conséquent, un faible niveau de strate indique une bonne qualité de la base de temps : plus le niveau de strate est faible, plus la qualité du temps est meilleure.
Enfin, une strate de niveau 3, 4 ou 5 est considérée comme correcte et cohérente au sein d’une infrastructure Active Directory, clients compris.
Active Directory et NTP
Active Directory est sensible au temps, un peu plus que d’autres technologies certainement. Les serveurs, les clients ainsi que les autres composants doivent être synchronisés pour les mêmes raisons évoquées plus haut.
Le contrôleur de domaine principal joue un rôle crucial dans cette synchronisation du temps pour l’environnement Active Directory. Le PDCE, PDC Emulator en anglais, est la source faisant autorité naturellement en utilisant le protocole NT5DS pour les clients natifs Active Directory (machines Windows jointes au domaine typiquement).
Malgré tout, il convient de paramétrer les autres contrôleurs de domaines en utilisant le protocole standard.
Le PDCE doit être à la fois client NTP et serveur de temps via le port standard (123/tcp-udp).
Configuration NTP via BDR
Dans un environnement Microsoft Windows Active Directory, les clients tout comme les serveurs peuvent se configurer à l’aide de trois méthodes différente : par modification de la base de registre (c’est clair « has been » 😒), par l’utilitaire w32tm.exe ou par GPo.
- Configuration de Microsoft Windows comme client NTP par modification du registre :
Registry Settings System Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers]
Value Name: (Default)
Data Type: REG_SZ (String Value)
Value Data: fr.pool.ntp.org
- Configuration de Microsoft Windows comme serveur NTP par modification du registre :
System Key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
Value Name: LocalNTP
Data Type: REG_DWORD (DWORD Value)
Value Data: (0 = disabled, 1 = enabled)
Comme nous pouvons nous y attendre, ces modifications nécessitent le redémarrage du service W32Time pour qu’elles soient effectives.
- Configuration du client st eserveur NTP par l’utilitaire w32tm :
Arrêt du service de temps : sc stop w32time
Configuration de la base de temps : w32tm /config /syncfromflags:manual /manualpeerlist: « fr.pool.ntp.org,0x8 »
Configuration du serveur de temps : w32tm /config /reliable:yes
Mise à jour de la configuration : w32tm /config /update
Démarrage du service de temps : sc start w32time
Vous pouvez lancer la commande w32tm /resync pour amorcer/initialiser une synchronisation manuellement.
La BRD et w32tm permettent une configuration convenable, mais restent toutefois une méthode empirique. Voilà pourquoi, l’utilisation de la GPo est vraiment la plus élégante.
Dans ces deux approches, seul le PDCE est en mesure de fournir la base de temps (avec un niveau de strate faible) aux clients gérés par Active Directory et aux autres contrôleurs de domaine. Tellement que, selon moi, cette situation soulève des questions légitimes : quid des autres contrôleurs de domaine comme serveur NTP ? … ou encore quid de la prise en charge des clients NTP non-Windows ?
Au fur et à mesure de ma réflexion, la configuration recommandée est celle basée sur les GPo : simple, efficace, dynamique et apporte une bonne résilience ainsi qu’on bon nivèlement.
Configuration NTP via GPo
Rapidement, voici l’approche tactique et sa mise en œuvre :
- Forger une première GPo au niveau de l’OU « Default Domain Controllers » pour diriger le PDCE vers une source NTP.
Une configuration exclusive du PDCE nécessite l’ajout du filtre WMI comme suit : « select * from Win32_ComputerSystem WHERE DomainRole = 5 »
En faisant autrement, nous pouvons penser alors il y aura fatalement des secondes intercalaires entre le PDCE et les autres contrôleurs de domaine. Ce raisonnement est logique, mais va à l’encotre de la logique NTP de Microsoft.
La configuration est à faire au niveau de la structure suivante : Computer Configuration > Administrative Templates > System > Windows Time Service > Time Providers
Configure Windows NTP Client : Enabled
Enable Windows NTP Client : Enabled
Enable Windows NTP Server: Enabled
- Forger une seconde GPo pour configurer les serveurs NTP exploitables par les clients non-Windows. Cette GPo devra toujours être au niveau de l’OU « Default Domain Controllers »
Le filtre WMI doit être légèrement différent comme suit : « select * from Win32_ComputerSystem WHERE DomainRole <> 5 »
Grâce à la combinaison de ces deux GPo, vous pourrez baser votre temps avec l’unique nom FQDN de votre domaine pour les client non-Windows. Ceci permet de bénéficier une bonne synchronisation du temps pour les authentifications ainsi que d’une bonne résilience.
La configuration est à faire au niveau de la structure suivante : Computer Configuration > Administrative Templates > System > Windows Time Service > Time Providers
Enable Windows NTP Server: Enabled
Tout compte fait, c’est ainsi tout simplement la meilleure façon d’avoir la résilience et la scalabilité, quelle que soit la situation. Les contrôleurs de domaine fournissent le temps via le protocole standard NTP et via NTDS à l’ensemble des clients (Windows et autres).
Le déplacement du rôle FSMO devient sans impact au sein de l’infrastructure Active Directory.
Un moyen mnémotechnique
- Le PDCE se synchronise idéalement avec une source externe fiable,
- Les contrôleurs de domaine se synchronisent avec le PDCE (unique par domaine),
- Tous les membres du domaine utilisent utiliser l’heure du domaine NT5DS,
- N’importe quel client peut se synchroniser avec n’importe quel contrôleur de domaine,
- Le PDCE du domaine enfant peut se synchroniser avec n’importe quel contrôleur de domaine du domaine parent.
Considération des autres bases de temps NTP
Lorsque la source de temps de l’infrastructure est configurée et légitimée, il est important de la mettre en avant pour l’ensemble des composants.
C’est logique pour une démarche d’homogénéisation et de simplification des configurations. Si ce n’est pas le cas, dites-vous qu’il n’est jamais trop tard pour amender les configurations historiques.
Subséquemment, il faut s’assurer qu’aucun composant ne soit synchronisé localement ou vers une autre source, e.g. auprès des hyperviseurs. Ce sont des cas classiques qui provoquent facilement un glissement horaire au cœur d’une infrastructure Active Directory.
En un mot, la source doit être fiable et unique pour l’ensemble des clients pou rune infrastructure donnée.
Vérification NTP
Il est important de surveiller régulièrement la synchronisation du temps au sein de l’environnement Active Directory.
Cela est possible en exploitant les outils tels que w32tm, les journaux d’événements Windows ou encore des outils tiers dédiés à cet effet.
Exemple d’utilisation de w32tm ci-dessous :
w32tm /query /status
w32tm /monitor
Sécurité informatique et NTP, quel lien ?
A priori, le lien n’est pas évident pour tout le monde. Cette situation est dommageable puisque ce lien assez fort est vérifiable.
Dès lors que l’authentification soit liée à la bonne synchronisation du temps, il nous est impossible de nier ou ignorer cela. Incontestablement et indirectement, la sécurité du serveur NTP est donc déterminante pour garantir l’intégrité, la confidentialité et la disponibilité des systèmes.
Chaque entreprise doit ainsi prendre les mesures adaptées pour sécuriser cette base de temps qu’est la sienne.
Ce concept amène une interrogation non anodine : faut-il se caler aux temps fournis par Internet ? La bonne réponse dépend de votre politique de sécurité et de votre tolérance aux pannes. Tout est une question de stratégie et de compromis car les attaquent NTP ne sont pas des légendes.
Conclusion
Pour résumer, une synchronisation correcte est essentielle dans un environnement Active Directory. C’est fondamental, car effectivement il s’agit d’assurer la cohérence et la fiabilité des opérations et des processus dans l’infrastructure, au niveau global.
Architecturer convenablement la base de temps est donc utile. D’ailleurs, bien architecture tout simplement n’est jamais futile !
C’est pourquoi la tendance doit tendre vers le parfait en matière de NTP et d’architecture. C’est rarement notre constat sur le terrain (sic),
Les choix relatifs à l’implémentation du temps de reference dépendent des enjeux, des règles et de la topologie réseaux intrinsèques à votre infrastructure elle-même.
Le NTP ne peut être une histoire d’improvisation. De surcroit, cela ne peut pas non plus être une histoire de technologie (famille de systèmes ou types de plateforme … faux débat) !
Bref, au même titre que le DNS, le NTP est un service essentiel à considérer tout au long de la vie de son infrastructure informatique.