Tipps & Tricks zur Netzwerk- und Systemzeit

Zeiteinstellung in PCs, VMs und Servern

| Autor / Redakteur: Frank-Michael Schlede, Thomas Bär / Andreas Donner

Falsche bzw. unterschiedliche Zeitstände von PCs, VMs und Servern können viel Ärger machen!
Falsche bzw. unterschiedliche Zeitstände von PCs, VMs und Servern können viel Ärger machen! (Bild: gemeinfrei - Pixabay - jarmoluk / CC0)

Seit Dekaden verfügen Computersysteme über eine eingebaute Uhr, die mehr oder minder genau arbeitet. Falsche Zeiteinstellung können in Fehlverhalten resultieren und nicht selten ist die korrekte Uhrzeit wichtig. Wir liefern wichtige Hintergrundinfos und Tipps.

Üblicherweise ist das Problem an der Zeit, dass es davon einfach zu wenig gibt, so die meisten Menschen. Alles wohl eher eine Frage der Perspektive – mit Blick auf die Lebenserwartung einer Eintagsfliege oder den vielen Jahren bei einer Schildkröte. Was wir vom Leben erwarten oder ob wir dafür genug Zeit haben, soll hier jedoch nicht das Thema sein – eher die nicht richtige Zeit und ihre Auswirkung auf Computerprozesse.

Falsche Zeiteinstellungen gelten in der IT als Problemfall und einige Systeme reagieren mit Fehlfunktionen, sofern die Zeitwerte nicht richtig sind. Das für IT-Profis bekannteste Beispiel dürfte die Unfähigkeit von Windows-Computern sein, sich mit einer Domäne zu verbinden, wenn die Differenz der Zeiteinstellungen zu hoch ist.

Auf den ersten Blick mag ein solches Verhalten der Server kleinlich anmuten – ein paar Gedanken weiter offenbart sich jedoch die Herausforderung für Entwickler. Sobald es „gültig von“ und „gültig bis“-Werte gibt, Verschlüsselungsalgorithmen auf gemeinsamen Zeitwerten basieren oder Abläufe halbwegs synchron in einem Protokoll erscheinen müssen, ist es klar, warum es eine Grenze für eine zulässige Zeitabweichung gibt.

Symptom: Browserfehler

Aber, wie steht es denn in einem Praxischeck mit diesen gern zitierten, zeitlichen Katastrophen? Wird die Uhrzeit auf einem Computer verstellt, beispielsweise einige Jahre in die Zukunft, ist ein normales Surfen mit einem Webbrowser nur noch erschwert möglich. Traditionelle http-Verbindungen sind, was die Zeiteinstellungen angeht, vollkommen ungefährdet – sie funktionieren auch dann, wenn der Rechner glaubt, rund 50 Jahre in der Zukunft oder 20 Jahre in der Vergangenheit zu arbeiten.

Bei verschlüsselten https-Verbindungen, wie sie zunehmend als Standard gelten, ist das anders. Mozillas Firefox zeigt bei einem Google-Aufruf den symbolisierten Zollbeamten auf gelben Grund und gibt an, dass dieser Verbindung nicht getraut werden könne. Denn dem Verschlüsselungsalgorithmus ist die Uhrzeit und das Datum zwar an sich auch egal, nicht aber dem genutzten Zertifikat, welches für einen zeitlichen Raum die Identität eines Serversystems und der damit verbundenen Institution sicherstellt. Da das Zertifikat im Jahr 2059 nicht mehr gilt, ist auch die Verbindung möglicherweise unsicher, da nicht sichergestellt werden kann, ob Google auch noch Google ist. Ein Computer mit einer komplett verstellten Uhrzeit, zum Beispiel aufgrund einer leeren Uhrpufferbatterie, reagiert daher mit einem Fehlverhalten beim Browsing.

Symptom: Authentifizierungsfehler

Vielerorts hören IT-Profis und Administratoren immer wieder die Geschichte von Problemen, die im Zusammenhang mit verstellten Computeruhren auf Windows-Systemen einhergehen. Was bei Serversystemen sicherlich zu einem ausgewachsenen Problem mutieren mag, ist bei einer ganz regulären Client-Workstation jedoch eher unerheblich. Auch mit einer um mehrere Tage verstellten Zeiteinstellung ist eine Anmeldung problemlos möglich. Nach einiger Zeit justiert sich die Uhrzeit ohnehin, da die Einstellung für gewöhnlich von einem Domänencontroller mit aktiver PDC-Emulator-Rolle (PDC = Primary Domain Controller) an seine Clients geschickt wird.

