Uno de los servidores NTP externos (el principal, actualmente) que estamos utilizando como fuente parece no responder a las llamadas NTP. Desafortunadamente, en nuestro enrutador central (Cisco 6509), la funcionalidad NTP no se ha cambiado al servidor externo NTP secundario como se esperaba. Como resultado, nuestro enrutador central, que es más o menos nuestra principal fuente NTP interna, tiene 2 minutos de retraso.

Estoy planeando solucionar el problema del enrutador externo haciendo que la fuente NTP externa sea la que funciona actualmente. Me pregunto, ¿cuánto afectará un cambio de 2 minutos a mis usuarios y servicios? Especialmente desde estos días, confiamos mucho en la autenticación basada en certificados.

Somos una tienda de Windows / Cisco.

Configuración interna de NTP:

[Core Router 1 / Cisco 6509]:
mirando a dos servidores NTP externos (en los que el principal no responde a las llamadas NTP)

[Core Router 2]:
Sincronización con Core router 1 (primario), enrutador externo que funciona (secundario)

[Otros dispositivos de red de Cisco]:
Sincronización con el enrutador central 1 (primario), el enrutador central 2 (secundario)

[Controlador (es) de dominio]:
Sincronización con el enrutador Core 1

[Todos los clientes / servidores de Windows]:
sincronización con controladores de dominio

A menos que el cronometraje extremadamente preciso sea de misión crítica para usted, no debería haber un efecto discernible para sus usuarios, aparte de que sus relojes cambien en 2 minutos.

La posible excepción es si declaran que su servidor NTP está "loco" como resultado del gran cambio (que requeriría que reinicie el servicio NTP en los sistemas afectados para obligarlos a sincronizar el reloj, aunque puede hacerlo sin un apagón).

Mientras arreglas esto, aquí hay algunos otros consejos:

• Debe configurar sus sistemas que analizan las fuentes externas de NTP para que analicen varios (4-5) servidores del proyecto de agrupación pública de NTP , preferiblemente los geográficamente apropiados.
  Tener más servidores NTP permite que el algoritmo de selección ignore los que se rompen / se vuelven locos y mantienen su reloj preciso.

• En una configuración como la suya me gustaría señalar Core Router 1y Core Router 2en fuentes de reloj externas (no entre sí).
  Esto le proporciona dos relojes sincronizados de forma independiente que deberían estar a unos pocos ms uno del otro, pero si uno de sus enrutadores se vuelve loco, no puede dañar al otro.

• En una configuración como la suya, apuntaría los controladores de dominio a AMBOS enrutadores centrales (nuevamente para proteger contra una caída).
  Si desea protegerse contra un reloj que se vuelve loco, debe agregar un tercer servidor NTP autorizado (o enumerar uno de sus enrutadores dos veces y esperar que no sea el que se vuelva loco ...)

Los valores predeterminados de dominio para Windows permiten que el tiempo esté apagado +/- 300 segundos antes de que la autenticación deje de funcionar, por lo que estará bien. Aquí hay un artículo bastante exhaustivo sobre el tema , que incluso menciona cómo cambiar su tolerancia al sesgo de tiempo con un GPO de nivel de dominio. Está en Computer Configuration-> Policies-> Windows Settings-> Security Settings-> Account Policies-> Kerberos Policy-> Maximum tolerance for computer clock synchronization.

Dicho esto, debe tener su fuente de tiempo autorizada (que generalmente es el controlador de dominio que tiene la función de emulador PDC en un dominio de Windows) sincronizada con una ntpfuente externa , como pool.ntp.org. Más información de Technet, aquí .

Y en respuesta a la otra respuesta, esto no requiere tiempo de inactividad. Simplemente vuelva a señalar su fuente de tiempo autorizada, y el resto de las computadoras unidas al dominio también se sincronizarán.

EDITAR: dado que @ voretaq7 lo mencionó, debo señalar que solo tenemos un sistema que ve una fuente de tiempo externa, nuestro emulador PDC. Todos los dispositivos, incluido el equipo de red, se sincronizan con él. Consideramos que esta es una mejor disposición, ya que el equipo de red no rechazará la autenticación debido a la distorsión del tiempo, pero las computadoras unidas al dominio que usan Kerberos (que son todas, para nosotros) lo harán. Entonces, en ese sentido, no es particularmente importante tener una hora precisa en nuestro equipo de red, pero sí en nuestros sistemas Windows, doblemente porque también ejecutamos nuestro software de cronometraje para los empleados por hora en un servidor Windows.

Los clientes de Windows realmente no tendrán problemas para iniciar sesión en absoluto. La descripción de la Maximum tolerance for computer clock synchronizationpolítica es bastante imprecisa en estos días.

Un cliente con un reloj muy incorrecto recibirá una respuesta del servidor que establece la distorsión entre sus relojes: la autenticación se realiza normalmente (con el cliente ajustándose para dar cuenta de la aparente distorsión del reloj).

La descripción es correcta sobre una cosa; la política todavía establece efectivamente el cronómetro para los ataques de repetición, pero, en términos de tráfico legítimo, la comunicación es robusta contra grandes desviaciones de reloj.

Consulte este artículo de MS KB para obtener más información.

Es posible que desee considerar buscar otros servidores NTP que no sean su equipo central de Cisco: el tráfico NTP grave genera una alta carga de CPU en el equipo de Cisco que podría ocasionar problemas de red.

Obviamente no puedes programar un pequeño tiempo de inactividad, ¿verdad? Presionaría por un tiempo de inactividad para reiniciar el servicio ntp en todos los servidores afectados. Si eso no es posible, entonces debes esperar un tiempo.

(Iba a hacer de esto un comentario sobre la respuesta de vortaq7, pero creo que merece repetirse por derecho propio, ya que muchas personas cometen este error).

Necesita al menos 3 (preferiblemente 4-6) fuentes de tiempo para que el algoritmo de NTP converja con precisión en el tiempo correcto. Si NTP tiene solo dos fuentes principales y ambas están eliminadas en una cantidad significativa, NTP no tiene forma de saber en cuál confiar.

La mayor ayuda para mí para comprender esto fue el diagrama en la página 9 del plan de Sun "Uso de NTP para controlar y sincronizar los relojes del sistema, parte III: Monitoreo y solución de problemas de NTP". Este documento desapareció de la vista cuando Oracle compró Sun, pero aún puede encontrarlo en Wayback Machine . También hay muchos éxitos en la web si buscas el título.