Les paramètres par défaut du domaine Windows permettent d'obtenir un délai de +/- 300 secondes avant que l'authentification ne cesse de fonctionner, ce qui ne pose pas de problème. Voici un article assez exhaustif sur le sujet qui indique même comment modifier votre tolérance à l'asymétrie temporelle à l'aide d'un GPO au niveau du domaine. Il se trouve à l'adresse Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Kerberos Policy -> Maximum tolerance for computer clock synchronization .

Cela dit, vous devriez faire en sorte que votre source de temps faisant autorité (qui est généralement le contrôleur de domaine détenant le rôle d'émulateur PDC dans un domaine Windows) se synchronise avec une source de temps externe. ntp source, comme pool.ntp.org . Plus d'informations sur Technet, ici .

Et pour répondre à l'autre question, cela ne nécessite pas de temps d'arrêt. Il suffit de réorienter la source de temps qui fait autorité et le reste des ordinateurs reliés au domaine se synchroniseront également.

EDIT : puisque @voretaq7 l'a mentionné, je dois préciser que nous n'avons qu'un seul système qui voit une source de temps extérieure, notre émulateur PDC. Tous les appareils, y compris l'équipement réseau, se synchronisent sur cette source. Nous estimons qu'il s'agit d'une meilleure solution, car l'équipement réseau ne rejettera pas l'authentification en raison du décalage temporel, mais les ordinateurs reliés à un domaine et utilisant Kerberos (ce qui est le cas de tous, pour nous) le feront. À cet égard, il n'est pas particulièrement important d'avoir une heure exacte sur notre équipement de réseau, mais elle l'est sur nos systèmes Windows, d'autant plus que nous exécutons notre logiciel de chronométrage pour les employés horaires sur un serveur Windows également.

Les clients Windows n'auront aucun problème à se connecter. La description de la Maximum tolerance for computer clock synchronization est plutôt inexacte de nos jours.

Un client dont l'horloge est gravement erronée recevra une réponse du serveur établissant le décalage entre leurs horloges - l'authentification se déroule alors normalement (le client s'ajustant lui-même pour tenir compte du décalage apparent de l'horloge).

La description a raison sur un point : la politique fixe toujours effectivement le délai pour les attaques par rejeu - mais, en termes de trafic légitime, la communication est robuste face à de grands décalages d'horloge.

Véase cet article de MS KB pour plus d'informations.

Vous pouvez envisager d'utiliser d'autres serveurs NTP que votre équipement principal Cisco : un trafic NTP important entraîne une charge de travail élevée sur l'équipement Cisco, ce qui peut provoquer des problèmes de réseau.

Il est évident que vous ne pouvez pas prévoir un petit temps d'arrêt, n'est-ce pas ? J'insisterais pour qu'il y ait un temps d'arrêt afin de redémarrer le service ntp sur tous les serveurs concernés. Si ce n'est pas possible, vous devrez attendre un certain temps.