Zeitsynchronisation in Netzwerken

Nahezu überall spielt das Datum und die Uhrzeit eine wichtige Rolle. Jede Datei hat ein Datum und Uhrzeit der Erstellung und letzten Änderung. E-Mails passieren die Netzwerke und Zeitzonen und protokollieren die Stationen im Kopf der Nachricht mit.

Wenn viele Systeme zusammen arbeiten, dann ist eine korrekte Einstellung der Uhrzeit nicht nur hilfreich sondern teilweise absolut notwendig. Einige System (z.B. NetWare NDS) sind ohne Zeitsynchronisation nicht betriebsfähig, und auch das Active Directory benutzt Zeitstempel, um bei Konflikten bei der Replikation die aktuellsten Daten zu übernehmen. Auch die Autorisierung mittels Kerberos nutzt Gültigkeitszeiten, so dass Computer die mehrere Stunden daneben liegen, Probleme bekommen.

Aber auch wir als Administratoren profitieren von einer synchronen Uhrzeit, da viele Probleme nicht auf ein System bezogen werden können und die Auswertung von Protokolldateien, Ereignisprotokollen (Eventlog) etc. sehr viel einfacher möglich ist, wenn alle Systeme die gleiche Uhrzeit haben.

Auch für Anwender ist die korrekte Uhrzeit notwendig und sinnvoll, damit z.B. das Datum einer Mail korrekt ist und damit Termineinladungen als auch die Erinnerungen daran richtig erfolgen. Sobald über diesen Weg auch Termine abgesprochen werden, muss die Zeitzone mit berücksichtigt werden. Da 9:00 in Berlin eben nicht 9:00 Uhr in London bedeutet.
Daher ist neben einer genauen und synchronen Zeit auch die korrekte Einstellung der Zone notwendig.  Aber was ist eigentlich die "richtige Zeit" ?

Zeitzonen

Ein Wort vorab. Es gibt keine absolute Zeit. Zeit ist immer etwas relatives. Ich möchte gar nicht so weit gehen, wie der Physiker Einstein mit der Relativitätstheorie, dass die Zeit sogar unterschiedlich schnell läuft, abhängig von der eigenen Geschwindigkeit, aber die Erde ist rund und dreht sich und für jeden Menschen steht mittags die Sonne im Zenit. Die Folge davon ist, dass es auf unserer Erde mehrere Zeitzonen gibt. (24 Stück und einige Sonderzonen), welche unterschiedliche Uhrzeiten anzeigen. Demnach ist 12 Uhr Mittag nicht überall auf der Welt 12 Uhr Mittag. So einleuchtend diese Trivialität ist, so tief greifend ist die Bedeutung für die IT-Branche.

Aus diesem Grunde hat sich die Menschheit darauf geeinigt, die Uhrzeit ein Greenwich, England als Basis zu nutzen. Dies ist die Zeitzone 0 oder auch GMT (Greenwich Meantime) bezeichnet. Alle anderen Zeitzonen sind relativ dazu zu sehen. Jede Zeitzone hat dazu eine dreistellige Abkürzung. MET steht für „midle european time“ und ist immer eine Stunde der GMT voraus, Der Faktor beträgt also +0100.

Aus der Uhrzeit 08:00 GMT wird bei der Anzeige auf einem System in Deutschland die Uhrzeit 09:00 MET. Zumindest währen der Winterzeit. Entsprechend gilt dies auch für andere Zeitzonen auf unserer Welt. Neben den 24 Zonen gibt es einige Sonderzonen, z.B.: Inseln und besondere Staaten, die sich eine eigene Zeitzone gegeben haben und um eine halbe Stunde vor oder nachlaufen. Auch sind die Zeitzonen nicht alle gleich verteilt. Einige Zeitzonen sind breiter, um die Ländergrenzen einzuschließen. Nur auf den Ozeanen verlaufen die Zeitzonen nahezu gerade von Pol zu Pol

Sommerzeit und Winterzeit

