Einer der externen NTP-Server (der primäre - derzeit), den wir als Quelle verwenden, scheint nicht auf NTP-Anrufe zu reagieren. Leider hat die NTP-Funktionalität auf unserem Core-Router (Cisco 6509) nicht wie erwartet auf den sekundären externen NTP-Server umgestellt. Infolgedessen ist unser Core-Router, der so ziemlich unsere wichtigste interne NTP-Quelle ist, 2 Minuten zu spät.

Ich plane, das Problem mit dem externen Router zu beheben, indem die externe NTP-Quelle die derzeit funktionierende ist. Ich frage mich, wie stark sich eine Änderung von 2 Minuten auf meine Benutzer und Dienste auswirkt. Insbesondere seit diesen Tagen verlassen wir uns stark auf die zertifikatbasierte Authentifizierung.

Wir sind ein Windows / Cisco-Shop.

Internes NTP-Setup:

[Core Router 1 / Cisco 6509]:
Blick auf zwei externe NTP-Server (von denen der primäre nicht auf NTP-Anrufe reagiert)

[Core Router 2]:
Synchronisierung mit Core Router 1 (primär), funktionierender externer Router (sekundär)

[Andere Cisco-Netzwerkgeräte]:
Synchronisierung mit Core-Router 1 (primär), Core-Router 2 (sekundär)

[Domänencontroller]:
Synchronisierung mit Core Router 1

[Alle Windows-Clients / -Server]:
Synchronisierung mit Domänencontrollern

Sofern für Sie keine äußerst genaue Zeitmessung von entscheidender Bedeutung ist, sollten für Ihre Benutzer keine Auswirkungen erkennbar sein, abgesehen davon, dass sich ihre Uhren um 2 Minuten ändern.

Die mögliche Ausnahme besteht darin, dass Ihr NTP-Server aufgrund der großen Änderung als "verrückt" deklariert wird (was erfordern würde, dass Sie den NTP-Dienst auf den betroffenen Systemen neu starten, um sie zur Synchronisierung der Uhr zu zwingen - obwohl Sie dies ohne tun können ein Ausfall).

Während Sie dies beheben, sind hier einige andere Hinweise:

• Sie sollten Ihre Systeme, die externe NTP-Quellen untersuchen, so konfigurieren, dass mehrere (4-5) Server aus dem öffentlichen NTP-Pool-Projekt angezeigt werden - vorzugsweise geografisch geeignete.
  Mit mehr NTP-Servern kann der Auswahlalgorithmus diejenigen ignorieren, die kaputt gehen / verrückt werden, und Ihre Uhr genau halten.

• In einer Konfiguration , wie das Ihre I - Punkt würde Core Router 1und Core Router 2bei externen Taktquellen (nicht sie).
  Dies gibt Ihnen zwei unabhängig synchronisierte Uhren, die innerhalb weniger ms voneinander entfernt sein sollten. Wenn jedoch einer Ihrer Router verrückt wird, kann der andere nicht verletzt werden.

• In einer Konfiguration wie Ihrer würde ich die Domänencontroller auf BEIDE Core-Router richten (erneut zum Schutz vor einem Ausfall).
  Wenn Sie sich vor einer verrückten Uhr schützen möchten, sollten Sie einen dritten autorisierenden NTP-Server hinzufügen (oder einen Ihrer Router zweimal auflisten und hoffen, dass dieser nicht den Verstand verliert…).

Bei den Standardeinstellungen für Windows kann die Zeit +/- 300 Sekunden ausgeschaltet sein, bevor die Authentifizierung nicht mehr funktioniert. Hier ist ein ziemlich ausführlicher Artikel zu diesem Thema , in dem sogar erwähnt wird, wie Sie Ihre Toleranz für Zeitversatz mit einem Gruppenrichtlinienobjekt auf Domänenebene ändern können. Es ist bei Computer Configuration-> Policies-> Windows Settings-> Security Settings-> Account Policies-> Kerberos Policy-> Maximum tolerance for computer clock synchronization.

