Pourquoi un VPN ne règle pas l’horloge d’un portable joint au domaine

Un télétravailleur connecte le VPN, le tunnel monte et les connexions commencent à échouer avec une erreur d’authentification qui mentionne l’heure. Rien n’est cassé dans le tunnel. Un VPN transporte des paquets entre réseaux ; il ne donne pas à deux machines une horloge commune, et l’authentification de domaine, la validation des certificats et la corrélation d’audit dépendent toutes d’horloges qui s’accordent d’assez près. Trois décisions en découlent : qui possède l’heure dans le domaine, ce que l’appareil utilise réellement et ce qui se passe pendant que l’appareil est en itinérance.

Un chemin n’est pas une horloge

L’authentification Kerberos contient des données sensibles au temps et rejette les requêtes hors d’une tolérance configurée, qui est de cinq minutes par défaut dans les domaines Windows. Les certificats portent des intervalles de validité, si bien qu’un appareil dont l’horloge avance assez traite un certificat valide comme pas encore valide. Les enregistrements d’audit de plusieurs machines ne se corrèlent que si leurs horloges sont proches, et cela compte la première fois qu’une revue d’incident demande ce qui s’est produit d’abord.

Ces trois dépendances sont indépendantes du tunnel. Monter un VPN change l’accessibilité, et l’accessibilité est ce qui permet à un appareil de trouver une source de temps ; ce n’est pas la source.

Gardez le fuseau horaire affiché séparé de l’horloge elle-même. Deux portables affichant des heures locales différentes peuvent être parfaitement synchronisés, et deux affichant la même heure peuvent différer de minutes si leurs réglages de fuseau horaire diffèrent. Changer de fuseau horaire n’est pas une réparation d’une horloge fausse, et reculer une date pour faire fonctionner un certificat expiré casse toutes les autres vérifications de la machine qui dépendent du temps.

Décidez qui possède l’heure dans le domaine

Les membres Windows joints au domaine suivent normalement la hiérarchie de temps d’Active Directory au lieu d’interroger un serveur public à chaque fois. Cette chaîne se termine à l’émulateur PDC de la racine de la forêt, dont la référence est la source faisant autorité de l’organisation.

Deux conditions décident de la référence : si la stratégie autorise un service de temps externe, et si le réseau peut joindre de manière fiable une source interne approuvée depuis chaque site. Si les deux sont floues, la réponse pratique est de garder la hiérarchie intacte et de réparer l’accessibilité plutôt que de pointer les clients vers un pool public. Une troisième condition décide du chemin de défaillance : ce que l’appareil doit faire quand aucune des deux sources n’est joignable. Trancher cela à l’avance évite la rustine improvisée consistant à épingler un serveur public sur un portable.

Ce choix appartient aux administrateurs du domaine et du temps, pas à la conception de l’accès distant. Un portable qui se configure comme autorité de temps fiable est une autre architecture, et c’est rarement celle que la revue de sécurité a approuvée.

Lisez ce que l’appareil utilise réellement

Deux commandes en lecture seule documentent l’état actuel sur un appareil Windows géré, et il vaut la peine de les relever avant et après un changement :

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

Notez la source sélectionnée, la dernière synchronisation réussie et la strate ou l’identifiant de référence à côté de la stratégie de gestion de l’appareil. Une synchronisation manuelle réussie prouve que la commande fonctionne, pas que la stratégie survive à un redémarrage ou à un changement de rôle.

Si la source affiche l’horloge CMOS locale, l’appareil ne se synchronise pas du tout, ce qui signifie généralement que le contrôleur de domaine était injoignable au démarrage ou que le service de temps a été désactivé par stratégie. S’il affiche un serveur public, quelque chose hors de la hiérarchie du domaine l’emporte, et c’est une question de stratégie, pas de réseau.

Décidez ce qui se passe en itinérance

Déconnecté, un appareil s’appuie sur son horloge locale et sur les fournisseurs de temps qu’il peut joindre. Les portables dérivent, et un appareil hors ligne pendant des semaines peut dériver assez pour faire échouer la première requête Kerberos après la reconnexion.

À la reconnexion, l’appareil a besoin de la découverte du domaine et du chemin prévu vers le service de temps, pas seulement d’une route vers un partage de fichiers. Testez-le en redémarrant hors réseau, en connectant le VPN et en relisant la source, au lieu de supposer que la hiérarchie s’est rétablie d’elle-même.

Les machines virtuelles ajoutent un fournisseur. L’intégration de temps de l’hyperviseur est une source légitime dans beaucoup de conceptions, mais son rôle doit être choisi délibérément et coordonné avec la stratégie du domaine. Deux fournisseurs en désaccord produisent une horloge qui paraît stable et qui est fausse.

Gardez la stratégie des membres à part de l’autorité

La configuration ordinaire d’un membre et la configuration du serveur faisant autorité sont des problèmes différents avec des contrôles de changement différents. Les mélanger, c’est ainsi qu’un changement de stratégie de routine sur un portable finit par modifier la référence de toute la forêt.

Rédigez la décision en quatre lignes : la source faisant autorité, la hiérarchie qui la porte, le comportement en itinérance et la commande qui prouve l’état sur un appareil. Si les trois premières sont documentées et la quatrième reproductible, un échec de connexion lié au temps devient une vérification de cinq minutes au lieu d’une chasse dans les journaux VPN.