Timeservice für Windows-Netzwerke

ActiveDirectory basiert auf Kerberos. Sobald die Uhren zweier Systeme mehr als 5 Minuten weit auseinander laufen funktioniert so manches nicht mehr – teilweise auch gar nichts.

ActiveDirectory synchronisiert über den internen Windows-Zeitdienst w32time alle Domain-Controller mit dem PDC-Emulator; anschließend synchronisieren  PCs und Member-Server mit ihren jeweiligen Logon-Domain-Controllern.

Kommt ein Domain-Forest zum Einsatz, funktioniert das innerhalb aller Domains identisch – domainübergreifend synchronisieren die PDC-Emulatoren der Sub-Domains jeweils mit den Domain-Controllern ihrer übergeordneten Domain.

Die scheinbar komplizierten Regeln veranschaulicht diese schematische Darstellung aus dem Microsoft Technet:

Windows-Timeservice (Quelle: microsoft.com)

Für die interne technische Funktionalität ist also alles geregelt – aber wenn der PDC-Emulator der obersten Domain nicht aktuell ist, stimmt die Uhrzeit im gesamten Netzwerk nicht und das kann nur mit zuverlässigen externen Zeitquellen verhindert werden.

Viele Administratoren machen den Fehler, alle Systeme per NTP mit externen Quellen zu synchronisieren. Das ist jedoch der falsche Weg und führt immer dann zu Problemen, wenn ein Client gerade keine Verbindung zu seinen NTP-Servern hat und mit einer nicht synchronisierten Uhr eine Kerberos-Authentifizierung startet. Daher ist es wichtig, ausschließlich den PDC-Emulator der obersten Domain per NTP zu synchronisieren – alles andere macht Windows zuverlässig selbst.

WICHTIG: Auch wenn der eine oder andere Administrator meint, er wüsste es besser als Microsoft – einfach die Finger weg lassen, denn der Windows-Zeitdienst ist ein ausgeklügeltes System, dass man mit Änderungen nur verschlechtern kann.

Die Konfiguration findet wahlweise händisch per Konsolenbefehl statt, oder automatisiert per GPO.

Manuelle Konfiguration

PDC-Emulator

Für den PDC-Emulator und alle Standalone-Systeme ohne ActiveDirectory-Anbindung aktiviert man NTP mit diesem Befehl:

w32tm /config /manualpeerlist:0.pool.ntp.org,0x9 /syncfromflags:manual /reliable:yes /update

Da der NTP-Pool nur geprüfte Server beinhaltet und auf jede Anfrage mehrere IP-Adressen zurückliefert, müssen keine weiteren Adressen zur Ausfallsicherheit angegeben werden – Windows nutzt alle IP-Adressen, die es bei der DNS-Auflösung erhält. Wer andere Server nutzt sollte mindestens 3 Server haben; die werden dann als Leerzeichen-getrennte Liste in Anführungszeichen übergeben:

w32tm /config /manualpeerlist:"ptbtime1.ptb.de,0x9 ptbtime2.ptb.de,0xa ptbtime3.ptb.de,0xa" /syncfromflags:manual /reliable:yes /update

Wichtig sind bei beiden Kommandos die Server-Flags, die sich per Komma getrennt an jeden Servernamen anschließen. Sie müssen gesetzt werden und haben folgende Bedeutung:

  • 0x01 SpecialInterval (Primärer Server)
  • 0x02 UseAsFallbackOnly (Sekundärer Server)
  • 0x04 SymmatricActive
  • 0x08 Client

Es sollte immer genau einen primären Server geben, sekundäre Server können mehrfach vorhanden sein. Wer nur einen Server hat, nutzt daher 0x09 (0x01 + 0x08); wer mehrere Server hat, setzt einen auf 0x09 und die anderen auf 0x0a (0x02 + 0x08).

Der Rest

Für alle anderen Domain-Controller, Member-Server, Clients und die PDC-Emulatoren der Sub-Domains aktiviert man den internen Zeitdienst mit diesem Befehl:

w32tm /config /syncfromflags:domhier /update

In allen drei Fällen muss im Anschluss der Dienst neu gestartet werden:

net stop w32time
net start w32time

Das war schon alles. Da noch sehr viele Anleitungen mit dem Verweis auf den Befehl net time kursieren noch eine kleine Anmerkung: Dieser Befehl ist veraltet. Er stammt noch aus Windows NT, war ab Windows XP deprecated und ist ab Windows Vista nicht mehr zu nutzen. Es hilft auch nichts, sich alte Programmdateien aus früheren Windows-Versionen zu kopieren oder sonstige Experimente durchzuführen – einfach mit der Zeit gehen und w32tm nutzen. Da Windows XP 2001 erschienen ist sind also alle Anleitungen, die auf net time verweisen als inkompetent zu verwerfen!

Automatische Konfiguration mit GPO und WMI