Weil dies nicht schon genug Aufwand bedeutet, wurden nun bei einigen Zonen auch noch die Sommerzeit eingeführt. Auf Gründen der Energieeinsparung wurde versucht, das Arbeitsleben an die Sonnenscheindauer anzupassen, damit der Bedarf an Energie für Beleuchtung etc. reduziert wird. Daher ändern einige Staaten zweimal im Jahr ihre Uhrzeit. Sie ändern dabei nicht ihre Zeitzone, sondern verstellen nur die Uhr. Das Ergebnis ist, dass unsere Zeitzone in Europa gerne als MET-1MEST bezeichnet wird. Im Sommer verstellen wir unsere Uhr zusätzlich um eine Stunde. Auf dieser Information geht aber nicht hervor, wann diese Umstellung erfolgt. Und je nach Betriebssystem, Version, Patchlevel oder Einstellung des Administrators sind die Werte eventuell falsch. Weiterhin wurde die Umschaltzeit von Sommerzeit auf Winterzeit vor einigen Jahren geändert, so dass die Umschaltzeiten bei älteren Systemen falsch eingetragen sind. Als Quintessenz müssen wir daher darauf achten:

Systeme ohne automatische Umstellung bedürfen der manuellen Anpassung der Uhrzeit als auch der Anpassungsparameter der Zone. Ein Beispiel hierzu ist der Mailserver Mercury.NLM (SMTP-Server als NLM für NetWare), welchem manuell korrigiert werden muss.

Änderung der Zeitzone

Nun könnte man nahe legen, dass eine falsche Zeitzone einfach wieder geändert werden kann und alles ist in Ordnung. Dies stimmte auch für alle Ereignisse, die ab diesem Zeitpunkt eintreffen.
Aber vorherige Ereignisse könnten sich ungeplant verschieben. Immer dann nämlich, wenn die Software nicht die lokale Zeit speichert, sondern die GMT-Zeit intern zum Speichern verwendet. Dies macht z.B. das NTFS-Dateisystem genauso wie Outlook für die Speicherung von Terminen. Wird nun die Zeitzone verändert, verschieben sich die Termine ebenso. Dies ist durchaus gewollt, wenn ein Mitarbeiter um die halbe Welt reist und auf den Notebook die Zeitzone anpasst. Dann ist es normal, dass ein Termin, der in Europa nachmittags stattfindet, im Kalender plötzlich früh morgens angezeigt wird. Schließlich muss ich frühmorgens in den USA nach Deutschland anrufen, da dort schon später Abend ist. Wird die Zeitzone aber anhand einer falschen Einstellung korrigiert, dann ist die Verschiebung der Termine nicht gewünscht. Darauf ist zu achten.

Die Einstellung der Zeitzone ist stark vom Betriebssystem abhängig und dort nachzulesen. In der Regel wird die Zeitzone eingetragen oder aus einer Liste ausgewählt:

Je nach Betriebssystem erfolgt dies automatisch oder manuell.

Achtung: eine korrekte Zeitzone ist auch für den Betrieb mit Outlook sehr wichtig

Die korrekte Uhrzeit

Nachdem wir nun die Zeitzone der Systeme korrekt gesetzt haben, können wir sicher sein, dass alle Systeme die gleiche relative Uhrzeit nutzen. Nun fehlt noch ein Weg, allen Systemen die "richtige" Uhrzeit zu gegeben, denn gegen eine falsch laufende Uhr helfen auch korrekte Zeitzonen nicht. Daher müssen wir uns erst einmal die Uhrzeit besorgen. Dazu gibt es mehrere Quellen:

Gerade der Bezug der Zeit über Internet ist heute hinreichend genau und ohne weitere Kosten möglich, da viele Provider für ihre Kunden entsprechende Zeitserver anbieten. Selbst wenn der Provider keinen "nahen" Server anbietet, gibt es jede Menge frei erreichbare Server. Einige Betreiber wünschen sich vorab eine Information, wer ihren Server hier denn abfragt.

Über diesen Weg sollte auf jeden Fall ihr PDC-Emulator der Root-Domäne eine korrekte Uhrzeit erhalten. Auf dem Bild sehen Sie aber schon, dass auch andere DCs in der gleichen Domäne, Mitgliedsserver und andere DCS von anderen Domänen in diesem Forest ihre Uhrzeit beziehen. Auch die erfolgt über das Protokoll NTP.

Verteilen der Zeit - NTP

