Synchronisation de l'heure dans Active Directory : l'émulateur PDC, Kerberos et les pièges de la virtualisation
La synchronisation de l'heure fait partie de ces sujets que l'on ne remarque que lorsqu'ils cassent. Or, dans un domaine Active Directory, le temps est une donnée de sécurité : Kerberos en dépend, la corrélation des journaux aussi. Une configuration approximative se traduit par des pannes d'authentification difficiles à diagnostiquer et par des enquêtes faussées.
Pourquoi l'heure est une question de sécurité
Kerberos utilise des horodatages pour se protéger contre le rejeu : une demande dont l'heure s'écarte trop de celle du contrôleur de domaine est refusée. La tolérance est fixée par le paramètre de stratégie Kerberos « Tolérance maximale pour la synchronisation de l'horloge de l'ordinateur », de cinq minutes par défaut. L'augmenter pour masquer un problème de synchronisation affaiblit la protection sans rien résoudre.
Au-delà de Kerberos, l'heure conditionne la validité des certificats, le fonctionnement des codes à usage unique basés sur le temps et, surtout, la capacité à reconstituer une attaque. Lorsque les journaux des contrôleurs de domaine, des pare-feu et des postes ne sont pas alignés, la chronologie d'un incident devient une source de débats plutôt qu'un fait établi.
La hiérarchie de temps du domaine
Le service de temps Windows (W32Time) organise une hiérarchie automatique lorsque les machines utilisent le mode de synchronisation du domaine (type NT5DS) :
- les postes et serveurs membres se synchronisent sur un contrôleur de domaine de leur domaine ;
- les contrôleurs de domaine se synchronisent sur l'émulateur PDC de leur domaine, ou sur un DC du domaine parent ;
- l'émulateur PDC du domaine racine de la forêt est la source de référence de toute la forêt.
Seul ce dernier doit être configuré pour interroger des sources externes (type NTP), idéalement plusieurs serveurs fiables : serveurs de temps internes adossés à une référence matérielle, ou serveurs publics de confiance autorisés par le pare-feu. Tous les autres contrôleurs de domaine restent en mode hiérarchique. Configurer manuellement une source externe sur chaque DC casse la cohérence de la hiérarchie.
Suivre le rôle d'émulateur PDC
Le piège classique survient lors du transfert du rôle d'émulateur PDC : le nouveau titulaire ne pointe vers aucune source externe, tandis que l'ancien continue de s'annoncer comme source fiable. Pour éviter cela, de nombreuses organisations appliquent la configuration par une GPO dédiée, liée à l'OU des contrôleurs de domaine et filtrée par une requête WMI qui cible le rôle d'émulateur PDC. La configuration suit ainsi automatiquement le rôle. Pensez aussi à inscrire la vérification de l'heure dans la procédure de transfert des rôles FSMO.
Les commandes w32tm /query /status, w32tm /query /source et w32tm /monitor permettent de vérifier la source effective de chaque machine et l'écart entre contrôleurs de domaine.
Les contrôleurs de domaine virtualisés
La virtualisation ajoute une seconde source de temps potentielle : l'hyperviseur. Les services d'intégration de Hyper-V et les outils invités des autres plateformes peuvent synchroniser l'horloge de la machine virtuelle sur celle de l'hôte. Si l'hôte dérive, ou s'il se synchronise lui-même sur un contrôleur de domaine qu'il héberge, on obtient des boucles et des sauts d'heure imprévisibles.
La recommandation générale est que les DC virtualisés obtiennent leur heure par la hiérarchie du domaine et non par l'hyperviseur, tout en gardant à l'esprit que certaines plateformes resynchronisent l'horloge lors d'événements particuliers (reprise après suspension, migration, restauration d'instantané). Les réglages exacts dépendent de la plateforme et de sa version : suivez la documentation de l'éditeur de l'hyperviseur et celle de Microsoft sur les contrôleurs de domaine virtualisés.
Surveillez aussi les mécanismes automatiques. Certaines fonctions de Windows destinées à corriger l'heure au démarrage ont provoqué, dans certains environnements, des sauts d'horloge importants. Évaluez leur comportement sur vos contrôleurs de domaine à la lumière des recommandations Microsoft en vigueur.
Ce qu'un audit vérifie
- la source de temps de l'émulateur PDC de la racine de forêt et sa fiabilité ;
- le mode hiérarchique sur les autres contrôleurs de domaine et sur les membres ;
- l'écart mesuré entre les contrôleurs de domaine et la valeur de tolérance Kerberos ;
- la configuration de synchronisation de l'hyperviseur pour les DC virtualisés ;
- la présence de la vérification de l'heure dans les procédures de transfert de rôles.