Tags: Active Directory, Synchronisierung
In einer Windows-Domäne sollte die Systemzeit aller Rechner übereinstimmen, damit das Active Directory störungsfrei funktionieren kann. Während die Synchronisierung der Uhrzeit bei normalen Mitgliedern einer Domäne automatisch gewährleistet sein sollte, empfiehlt sich beim DC mit der PDC-Emulator-Rolle die Konfiguration eines externen NTP-Servers.
Eine synchrone Systemzeit benötigt das Active Directory vor allen aus zwei Gründen:
- Bei der Replikation der AD-Datenbank werden Zeitstempel verwendet, um Replikationskonflikte aufzulösen. Sie entstehen, wenn Objekte parallel auf zwei oder mehreren Domain-Controllern verändert werden.
- Kerberos V5 verweigert die Authentifizierung von Computern, wenn deren Zeit mehr als 5 Minuten abweicht (dieser Wert ist die Voreinstellung, sie kann über GPOs mit der Einstellung Max. Toleranz für die Synchronisierung des Computertakts unter Computerkonfiguration => Windows-Einstellungen => Sicherheitseinstellungen => Kontorichtlinien => Kerberos-Richtlinie geändert werden).
Synchronisierung per Voreinstellung
Innerhalb einer Windows-Domäne sorgt der Windows Time Service (W32Time) automatisch für den Abgleich der Systemzeit. Normale Mitglieder, seien es Clients oder Server, synchronisieren ihre Zeit mit einem der Domain Controller.
Die DCs wiederum beziehen ihre Zeit vom Inhaber der Rolle PDC-Emulator. Dieser wiederum sollte seine Einstellungen von einem DC der übergeordneten Domäne erhalten, und die DCs dort synchronisieren sich mit dem dortigen PDC-Emulator, usw. (siehe Grafik). Der PDC-Emulator der Root-Domäne ist schließlich derjenige, der seine Systemzeit von einer externen Quelle abrufen sollte, etwa von einem dafür vorgesehenen Gerät oder einem Internet-Zeit-Server.
Einstellungen überprüfen mit w32tm
Möchte man herausfinden, von welcher Quelle ein Rechner seine Systemzeit ermittelt, dann kann man dies mit Hilfe des Befehls
w32tm /query /source /computer:<RemotePC>
herausfinden. Bei normalen Mitgliedern der Domäne sollte das Ergebnis ein DC sein, bei DCs der Inhaber der Rolle PDC-Emulator. Läuft Windows jedoch in einer virtuellen Maschine, dann lautet unter Hyper-V die Quelle auf VM IC Time Synchronization Provider, wenn die Synchronisierung über die Integrationsdienste aktiviert ist. Das Pendant unter VMware heißt VMICTimeProvider.
Synchronisierung in VMs unter Hyper-V
Gastbetriebssysteme in VMs greifen nicht auf die CMOS-Uhr zurück, um beim Booten die Systemzeit einzustellen. Stattdessen erhalten sie diese Information von Hyper-V, und zwar noch bevor die Integrationsdienste starten. Ab diesem Zeitpunkt berechnet Windows die aktuelle Zeit anhand eines eigenen Algorithmus. Da dieser innerhalb von VMs durch die ungleichmäßige Zuteilung von Hardware-Ressourcen meist außer Tritt gelangt und die Uhr damit zu langsam geht, gleicht die Synchronisierungsfunktion der Integrationsdienste diesen Rückstand immer wieder aus.
Aufgrund der ohnehin herrschenden Zeitsynchronisierung innerhalb einer Domäne erscheint es nicht notwendig, dass Windows-VMs ihre Systemuhren zusätzlich mit dem Virtualisierungs-Host abgleichen. Ben Armstrong, Program Manager für Hyper-V bei Microsoft, empfiehlt aber in einem Blog-Beitrag, die Synchronisierung mit Hyper-V eingeschaltet zu lassen. Diese komme damit klar, wenn Gäste ihre Einstellungen zusätzlich über eine andere Quelle bezögen. Außerdem sei sie in der Lage, die Uhren auch dann abzugleichen, wenn Host und Gast verschiedenen Zeitzonen angehören.
Diverse Ratgeber im Web empfehlen, die Zeitsynchronisierung mit Hyper-V in jedem Fall abzuschalten, wenn in der VM ein virtueller DC mit der PDC-Emulator-Rolle läuft. Hier drohe Chaos, wenn er zusätzlich seine Einstellungen von einer externen Quelle abrufe. Im oben genannten Beitrag rät Ben Armstrong jedoch dazu, auch in diesem Fall die Synchronisierung über Hyper-V nicht auszuschalten.
Externen Zeitgeber konfigurieren
In den meisten Umgebungen wird man nur den PDC-Betriebsmaster mit einer externen Quelle synchronisieren, alle anderen Rechner innerhalb der Domäne sollten automatisch mit ihm abgeglichen werden.
Auch die Konfiguration eines externen NTP-Servers erfolgt über den Befehl w32tm. Mit dem Parameter manualpeerlist teilt man ihm den DNS-Namen oder die IP-Adresse von einem Zeitgeber mit. Gibt man mehr als eine Quelle an, dann muss die Liste in Anführungszeichen stehen und die einzelnen Elemente müssen durch Leerzeichen getrennt sein. So konfiguriert man etwa die öffentlich zugänglichen NTP-Server von ntp.org auf folgende Weise:
w32tm /config /syncfromflags:manual /update /reliable:yes /manualpeerlist:"0.de.pool.ntp.org 1.de.pool.ntp.org 2.de.pool.ntp.org 3.de.pool.ntp.org"
NTP-Server über GPO einrichten
Alternativ zu w32tm.exe kann man Gruppenrichtlinien verwendet, um eine externe Zeitquelle zu definieren. Dazu erstellt man ein GPO und verknüpft es mit der OU Domain Controllers. Damit es nur auf den DC mit der Rolle PDC-Emulator angewendet wird, benötigt man diesen WMI-Filter:
Select * from Win32_ComputerSystem where DomainRole = 5
Die dafür zuständigen Einstellungen sind Windows-NTP-Client aktivieren und Windows-NTP-Client konfigurieren, sie finden sich unter Computerkonfiguration => Richtlinien => Administrative Vorlagen => System => Windows-Zeitdienst => Zeitanbieter.
Bei der Konfiguration des NTP-Clients muss man unter Type auf NTP umstellen, wenn man eine externe Quelle über dieses Protokoll einbinden möchte. Bei virtualisierten DCs kann es zudem hilfreich sein, das Poll-Intervall von den vorgegebenen 3600 auf 900 Sekunden zu verkürzen.
Schließlich muss man noch unter Computerkonfiguration => Richtlinien => Administrative Vorlagen => System => Windows-Zeitdienst die Globalen Konfigurationseinstellungen aktivieren und die vorgegebenen Werte dort bei Bedarf anpassen.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
- IdFix: Fehler im Active Directory finden, Sync mit Azure AD vorbereiten
- Geräte über Hybrid Join in Azure AD registrieren
- Passwortänderungen und Kennwortschutz von Azure AD in das lokale Active Directory zurückschreiben
- Azure AD Connect 2.1.15.0: Automatische Updates, Aus für Admin Agent, Sync für zusätzliche Attribute
- Azure AD Connect einrichten
Weitere Links
7 Kommentare
Damit der DC sich die Zeit von einem externen NTP-Provider beziehen kann, benötigt er jedoch einen Zugangs ins Internet. Eine gefährliche Sache, wie ich meine...
Eine externe Quelle, könnte auch ein Proxy/Firewall/UTM sein. Somit ist die Sicherheit wieder gewährleistet.
Interessant wäre auch ein Artikel wie man das ganze mit VM-Ware "richtig" macht.
Ich hatte schon einige Zeit Probleme mit virtuellen Umgebungen die auf VM-Ware aufbauen. Meine Lösung war es dann die NTP Server im Esxer ein zu tragen und die vms via VMware tools die Zeit synchronisieren zu lassen. Es ist aber auf jeden Fall drauf zu achten,dass die ESXer auch gültige DNS Server eingetragen haben, sonst geht die Zeitsynchronisierung schnell auch mal schief.
Gruß John
Hallo,
wie kann ich in einer Domäne das Abfrage-Intervall der Clients zum DC ändern? Ich möchte das global für alle Domain-Member über GPO festlegen.
Momentan ist der "Abrufintervall" auf meinen Clients, wenn ich w32tm /query /status ausführe auf "15 (32768s)" festgelegt. Ich möchte aber, dass die Clients sich standardmäßig einmal alle 60 Minuten mit dem DC ableichen.
Danke für den Tipp. Ich habe dass Problem das neben allen Terminals eine funkuhr steht weil die Domäne Zeit sich immer weiter verstellt. Der pdc wurde auf ein physikalischen Server übertragen aber vorher War alles auf einer VMware esxi. Die läuft aber nach wie vor weiter.
Bei uns hat die eingeschaltete Hyper-V Zeitsynchronisation der Gäste zu einem Fehler / Zeitversatz geführt.
Ich vermute, dass wenn der Hyper-V-Server ein Member-Server einer Domäne ist, von welcher der PDC eine seiner eigenen virtuellen Maschinen ist, das zu einer Schwanzbeisser-Schaltung führt, die nicht funktioniert.
Microsoft empfiehlt in der Domäne, das die Zeitsynchronisierung immer mit dem Zeitreferenzserver der Domäne (meist der PDC-Emulator) stattfindet und niemals mit dem Virtualisierungshost, wie es die default-Einstellungen der virtuellen Maschinen vorgeben.
Diese VM-Einstellung sollte man sofort bei der Installation ändern. Insbesondere bei virtualisierten DCs gibt's sonst mächtig Streß in der Domäne - und den braucht wirklich niemand.