In einem AD synchronisieren alle Arbeitsstationen und Mitglied-Server ihre Zeit mit den Domänencontrollern. Alle DCs einer Domäne synchronisieren wiederum ihre Zeit mit dem PDC-Emulator. Gibt es mehrere Strukturen und untergeordnete Domänen, synchronisieren die PDC-Emulatoren der einzelnen Domänen ihre Zeit mit dem PDC-Emulator der jeweils übergeordneten Domäne. Der oberste Zeitserver in einer Gesamtstruktur ist somit der PDC-Emulator der Stamm- bzw. Root-Domäne.

Die Zeitsynchronisation in einem AD ist sehr wichtig für die Kommunikation und die Sicherheit – insbesondere für Exchange Server. In einem AD wird in Sachen Authentifizierung hauptsächlich mit Kerberos gearbeitet und dieses Protokoll ist von der Uhrzeit abhängig. Sobald die Uhren mehr als fünf Minuten voneinander abweichen, kann es zu Authentifizierungsproblemen kommen. Aus diesem Grunde ist die Rolle des PDC-Emulators sehr wichtig.

Symptom: Immer eine Stunde voraus

Besonders Administratoren in VMware ESX-Testumgebungen dürften das hartnäckige Problem zur Genüge kennen. Wer seine virtualisierten Maschinen immer wieder herunterfährt oder anhält, um den Hostserver auszuschalten, hat nicht selten einen Domänencontroller (mit PDC-Betriebsmaster-Rolle), der seiner Zeit stets einer Stunde voraus ist. Unglücklicherweise hat der Administrator nur selten die Möglichkeit, die Uhrzeit auf dem Hostserver richtig einzustellen, es sei denn, eine ILO-/DRAC-/RSA-Karte erlaubt einen Fernzugriff oder es ist ein Zugriff per KVM möglich.

Eine möglicherweise bessere Variante der Problemlösung ist die Verwendung eines NTP-Servers (Network Time Protocol) über das Internet, anstelle der Ableitung der Systemuhrzeit über den Hostserver. Mit wenigen Befehlen ist ein Domänencontroller damit wieder in der richtigen zeitlichen „Spur“, hierzu ist lediglich die Eingabeaufforderung mit Administrationsrechten zu öffnen:

Mit dem ersten Befehl >net stop w32time< wird der Windows-Zeitgeberdienst beendet. Es folgt mit

>w32tm /config /syncfromflags:manual /manualpeerlist:"de.pool.ntp.org"< der Verweis auf die deutschen NTP-Poolserver. Möglicherweise ist die Eingabe ohne Hochkommata erforderlich – da sind sich die Windows-Versionen nicht immer so einig.

Mit dem nachfolgenden Kommando stellt der Administrator sicher, dass die soeben definierte Quelle als „verlässlich“ gilt: >w32tm /config /reliable:yes<

Die klassische Empfehlung von Microsoft besagt, dass nur der PDC-Emulator in der Root-Domäne im Forrest, angeschlossen an eine externe NTP-Zeitquelle, eine verlässliche Zeitquelle darstellen soll. Ob die Zeit dann tatsächlich genau stimmt, ist wiederum nicht so ganz so wichtig – Hauptsache die Systeme innerhalb der Domäne sind sich hinsichtlich der Zeit einig.

Abgeschlossen wird die Synchronisation auf eine einheitliche Zeit mit dem Befehl >net start w32time<.

Wer sich detailliert mit dem Zeitdienst unter Microsoft Windows auseinandersetzen möchte, dem sei ein Artikel im Technet des Herstellers ans Herz gelegt.

Symptom: Linux-Zeitfehler mit Azure

Auch außerhalb der Windows-Welt kann es zu Zeitproblemen kommen. Ein beherzter Post eines Admins aus dem Jahr 2015 mit dem dringlichen Hinweis „Be Sociable, Share!“ soll hier eine weitere Nennung erhalten. Im Zusammenspiel mit Linux und Azure kann es zu Fehlern bei der Zeiteinstellung kommen, da viele Administratoren über ältere Hinweise stolpern, dass Microsoft Azure kein UDP unterstützen würde, dies aber seit geraumer Zeit tut. Insgesamt empfiehlt sich ein Blick in den Lösungsansatz des Blogs „Hard Answers“, sofern es mit der Zeitsynchronisation von Linux-VMs in Microsoft Hypervisoren nicht passt.

