Zeitserver Domäne Clients
Hallo,
mein Netz sieht wie folgt aus 2x VMware Host, 1x Vcenter VM, 2x DC´s, 2x DHCP. Zwischen DC´s und Clients ist die Uhrzeit unterschiedlich um ca. 2 min.
Wie ist die richtige Konfig hierzu bei Anwendung mit VMware. Wenn ich auf einen Client w32tm /query /status eingebe erscheint als Quelle time.windows.com
sollte doch vom PDC gezogen werden oder nicht.... Über NTP ist dies ratsam da permanent Verbindung nach außen bestehen muss ? oder doch Variante empfehlenswert
https://www.tech-faq.net/zeitquelle-am-domaenencontroller-konfigurieren/
Danke,
Gruß
Hans Peter
mein Netz sieht wie folgt aus 2x VMware Host, 1x Vcenter VM, 2x DC´s, 2x DHCP. Zwischen DC´s und Clients ist die Uhrzeit unterschiedlich um ca. 2 min.
Wie ist die richtige Konfig hierzu bei Anwendung mit VMware. Wenn ich auf einen Client w32tm /query /status eingebe erscheint als Quelle time.windows.com
sollte doch vom PDC gezogen werden oder nicht.... Über NTP ist dies ratsam da permanent Verbindung nach außen bestehen muss ? oder doch Variante empfehlenswert
https://www.tech-faq.net/zeitquelle-am-domaenencontroller-konfigurieren/
Danke,
Gruß
Hans Peter
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 650169
Url: https://administrator.de/contentid/650169
Ausgedruckt am: 24.11.2024 um 11:11 Uhr
7 Kommentare
Neuester Kommentar
Moin,
da hat ja schon einer herumgefummelt wenn ich das so lese.
Normal ist, dass die Clients sich nach dem DC richten. Die DCs selbst sollten sich am besten von einem festen Punkt die Zeit ziehen, aber nicht vom ESX. Der ESX wiederum sollte sich ebenfalls die Zeit von DCs ziehen.
Wie schon erwähnt sollten sich die Clients an dem DC orientieren. Das würde ich aller erstes gerade ziehen. Sonst fliegt dir ja die halbe Domäne auseinander.
Gruß
Spirit
da hat ja schon einer herumgefummelt wenn ich das so lese.
Normal ist, dass die Clients sich nach dem DC richten. Die DCs selbst sollten sich am besten von einem festen Punkt die Zeit ziehen, aber nicht vom ESX. Der ESX wiederum sollte sich ebenfalls die Zeit von DCs ziehen.
Wie schon erwähnt sollten sich die Clients an dem DC orientieren. Das würde ich aller erstes gerade ziehen. Sonst fliegt dir ja die halbe Domäne auseinander.
Gruß
Spirit
Das ist mir auch schon aufgefallen (Server 2016), also hat vermutlich niemand herum gefummelt. Ich habe es damals abgestempelt, dass es daran liegen könnte, dass der DC auch eine VM war und seine Zeit vom Hypervisor erhalten hat und der Hypervisor in der Domain drinnen war, also eigentlich ein Loop. Ich habe daraufhin den Zeitdienst für die DC VM deaktiviert und NTC aller Server wieder auf den DC umgestellt und die DCs manuell auf unseren Zeitserver im Netzwerk.
Nein das ist nicht so wichtig. Wichtig ist, dass du ein zentrales Gerät in deinem Netzwerk hast, was sich darum kümmert und alle anderen Geräte sich von dort die zeit holen. Das kann ein DC sein, muss es aber nicht. Es muss auch keine physische Maschine sein, aber die hat wie schon gesagt wurde den Vorteil, dass der Zeitserver dann auch zur Verfügung steht, wenn die VMS runter gefahren werden. Du kannst aber genau so gut einen physischen Management-Server (zum Beispiel der der ohnehin deine Server überwacht) dafür nehmen.
Ich persönlich nehme gerne die Firewall als NTP-Server. Zum einen ist die permanent erreichbar und auch bei Update (weil Cluster) noch verfügbar. Zum anderen ändert sich die IP der Firewall so gut wie nie. Selbst bei einem Tausch bleibt die IP der Firewall gleich, wo bei eines virtuellen DCs oder eines physischen Managementservers sich im Laufe der Zeit (meist bei einer Migration auf eine höhere Serverversion) auch mal wechselt. Und für die Kritiker: Ja das ist ein bisschen mehr Last für die Firewall, aber ich muss die NTP-Daten ja nicht alle 5 Sekunden Abfragen. Es reicht die Daten beim Start des Gerätes und dann (meine Meinung) maximal alle 3 Stunden abgeglichen werden. Diese "Last" sollte eine Firewall durchaus aushalten.
Ich verwende ebenfalls die Firewall als NTP, jedoch wird diese nur von einem DC abgefragt, nicht von den Clients. Die Clients holen sie es sich trotzdem vom DC ab.
Aus folgendem Grund:
Ich habe zwei DC's. Beide holten sich die Zeit von der Firewall ab. Nach einem Stromausfall war die Firewall nicht bereit. Firewall neu gestartet, geht wieder. Ein DC wollte in der Phase eine neue Zeit abholen, der andere DC noch nicht. Das Ergebnis war ein Zeitunterschied von 1h - die Zeitzonen stimmten jedoch überall. Alle Clients und Server, die am DC1 angemeldet waren, hatten eine andere Uhrzeit, als Geräte, die am DC2 angemeldet waren. Kerberos hat die Häfte abgewiesen. Erst nach 45 Minuten mit ständigen Neustarts, überprüfen der NTP Einstellungen sämtlicher DCs, Server und ein paar Clients, hat es sich wieder von selbst normalisiert.
Aus folgendem Grund:
Ich habe zwei DC's. Beide holten sich die Zeit von der Firewall ab. Nach einem Stromausfall war die Firewall nicht bereit. Firewall neu gestartet, geht wieder. Ein DC wollte in der Phase eine neue Zeit abholen, der andere DC noch nicht. Das Ergebnis war ein Zeitunterschied von 1h - die Zeitzonen stimmten jedoch überall. Alle Clients und Server, die am DC1 angemeldet waren, hatten eine andere Uhrzeit, als Geräte, die am DC2 angemeldet waren. Kerberos hat die Häfte abgewiesen. Erst nach 45 Minuten mit ständigen Neustarts, überprüfen der NTP Einstellungen sämtlicher DCs, Server und ein paar Clients, hat es sich wieder von selbst normalisiert.
Virtuelle DC sind tatsächlich ein Problem. Dort wird zwar von VMware eine Hardware Clock simuliert, aber eben nur simuliert.
Ich habe die Erfahrung mit einem Samba DC (virtualisiert mit KVM) gemacht, dort gibt es eine Option für den NTP. Diese nennt sich "Tinker Panic 0" und wird in die ntp.conf gesetzt.
Damit wird bewirkt, das wenn die Differenz zwischen der "simulierten" Hardware Clock und den externen Zeitservern zu groß wird, diese nicht vom NTP Daemon nachjustiert wird. Wird hier also das selbe Problem sein. Den es wird immer die lokale Zeit mit den Zeitservern abgeglichen.
Ich habe die Erfahrung mit einem Samba DC (virtualisiert mit KVM) gemacht, dort gibt es eine Option für den NTP. Diese nennt sich "Tinker Panic 0" und wird in die ntp.conf gesetzt.
Damit wird bewirkt, das wenn die Differenz zwischen der "simulierten" Hardware Clock und den externen Zeitservern zu groß wird, diese nicht vom NTP Daemon nachjustiert wird. Wird hier also das selbe Problem sein. Den es wird immer die lokale Zeit mit den Zeitservern abgeglichen.