Um dos servidores NTP externos (o principal - atualmente) que estamos usando como fonte parece não estar respondendo às chamadas NTP. Infelizmente, em nosso roteador principal (Cisco 6509), a funcionalidade NTP não mudou para o servidor externo NTP secundário, como era esperado. Como resultado, nosso roteador principal, que é praticamente a nossa principal fonte NTP interna, está 2 minutos atrasado.

Estou planejando corrigir o problema do roteador externo, tornando a fonte NTP externa a que está funcionando atualmente. Pergunto-me, quanto uma alteração de 2 minutos afetará meus usuários e serviços? Especialmente desde os dias de hoje, dependemos muito da autenticação baseada em certificado.

Somos uma loja do Windows / Cisco.

Configuração interna do NTP:

[Roteador principal 1 / Cisco 6509]:
olhando para dois servidores NTP externos (nos quais o principal não está respondendo a chamadas NTP)

[Roteador Core 2]:
sincronizando com o roteador Core 1 (primário), trabalhando com o roteador externo (secundário)

[Outros dispositivos de rede da Cisco]:
Sincronizando com o roteador principal 1 (primário), roteador principal 2 (secundário)

[Controlador (es) de domínio]:
sincronizando com o roteador Core 1

[Todos os clientes / servidores Windows]:
Sincronizando com controladores de domínio

A menos que a cronometragem extremamente precisa seja de missão crítica para você, não deve haver efeito discernível para seus usuários, além de os relógios mudarem em 2 minutos.

A possível exceção é se eles declararem seu servidor NTP "insano" como resultado de uma grande alteração (o que exigiria que você reiniciasse o serviço NTP nos sistemas afetados para forçá-los a sincronizar o relógio - embora você possa fazer isso sem uma interrupção).

Enquanto você corrige isso, aqui estão alguns outros indicadores:

• Você deve configurar seus sistemas que analisam fontes NTP externas para examinar vários servidores (4-5) do projeto público do conjunto NTP - preferencialmente os geograficamente apropriados.
  Ter mais servidores NTP permite que o algoritmo de seleção ignore aqueles que quebram / enlouquecem e mantém seu relógio preciso.

• Em uma configuração como a sua, eu apontaria Core Router 1e Core Router 2para fontes externas de clock (não uma para a outra).
  Isso fornece dois relógios sincronizados de forma independente, que devem estar a alguns ms um do outro, mas se um de seus roteadores ficar louco, não poderá prejudicar o outro.

• Em uma configuração como a sua, eu apontaria os controladores de domínio para os dois roteadores principais (novamente para proteger contra uma queda).
  Se você deseja se proteger contra um relógio que está ficando louco, adicione um terceiro servidor NTP autoritativo (ou liste um de seus roteadores duas vezes e espero que não seja o que enlouquece ...)

Os padrões de domínio do Windows permitem que o tempo seja desligado +/- 300 segundos antes da autenticação parar de funcionar, portanto você ficará bem. Aqui está um artigo bastante exaustivo sobre o assunto , que até menciona como alterar sua tolerância ao tempo distorcido com um GPO no nível do domínio. Está em Computer Configuration-> Policies-> Windows Settings-> Security Settings-> Account Policies-> Kerberos Policy-> Maximum tolerance for computer clock synchronization.

Dito isso, você deve ter sua fonte de tempo autorizada (que geralmente é o Controlador de Domínio que possui a função de emulador PDC em um domínio do Windows) sincronizada com uma ntpfonte externa , como pool.ntp.org. Mais informações da Technet, aqui .

E, em resposta à outra resposta, isso não requer tempo de inatividade. Basta apontar novamente sua fonte de tempo autorizada e o restante dos computadores ingressados ​​no domínio também se sincronizarão.

EDIT: como @ voretaq7 mencionou, devo ressaltar que apenas um sistema vê uma fonte de tempo externa, nosso emulador PDC. Todos os dispositivos, incluindo o equipamento de rede, são sincronizados. Achamos que esse é um arranjo melhor, pois o equipamento de rede não rejeita a autenticação devido ao desvio do tempo, mas os computadores ingressados ​​no domínio usando o Kerberos (que são todos eles para nós) o farão. Portanto, nesse aspecto, não é particularmente importante ter um tempo preciso em nossos equipamentos de rede, mas sim em nossos sistemas Windows, duplamente porque também executamos nosso software de controle de tempo para funcionários horistas em um servidor Windows.

Na verdade, os clientes Windows não terão nenhum problema ao fazer logon. A descrição da Maximum tolerance for computer clock synchronizationpolítica é bastante imprecisa atualmente.

Um cliente com um relógio gravemente errado receberá uma resposta do servidor estabelecendo a inclinação entre os relógios - a autenticação continuará normalmente (com o cliente se ajustando para dar conta da aparente inclinação do relógio).

A descrição está certa sobre uma coisa; a política ainda efetivamente define o cronômetro para ataques de repetição - mas, em termos de tráfego legítimo, a comunicação é robusta contra grandes desvios do relógio.

Consulte este artigo do MS KB para obter mais informações.

Você pode considerar a possibilidade de procurar outros servidores NTP que não o seu equipamento Cisco principal: o tráfego NTP sério fornece uma carga de CPU alta no equipamento Cisco, o que pode resultar em problemas de rede.

Obviamente você não pode agendar um pequeno tempo de inatividade, não é? Eu pressionaria por um tempo de inatividade para reiniciar o serviço ntp em todos os servidores afetados. Se isso não for possível, você precisará esperar um pouco.

(Eu ia fazer disso um comentário sobre a resposta de vortaq7, mas acho que merece repetir por si só, já que muitas pessoas cometem esse erro.)

Você precisa de pelo menos 3 (de preferência 4-6) fontes de tempo para que o algoritmo do NTP converja com precisão no tempo correto. Se o NTP tiver apenas duas fontes principais e as duas estiverem em quantidade significativa, o NTP não terá como saber em qual confiar.

A maior ajuda para mim no entendimento disso foi o diagrama na página 9 do blueprint da Sun "Usando o NTP para controlar e sincronizar relógios do sistema, parte III: monitoramento e solução de problemas do NTP". Este documento desapareceu de vista quando a Oracle comprou a Sun, mas você ainda pode encontrá-lo na Wayback Machine . Também há muitos hits na web se você procurar pelo título.