NTP: Warum die Zeit im Netzwerk so wichtig ist

Zeit ist ein hohes Gut. Nirgends ist eine exakte Uhrzeit aber so wichtig wie im internen LAN eines Netzwerks. Schon geringe Abweichungen führen zu vielfältigen Fehlfunktionen, deren Ursache nur schwer zu finden ist. Ein klarer Fall für das Monitoring.

Das NTP-Setup

Der Ansatz ist eigentlich ganz einfach umzusetzen. In einem Windows-Netzwerk ist der Domain-Controller für die Uhrzeit zuständig. Gibt es mehrere davon, so bestimmt die Rollenverteilung, wer der Herr der Uhrzeit ist. Der DC mit der PDC-Rolle versorgt alle anderen Server und sämtliche Clients mit der Uhrzeit. Der Domain-Controller holt sich am einfachsten die aktuelle Zeit von einem Time-Server aus dem Internet (Funkuhren spielen heute nur noch eine untergeordnete Rolle).

Die Zeitdifferenz und deren Folgen

Im Netzwerk selbst kommt es nicht so sehr auf die exakte Uhrzeit an. Die zeitliche Differenz der einzelnen Systemuhren ist der kritische Punkt. Eine falsch gehende Uhr am PC oder Server mag ärgerlich sein – vor allem, wenn die Abweichung mehr als nur ein paar Minuten beträgt. Unterscheidet sich die Uhrzeit zweier Serversysteme auch nur um wenige Minuten, so treten die eigenartigsten Probleme auf: Dienste des Servers verweigern den Start, Server verweigern eine Anmeldung, usw.

Die Ursache liegt in der Nutzung des Zeitstempels im Rahmen der Authentifizierung. Vor allem das genutzte Kerberos-Protokoll nimmt hier bereits kleinste Abweichungen krumm. Warum? Die Identitätsprüfung erfolgt im Rahmen eines Dialogs („Ich hätte gerne…“, „Wer bist denn Du?“). Und darin spielt der eingeschlossene Zeitstempel eine wichtige Rolle. Anfragen, die nicht „In-Time“ sind, werden einfach abgelehnt. Egal, ob die Daten zur Authentifizierung stimmen oder nicht.

Kein Vertrauen

Weicht die Uhrzeit zweier Systeme zu stark voneinander ab, so scheitert die Anmeldung. Auch wenn sich hier ein Super-Admin um einen Zugang bemüht. Die zurückgegebene Fehlermeldung weist nicht sofort auf diese Ursache hin.

Da weigert sich schon mal der Exchange-Store seine Datenbank zu starten. Oder die Verwaltungskonsole des Mailservers zeigt anstatt der Infrastruktur nur eine nichtssagende Fehlermeldung. Selbst die Anmeldung an der Serverkonsole wird verweigert und bringt Falten auf die Stirn des Administrators.

Troubleshooting NTP

Die fehlerfreie Konfiguration des Network Time Protokolls ist nicht immer einfach. Vor allem bei einem Umzug der Rolle des Zeitservers von einem (defekten) System auf einen neuen Server kann es rasch zu Fehlkonfigurationen kommen. Da sich die Zeitverwaltung abhängig vom eingesetzten Betriebssystem stark unterscheidet, gibt es auch in den vielfältigen Foren eine Vielzahl an falschen Informationen. Hier hilft nur eines: Ab in die Tiefen der Registry und der Kommandozeile (W32tm.exe) mit vielen Parametern.

Wissen, wann die Zeit keine Wunden heilt

Rechtzeitig informiert zu sein, wann etwas mit der Uhrzeit im Netzwerk nicht stimmt, kann viel unnötige Arbeit ersparen. Sei es, dass der Domain-Controller keine Uhrzeit aus dem Internet erhält, die Abweichung viel zu hoch ist oder dieser sich weigert eine Uhrzeit an die anfragenden Systeme im LAN zu verteilen: Wenn der Administrator darüber zeitnah in Kenntnis gesetzt wird, können Ausfälle von Diensten rechtzeitig abgewendet werden.

NTP-Monitoring

Hier hilft nur die Überwachung der entsprechenden Dienste und Services mithilfe eines Monitoring-Systems. Dieses eskaliert rechtzeitig: sowohl bei einer (individuell definierten) Überschreitung der Zeitabweichung zwischen dem lokalen und dem Internet-Zeitdienst wie auch bei einem vollständigen Ausfall der Zeitverwaltung. Ausfall bedeutet dabei nicht, dass der Windows-Dienst selbst nicht funktioniert, sondern die Weigerung eine verlässliche Uhrzeit an die Clients zu verteilen. Im Windows-Protokoll findet sich dabei nur eine Warnung, dass die Uhrzeit aufgrund einer zu großen Differenz nicht als vertrauenswürdig eingestuft wird. Der Dienst läuft also ohne Probleme – die wichtige Funktion für den gesamten Netzwerkbetrieb bleibt aber aus.