Das heißt, Sie sollten Ihre autorisierende Zeitquelle (normalerweise der Domänencontroller, der die PDC-Emulatorrolle in einer Windows-Domäne innehat) mit einer externen ntpQuelle synchronisieren lassen , z pool.ntp.org. Weitere Infos von Technet hier .

Als Antwort auf die andere Antwort sind keine Ausfallzeiten erforderlich. Zeigen Sie einfach erneut auf Ihre maßgebliche Zeitquelle, und der Rest der Computer mit Domänenbeitritt wird ebenfalls synchronisiert.

EDIT: Da @ voretaq7 es erwähnt hat, sollte ich darauf hinweisen, dass wir nur ein System haben, das eine externe Zeitquelle sieht, unseren PDC-Emulator. Alle Geräte, einschließlich der Netzwerkgeräte, werden mit diesen synchronisiert. Wir finden, dass dies eine bessere Anordnung ist, da das Netzwerkgerät die Authentifizierung aufgrund von Zeitverzerrungen nicht ablehnt, Computer mit Domänenbeitritt, die Kerberos verwenden (was für uns alles ist). In dieser Hinsicht ist es nicht besonders wichtig, eine genaue Zeit auf unserem Netzwerkgerät zu haben, aber auf unseren Windows-Systemen, doppelt so, weil wir unsere Zeiterfassungssoftware für die stündlichen Mitarbeiter auch auf einem Windows-Server ausführen.

Die Windows-Clients können sich problemlos anmelden. Die Beschreibung der Maximum tolerance for computer clock synchronizationRichtlinie ist heutzutage ziemlich ungenau.

Ein Client mit einer stark falschen Uhr erhält eine Antwort vom Server, der den Versatz zwischen seinen Uhren festlegt. Die Authentifizierung erfolgt dann normal (wobei sich der Client selbst anpasst, um den scheinbaren Versatz der Uhr zu berücksichtigen).

Die Beschreibung ist in einer Sache richtig; Die Richtlinie legt den Timer für Wiederholungsangriffe immer noch effektiv fest. In Bezug auf legitimen Datenverkehr ist die Kommunikation jedoch robust gegen große Zeitverschiebungen.

Weitere Informationen finden Sie in diesem MS KB-Artikel .

Möglicherweise möchten Sie andere NTP-Server als Ihre Cisco-Kerngeräte in Betracht ziehen: Schwerer NTP-Verkehr führt zu einer hohen CPU-Belastung der Cisco-Geräte, was zu Netzwerkproblemen führen kann.

Offensichtlich können Sie keine kleinen Ausfallzeiten einplanen, oder? Ich würde auf eine Ausfallzeit drängen, um den NTP-Dienst auf allen betroffenen Servern neu zu starten. Wenn dies nicht möglich ist, müssen Sie einige Zeit warten.

(Ich wollte dies zu einem Kommentar zur Antwort von vortaq7 machen, aber ich denke, es verdient, es selbst zu wiederholen, da viele Leute diesen Fehler machen.)

Sie benötigen mindestens 3 (vorzugsweise 4-6) Zeitquellen, damit der NTP-Algorithmus genau zur richtigen Zeit konvergiert. Wenn NTP nur zwei primäre Quellen hat und beide um einen erheblichen Betrag ausfallen, kann NTP nicht wissen, welcher Quelle vertraut werden soll.

Die größte Hilfe für mich war das Diagramm auf Seite 9 des Sun-Entwurfs "Verwenden von NTP zur Steuerung und Synchronisierung von Systemuhren, Teil III: NTP-Überwachung und Fehlerbehebung". Dieses Dokument verschwand aus der Ansicht, als Oracle Sun kaufte, aber Sie können es immer noch auf der Wayback-Maschine finden . Es gibt auch viele Treffer im Web, wenn Sie nach dem Titel suchen.