Substituição da fonte do servidor NTP doente e nova sincronização (com o tempo interno atualmente 2 minutos atrasado)

Question

Um dos servidores NTP externos (o principal - atualmente) que estamos usando como origem parece não estar respondendo a 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 interna de NTP, está 2 minutos atrasado.

Estou planejando corrigir o problema do roteador externo, fazendo com que a fonte externa do NTP seja a que está funcionando atualmente. Estou pensando em quanto uma alteração de 2 minutos afetará meus usuários e serviços. Especialmente desde esses dias, confiamos muito na autenticação baseada em certificados.

Somos uma loja do Windows / Cisco.

Configuração interna do NTP:

[Core Router 1 / Cisco 6509]:
olhando para dois servidores NTP externos (em que o principal não está respondendo a chamadas NTP)

[Core Router 2]:
Sincronizando com o roteador principal 1 (principal), trabalhando o roteador externo (secundário)

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

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

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

    

Answer 1

A menos que a cronometragem extremamente precisa seja essencial para você, não deve haver nenhum efeito perceptível para seus usuários, a não ser que os relógios mudem em 2 minutos.

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

Enquanto você corrige isso, veja alguns outros indicadores:

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

• Em uma configuração como a sua, eu apontaria Core Router 1 e Core Router 2 para fontes de relógio externas (não uma para a outra).
  Isto dá-lhe dois relógios sincronizados de forma independente, que devem estar dentro de uns poucos ms um do outro, mas se um dos seus routers ficar louco, não poderá ferir o outro.

• Em uma configuração como a sua, eu apontaria os controladores de domínio nos BOTH roteadores principais (novamente para proteger contra um dos que estão descendo). Se você quiser proteger contra um relógio que enlouquece, deve adicionar um terceiro servidor NTP autoritativo (ou listar um dos seus roteadores duas vezes e esperar que não seja aquele que perderá a cabeça ...)

Answer 2

Os padrões de domínio para o Windows permitem que o tempo seja desativado em +/- 300 segundos antes que a autenticação pare de funcionar, então você estará bem. Aqui está um artigo bastante exaustivo sobre o assunto , que até menciona como mudar sua tolerância a distorções de tempo com um domínio nível GPO. Está em Computer Configuration - > Policies - > Windows Settings - > Security Settings - > Account Policies - > Kerberos Policy - > Maximum tolerance for computer clock synchronization .

Ditoisso,vocêdeveterasuafontedetempoautoritativa(quenormalmenteéoControladordeDomínioquedetémafunçãodeemuladorPDCemumdomíniodoWindows)sincronizadacomumafontentpexterna,comopool.ntp.org. Mais informações da Technet, aqui .

E em resposta à outra resposta, isso não requer tempo de inatividade. Apenas aponte novamente a sua fonte de tempo autoritativa, e o restante dos computadores associados ao domínio se sincronizarão também.

EDIT: como o @ voretaq7 mencionou, devo salientar que só temos um sistema para ver uma fonte externa de tempo, o nosso emulador PDC. Todos os dispositivos, incluindo o equipamento de rede, são sincronizados. Achamos que esse é um arranjo melhor, já que o equipamento de rede não rejeitará a autenticação devido a distorção de tempo, mas os computadores que fazem parte do 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 no nosso equipamento de rede, mas sim nos nossos sistemas Windows, duplamente porque também executamos nosso software de manutenção do tempo para os funcionários de hora em hora em um servidor Windows.

    

Answer 3

Os clientes do Windows não terão problemas em logar. A descrição da política Maximum tolerance for computer clock synchronization é bastante imprecisa nos dias de hoje.

Um cliente com um relógio gravemente errado receberá uma resposta do servidor estabelecendo a inclinação entre seus relógios - a autenticação prossegue normalmente (com o cliente ajustando-se para compensar a aparente distorção do relógio).

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

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

    

Answer 4

Você pode querer considerar olhar para outro (s) servidor (es) NTP do que seu equipamento cisco principal: o tráfego sério de NTP fornece uma alta carga cpu no equipamento cisco que pode resultar em problemas de rede.

    

Answer 5

Obviamente, você não pode programar um pequeno tempo de inatividade, não é? Eu iria pressionar por um tempo de inatividade para reiniciar o serviço ntp em todos os servidores afetados. Se isso não for possível, então você tem que esperar por algum tempo.

    

Answer 6

(Eu ia fazer um comentário sobre a resposta de vortaq7, mas acho que ela merece ser repetida, já que muitas pessoas cometem esse erro.)

Você precisa de pelo menos 3 (preferencialmente de 4 a 6) fontes de tempo para o algoritmo do NTP convergir com precisão no tempo correto. Se o NTP tiver apenas duas fontes primárias e ambas estiverem fora de uma quantidade significativa, o NTP não terá como saber em qual confiar.

A única grande ajuda para mim no entendimento disso foi o diagrama na página 9 do esquema da Sun "Usando o NTP para controlar e sincronizar os 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 em o Wayback Machine . Há também muitos acessos pela Web, se você pesquisar pelo título.