Nun geht es darum, diese Zeit allen Systemen im LAN bereitzustellen. Auch wenn viele Hersteller eigene Protokolle und Techniken entwickelt haben  (Angefangen bei der Integration in den NetWare Client bis zum Aufruf von "NET TIME \\server /SET /YES" per AT-Jobs) so gibt es heute nur noch eine sinnvolle Möglichkeit, die Uhrzeit im Netzwerk zu verteilen:

Das Network Time Protokoll (NTP) bzw. die vereinfachte Version SNTP  (Simple NTP) erlaubt es, über wenige IP-Pakete (genaugenommen Protokoll UDP Port 123) die Uhrzeit von einem NTP-Server zu beziehen. Bleiben also nur noch die Fragen:

Infrastruktur

Inwieweit sie mehrere Zeitserver an verschiedenen Standorten ihres Unternehmens bereitstellen um die Belastung des WAN zu reduzieren und eine Fehlerredundanz und Lastverteilung zu erreichen, kann ich ihnen in wenigen Sätzen nicht beschreiben. Allerdings sollten Sie ab einer bestimmten Größe auch mehrere NTP-Server zentral bereitstellen, die z.B. per DNS mit dem gleichen Namen erreichbar sind. (Round Robin). Auf der anderen Seite bedeutet ein Client, der alle 6 Stunden seine Zeit abfragt, gerate mal 128 Byte Netzwerklast, so dass sie auch sehr viele Clients über WAN anbinden können. Die Belastung durch Broadcasts, WINS, DNS-Abfragen, Routingprotokolle etc. ist um ein vielfaches höher. Daher eher weniger Server, die dann aber kontrolliert werden anstelle vieler lokaler Server, die aufwändiger zu kontrollieren sind.

Achtung bei der Einführung eines Active Directory. Mit dem AD kommt automatisch eine funktionierende Zeitsynchronisation mit, bei der Domain Controller als NTP Server dienen, die sich ihre Zeit vom PDC Emulator holen welche ihre Zeit von der übergeordneten Domäne bzw. dem Forrest Master holen. Aber dies ist alles konfigurierbar.

Server

Lesen Sie die Dokumentationen zu ihrem Server und sie werden feststellen, dass die meisten Server heute sowohl als NTP Client als auch NTP-Server dienen können. Dies trifft auf die aktuellen Versionen von Windows 2000 ebenso zu wie auf NetWare 5.x und eigentlich alle Derivate von UNIX und LINUX. Ältere Versionen wie NetWare 3.x 4.x und Windows NT 4.0 können mit Drittsoftware (kostenfrei) NTP-tauglich gemacht werden, z.B. mit dem W32TIME-Dienst für Windows NT 4.0.

Client

Bei den Clients sieht es etwas anders aus. Clients müssen nur die Uhrzeit von einem vertrauenswürdigen Server beziehen. Dies muss nicht unbedingt per NTP geschehen. Verschiedene Systeme haben eigene Wege hierzu implementiert. So wird in einer Umgebung mit NetWare Client die Uhrzeit automatisch an die Zeit des Servers angepasst. Gerade mit Windows NT haben aber normale Anwender überhaupt nicht mehr das Recht, die Uhrzeit des Computers zu ändern, so dass alle Hilfsprogramme im Anmeldeskript fehlt schlagen. Aber Anmeldeskripte sind auch keine Hilfe, da sie nicht immer und regelmäßig ausgeführt werden. Daher muss die Uhrzeitkorrektur Bestandteil des Kernsystems werden und unabhängig von Anwendern sein.

Hier möchte ich die Abhandlung der Thematik Zeitsynchronisation beenden. Ich hoffe die ein oder anderen Hinweise und Tipps gegeben zu haben. Nutzen Sie auch die Linksliste für weitergehende Informationen . Eine umfassendere Aufarbeitung des Themas unter Berücksichtigung anderer Betriebssysteme finden Sie hier: Netzwerkzeitsynchronisation

NTP Einstellungen unter Windows 2000 und 2003

Normalerweise holen Sich sowohl Windows 2000, WindowsXP und Windows 2003 ihre Uhrzeit anhand des Active Directory vom "richtigen" Server. Aber der PDC-Emulator der obersten Domäne muss trotzdem die Uhrzeit irgendwo her bekommen. Selbst wenn eine Atomuhr die Systemzeit setzt, muss Windows wissen, dass "seine" Zeit richtig ist, damit der Server diese an Clients weiter gibt. Meist wird aber das "Internet" per NTP befragt. Auch das ist zu konfigurieren. Dazu dient der W32TIME-Service