Sicherstellung: Woher kommt die Zeiteinstellung bei VMware?

Virtuelle Windows-Computer unterscheiden sich nicht sonderlich von physikalischen Maschinen – auch nicht bezüglich ihre Anforderungen, was die Zeiteinstellungen angeht. In einer virtualisierten Umgebung mit ESX/vSphere bekommen alle beteiligten Host-Systeme nicht automatisch die Zeiteinstellungen aus dem Active Directory, nur weil der vCenter-Server auf einem Domänenmitgliedsserver läuft. Üblicherweise gilt es, die „Zeitsynchronisation zwischen virtuellen Maschinen und dem ESX-Server“ unter Sonstiges in den Eigenschaften der VMware Tools zu aktivierten.

Im Zweifelsfall empfiehlt es sich zu prüfen, woher die Zeiteinstellungen kommen. Klicken Sie hierzu im vSphere Web Client auf „Hosts und Cluster“, wählen Sie in der linken Baumansicht den gewünschten ESX-Host, wählen Sie das Register „Verwalten“ und unter „System“ den Eintrag „Uhrzeitkonfiguration“. Hier sollte sich im Idealfall ein NTP-Server der Firma als Eintrag finden und der NTP-Dienststatus sollte „Gestartet“ sein. Wer auf externe Zeitquellen vertraut, kann diese angeben, am besten als Pool-Adressen.

Symptom: Warum bin ich (zeittechnisch) in Monrovia?

Das Problem, dass sich Benutzer angeblich in der Zeitzone UTC Monrovia, Reykjavik befinden, kann beim Einsatz der Outlook Web App auftreten, wenn der Anwender bei der ersten Anmeldung nicht die richtige Zeitzone ausgewählt hat. Üblicherweise sollte der Eintrag passen – doch Administratoren haben keine Möglichkeit, eine Vorbelegung durchzuführen. Die einzige Möglichkeit für den Benutzer besteht nun darin, die richtige Zeitzone in OWA selbst einzustellen:

  • Anmeldung per Outlook Web App
  • Klick oben rechts auf das Zahnrad-Symbol für Einstellungen
  • Im Navigationsbereich auf „Regionale“ klicken
  • Die richtige Zeitzone auswählen
  • Speichern klicken

Symptom: Office 365 immer einige Stunden hintendran!

Microsoft Office 365 verspricht das Komfortpaket beim Zusammenspiel in kleinen bis großen Firmen. Endlich alle Funktionen, die es sonst nur im lokalen Netzwerk gibt, auch über das Internet. Wer sein Office 365 bei Microsoft anmietet, wird aber möglicherweise bei der Verwendung von SharePoint auf das Phänomen stoßen, dass die Zeit der lokal synchronisierten Onedrive-Dateien, die sich faktisch auf dem SharePoint befinden, bezüglich des Zeitstempels in einer anderen Zeitzone befinden. Über das Web ist der Benutzer zeittechnisch in Redmond beheimatet, auf dem eigenen PC schätzungsweise in der Zeitzone von Berlin. Letztendlich findet der motivierte Administrator mindestens drei Stellen zur Änderung der Zeitzoneneinstellungen, ohne dass sich was ändert.

Um an die gewünschte Einstellung zu gelangen melden Sie sich am Office 365 Portal an, wechseln Sie in den Abschnitt „SharePoint“ und öffnen Sie die gewünschte Seite. Korrigieren Sie die URL im Browser bis zu Ihrer Seite, beispielsweise:

.test.sharepoint.com/sites/wir/Freigegebene%20Dokumente/Forms/AllItems.aspx

in

.test.sharepoint.com/sites/wir/_layouts/15/regionalsetng.aspx?noredirect=true

Nun sehen Sie das Menü für die Website-Einstellung mit Landes/Regions-Einstellungen. Üblicherweise würde der Benutzer über einen Klick auf das Zahnradsymbol oben rechts im Browserfenster an eben diese Einstellung gelangen. Bis Ende 2016 funktionierte das bei Office 365 jedoch nicht, daher dieser Quereinstieg über eine „hidden url“.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44468971 / Tipps & Tricks)