Die manuelle Konfiguration hat den Nachteil, dass sie in sich zusammenfällt, sobald die FSMO-Rolle des PDC-Emulators auf einen anderen Server übertragen wird. Egal aus welchem Grund das durchgeführt wird, zur Entlastung bei der Inbetriebnahme zusätzlcher Server, im Rahmen einer Hardware-Regeneration oder im Falle von Disaster-Recoveries. Üblicherweise wird der Zeitdienst vergessen und dann treten auf einmal “komische Fehler” auf, die schwierig nachzuvollziehen sind.

Die Optimallösung ist also eine GPO, die nur auf dem PDC-Emulator der obersten Domain greift und die Einstellungen automatisch vornimmt. Damit alles komplett automatisch funktioniert, sollte man WMI-Filer einsetzen – dadurch spart man sich eine zusätzliche Organisationseinheit oder eine Sicherheitsgruppe, in die man den PDC-Emulator verschieben muss; das wären sonst nur Fehlerquellen die durch vergessliche Administratoren zum gleichen Problem führen wie die manuelle Konfiguration.

PDC-Emulator

In der Organisationseinheit “Domain Controllers” erstellt man eine neue Richtlinie und gibt ihr einen passenden Namen, z.B. “TimeSyncNTP”. Die passende Option nennt sich Configure Windows NTP Client und ist in der Richtlinie Computer Configuration\Administrative Templates\System\Windows Time Service\Time Providers zu finden. Außerdem muss mit der Option Enable Windows NTP Client der NTP-Client aktiviert werden; sie befindet sich in der gleichen Richtlinie.

NTP-Client per GPO einstellen (Quelle: microsoft.com)

Der Zeitdienst von Microsoft ist nur die zweitbeste Wahl, denn er steht in den USA und die große Entfernung führt zu Ungenauigkeiten. Hier dürfen natürlich andere Server eingestellt werden – die Eingabe folgt den gleichen Regeln, wie oben in der manuellen Konfiguration erläutert. Server-Flags nicht vergessen!

Nachdem diese Optionen gesetzt wurden schließt man die GPO und weist ihr dann diesen WMI-Filter zu, wodurch ihre Gültigkeit auf den PDC-Emulator begrenzt wird:

Select * from Win32_ComputerSystem where DomainRole = 5

Wichtig: Diese GPO darf nur in der obersten Domain eingerichtet werden, denn die PDC-Emulatoren der Sub-Domains sollen ja mit ihrer übergeordneten Domain synchronisieren und nicht per NTP.

Der Rest

Anschließend erstellt man auf Domain-Ebene eine weitere GPO, die alle anderen Domain-Coltroller, Member-Server und Clients konfiguriert. Sie erhält ebenfalls wieder einen schicken Namen, z.B. “TimeSyncW32”.

Für Domain-Forests darf man nicht vergessen, die Richtlinie in allen Domains zu aktivieren. Alternativ kann sie auch in jedem Standort aktiviert werden, denn damit greift sie automatisch für alle Domains – auch evtl. zukünftig eingerichtete Sub-Domains. Außerdem ist sie dort vor eigenwilligen Domain-Administratoren geschützt, denn sie ist auf Standort-Ebene nur für Organisations-Admins veränderbar.

Diese Richtlinie ist zwar erst einmal bedeutungslos, denn sie stellt das wieder her, was bereits Windows-Standard; allerdings wird sie dann wichtig, wenn die FSMO-Rolle übertragen wird, denn sie deaktiviert die Einstellungen, die unsere vorherigen GPO auf dem Server vorgenommen hat, der dann kein PDC-Emulator mehr ist. Außerdem macht sie das Werk inkompetenter Administratoren in Sub-Domains rückgängig, die am Windows-Timeservice herumspielen.

Hier stellt man als Quelltyp nicht NTP, sondern NT5DS ein, alles andere bleibt unverändert. Das Feld NtpServer spielt hier keine Rolle, denn es ist nur bei der Einstellung NTP von Belang.

Diese Richtlinie bekommt keine WMI-Filter, sodass sie für alle Systeme gilt, außer den PDC-Emulator, bei dem sie von der zuvor definierten Richtlinie “TimeSyncNTP” überschrieben wird.

Leider wirken sich beide Richtlinien erst nach einem Neustart des Dienstes w32time aus, sodass nach Änderungen alle Computer neu gestartet werden müssen. Bei den Clients und Member-Servern ist das egal, denn sie behalten immer die Standard-Einstellungen. Nach Übertragen von FSMO-Rollen muss man allerdings daran denken, auf dem alten und neuen PDC-Emulator den Windows-Zeitdienst neu zu starten. Natürlich behebt sich das Problem auch von selbst, wenn man sich angewöhnt, nach jeder Rollenübertragung die betroffenen Server neu zu starten, was allgemein keine schlechte Idee ist.

Leave a Reply

Your email address will not be published. Required fields are marked *