Bei Windows 2000 können Sie einfach mit NET TIME die IP-Adresse des Servers angeben. Führen Sie in einer DOS-Box dazu folgende Befehle aus:

net stop w32time
net time /setsntp:xxx.xxx.xxx.xxx
net start w32time
w32tm.exe /once

Bei Windows 2003 hat sich der Aufruf der Konfiguration geändert.

w32tm /config /syncfromflags:manual /manualpeerlist:time.firma.tld /update /reliable:YES

Diese Zeile setzt den Zeitserver auf "Manuelles Update" von "time.firma.tld" und gibt sich dann als "zuverlässiger" Zeitserver aus und holt sich sofort die Zeit.

Seit Windows 2003 ist es auch möglich, ein Debuglog für den W32TIME-Dienst zu aktivieren. Speichern Sie einfach folgende Zeilen als REG-Datei und importieren Sie diese

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
"FileLogName"="c:\\temp\\ntp.log"
"FileLogSize"=dword:01000000
"FileLogEntries"="0-116"

Vergessen Sie am Ende nicht, das Diagnoseprotokoll wieder abzuschalten. Bei Windows 2000 können Sie die "w32tm /once" eine interaktive Verbindung zum NTP-Server in der Konsole beobachten. Auch im Systemeventlog hinterlässt W32TIME entsprechende Meldungen, wenn ein Fehler auftritt.

Autoritativer Zeitserver

Wenn es nun keinem ihrer Domänencontroller möglich ist, eine Zeit von einer vertrauenswürdigen NTP-Quelle zu bekommen, dann sollten Sie natürlich einen DC zur maßgeblich Zeitquelle deklarieren und dort sicherstellen, dass dessen Uhrzeit möglichst genau geht. Dies könnte dann eine Hardwareuhr (DCF77 o.ä.) sein, die einfach die lokale Uhr immer wieder korrigiert.

Um einen Windows Server nun zu einer "Referenz" zu deklarieren, müssen Sie per Regedit zwei Schlüssel setzen. Speichern Sie einfach diesen text z.B. als "W32HWTime.reg und importieren diesen auf dem PDC-Emulator der Stammdomäne

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
"LocalNTP"=dword:00000001
"ReliableTimeSource"=dword:00000001

Danach müssen Sie den Windows Zeitdienst einmal durchstarten (net stop w32time && net start w32time). Sorgen Sie dann noch dafür, dass alle Clients und anderen Server die Zeit neu holen (z.B.: durch Eingabe von "w32tm -s" und kontrollieren Sie das Eventlog.

Andere Weg der Zeitsynchronisation

Für den Fall, dass Sie keine Zugriffe per NTP nach außen zulassen oder der Provider dies, warum auch immer, sperrt, können Sie immer noch eine eigene ATOM-Uhr einsetzen. Sie können aber auch HTTP-Anfragen nutzen, da die meisten Webserver mit ihrer Antwort auch eine "Zeit" mit liefern. Hier ein Mitschnitt einer Abfrage der Startseite von Google und die Antwort.

Im HTTP-Response steht hier auch eine Uhrzeit samt Zeitzone drin. Natürlich muss man noch etwas Grips rein stecken und z.B. die Laufzeit eines großen HTTP-Pakets gegenüber einem kleinen UDP-Paket relativieren. Auch könnten Provider Antworten "Cachen", so dass man auch dies prüfen muss. Und natürlich sollte der angefragte Webserver auch einen halbwegs aktuelle Zeit bereit stellen. Der Administrator erwartet schließlich nicht, dass sein Webserver als "Zeitquelle" genutzt wird. Windows selbst unterstützt diese Art der "Zeitquelle" nicht.

Weiterhin gibt es spezielle Webseiten, die auf einen HTTP-Get einen Zeitstempel zurückliefern wie z.B. ebay und http://www.uhrzeit.org/sys/synchro.php, wobei ich keine Liste von Webseiten und deren Qualität der Zeit habe. Entsprechende Zusatzsoftware kann solche Server abfragen wie z.B.

Weitere Links

Keywords: Timesync NTP