Uno dei server NTP esterni (quello primario - attualmente) che stiamo utilizzando come sorgente sembra non rispondere alle chiamate NTP. Sfortunatamente, sul nostro router principale (Cisco 6509), la funzionalità NTP non è passata al server esterno NTP secondario come previsto. Di conseguenza, il nostro router principale, che è praticamente la nostra principale fonte NTP interna, è in ritardo di 2 minuti.

Sto programmando di risolvere il problema del router esterno facendo in modo che l'origine NTP esterna sia quella attualmente funzionante. Mi chiedo, quanto influirà un cambio di 2 minuti sui miei utenti e servizi? Specialmente da questi giorni, facciamo molto affidamento sull'autenticazione basata su certificati.

Siamo un negozio Windows / Cisco.

Configurazione NTP interna:

[Core Router 1 / Cisco 6509]:
ricerca di due server NTP esterni (in cui quello principale non risponde alle chiamate NTP)

[Router principale 2]:
sincronizzazione con il router principale 1 (primario), router esterno funzionante (secondario)

[Altri dispositivi di rete Cisco]:
sincronizzazione con il router principale 1 (primario), il router principale 2 (secondario)

[Controller di dominio]:
sincronizzazione con il router principale 1

[Tutti i client / server Windows]:
sincronizzazione con controller di dominio

A meno che un cronometraggio estremamente preciso non sia critico per te, non dovrebbero esserci effetti visibili per i tuoi utenti, a parte il fatto che i loro orologi cambiano di 2 minuti.

La possibile eccezione è se dichiarano che il tuo server NTP è "folle" a causa della grande modifica (che richiederebbe di riavviare il servizio NTP sui sistemi interessati per costringerli a sincronizzare l'orologio, anche se puoi farlo senza un'interruzione).

Mentre risolvi questo problema, ecco alcuni altri suggerimenti:

• Dovresti configurare i tuoi sistemi che guardano a fonti NTP esterne per guardare diversi (4-5) server dal progetto del pool NTP pubblico - preferibilmente quelli geograficamente appropriati.
  Avere più server NTP consente all'algoritmo di selezione di ignorare quelli che si rompono / impazziscono e mantengono il tuo orologio preciso.

• In una configurazione come la tua indicherei Core Router 1e Core Router 2verso sorgenti di clock esterne (non tra loro).
  Questo ti dà due orologi sincronizzati in modo indipendente che dovrebbero trovarsi a pochi ms l'uno dall'altro, ma se uno dei tuoi router diventa pazzo non può danneggiare l'altro.

• In una configurazione come la tua, indirizzerei i controller di dominio su ENTRAMBI i router principali (ancora una volta per proteggermi da uno che non funziona).
  Se vuoi proteggerti da un orologio impazzito, dovresti aggiungere un terzo server NTP autorevole (o elencare due volte uno dei tuoi router e sperare che non sia quello a perdere la testa ...)

I valori predefiniti del dominio per Windows consentono di disattivare il tempo +/- 300 secondi prima che l'autenticazione smetta di funzionare, quindi andrà tutto bene. Ecco un articolo abbastanza esaustivo sull'argomento , che menziona anche come modificare la tolleranza per il disallineamento temporale con un oggetto Criteri di gruppo a livello di dominio. È a Computer Configuration-> Policies-> Windows Settings-> Security Settings-> Account Policies-> Kerberos Policy-> Maximum tolerance for computer clock synchronization.

Detto questo, dovresti avere la tua fonte di tempo autorevole (che di solito è il controller di dominio che detiene il ruolo di emulatore PDC in un dominio Windows) sincronizzare con una ntpfonte esterna , come pool.ntp.org. Maggiori informazioni da Technet, qui .

E in risposta all'altra risposta, ciò non richiede tempi di inattività. Reindirizza la tua fonte di tempo autorevole e anche il resto dei computer aggiunti al dominio si sincronizzeranno da soli.

EDIT: poiché @ voretaq7 lo ha menzionato, dovrei sottolineare che abbiamo solo un sistema che vede una fonte di tempo esterna, il nostro emulatore PDC. Tutti i dispositivi, incluso il dispositivo di rete, si sincronizzano con esso. Riteniamo che questo sia un accordo migliore, poiché l'attrezzatura di rete non rifiuterà l'autenticazione a causa del disallineamento temporale, ma i computer collegati al dominio che usano Kerberos (che è tutto loro, per noi) lo faranno. Quindi, a tale proposito, non è particolarmente importante avere un tempo preciso sulla nostra attrezzatura di rete, ma lo è anche sui nostri sistemi Windows, doppiamente perché eseguiamo il nostro software di temporizzazione anche per i dipendenti orari su un server Windows.

I client Windows in realtà non avranno alcun problema ad accedere. La descrizione della Maximum tolerance for computer clock synchronizationpolitica è abbastanza inesatta in questi giorni.

Un client con un orologio gravemente sbagliato riceverà una risposta dal server che stabilisce l'inclinazione tra i loro orologi - l'autenticazione procede quindi normalmente (con il client che si adegua per tenere conto dell'inclinazione apparente dell'orologio).

La descrizione è corretta su una cosa; la politica imposta ancora in modo efficace il timer per gli attacchi replay - ma, in termini di traffico legittimo, la comunicazione è robusta contro grandi deviazioni dell'orologio.

Vedi questo articolo di MS KB per ulteriori informazioni.

Potresti prendere in considerazione la possibilità di esaminare altri server NTP diversi dalle tue apparecchiature Cisco principali: un traffico NTP serio comporta un carico elevato della CPU sull'apparecchiatura Cisco che potrebbe causare problemi di rete.

Ovviamente non puoi programmare un piccolo tempo di inattività, vero? Vorrei spingere per un tempo di inattività al fine di riavviare il servizio NTTP su tutti i server interessati. Se ciò non è possibile, devi aspettare un po 'di tempo.

(Stavo per fare questo un commento sulla risposta di vortaq7, ma penso che meriti di essere ripetuto di per sé, dal momento che molte persone commettono questo errore.)

Sono necessarie almeno 3 (preferibilmente 4-6) fonti di tempo affinché l'algoritmo di NTP converga con precisione nel tempo corretto. Se NTP ha solo due fonti primarie e sono entrambe fuori di una quantità significativa, NTP non ha modo di sapere quale fidarsi.

Il più grande aiuto per me nella comprensione di questo è stato il diagramma a pagina 9 del progetto Sun "Uso di NTP per controllare e sincronizzare gli orologi di sistema, parte III: monitoraggio e risoluzione dei problemi di NTP". Questo documento è scomparso alla vista quando Oracle ha acquistato Sun, ma è ancora possibile trovarlo sulla Wayback Machine . Ci sono anche molti successi sul Web se cerchi il titolo.