47
Zeit Phänomen, haben wir hier das erste Wurmloch gefunden?
Moin Zusammen,
ich wurde soeben von einem Administrator angerufen, der schon seit Tagen ein Problem mit der Synchronisation der Systemzeiten hat.
Als er mir das erste Mal sein Problem geschildert hat, dachte ich zuerst, dass der Gute vielleicht das falsche Kraut vorher geraucht haben könnte.
Jedoch hat mich eine Teamviewersitzung gerade selbst einen guten Schock verpasst.
Siehe folgendes Video
https://youtu.be/GUwaINxNhpw
Links ist Domänencontroller 1 und rechts ist Domänencontroller 2.
Wie kann den so etwas passieren? 🤨🤔
Grüsse aus BaWü
Alex
P.S. Beide DCs sind virtualisiert und laufen aktuell sogar auf demselben Hyper-V Host.
ich wurde soeben von einem Administrator angerufen, der schon seit Tagen ein Problem mit der Synchronisation der Systemzeiten hat.
Als er mir das erste Mal sein Problem geschildert hat, dachte ich zuerst, dass der Gute vielleicht das falsche Kraut vorher geraucht haben könnte.
Jedoch hat mich eine Teamviewersitzung gerade selbst einen guten Schock verpasst.
Siehe folgendes Video
https://youtu.be/GUwaINxNhpw
Links ist Domänencontroller 1 und rechts ist Domänencontroller 2.
Wie kann den so etwas passieren? 🤨🤔
Grüsse aus BaWü
Alex
P.S. Beide DCs sind virtualisiert und laufen aktuell sogar auf demselben Hyper-V Host.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 621128
Url: https://administrator.de/forum/zeit-phaenomen-haben-wir-hier-das-erste-wurmloch-gefunden-621128.html
Ausgedruckt am: 21.12.2024 um 17:12 Uhr
47 Kommentare
Neuester Kommentar
Naja das erste was ich mal als Referenz tauschen würde ist der Browser, der IE ist doch kaum noch von Webseiten vernünftig supported da würde mich so ein Bug ehrlich gesagt auch nicht wundern ...
der schon seit Tagen ein Problem mit der Synchronisation der Systemzeiten hat.
HyperV-Host-Sync der Zeiten auch sicher abgeschaltet?
Moin,
da hat Dich einer genatzt. Beim linken wurde der Refresh ausgeschaltet. Der rechte holt sich die Seite beim Reload erst aus dem Cache und macht dann den Refresh.
Liebe Grüße
Erik
<edit>Ich konnte das reproduzieren sogar in ein und demselben Browser. Man muss nur schnell genug beim Reload auf das Kreuz "Laden abbrechen" klicken. Offenbar wird erst GMT angezeigt und erst kurz danach die Zeit der Zeitzone des Rechners. Nach dem Abbruch läuft die Uhr nicht weiter.</edit>
da hat Dich einer genatzt. Beim linken wurde der Refresh ausgeschaltet. Der rechte holt sich die Seite beim Reload erst aus dem Cache und macht dann den Refresh.
Liebe Grüße
Erik
<edit>Ich konnte das reproduzieren sogar in ein und demselben Browser. Man muss nur schnell genug beim Reload auf das Kreuz "Laden abbrechen" klicken. Offenbar wird erst GMT angezeigt und erst kurz danach die Zeit der Zeitzone des Rechners. Nach dem Abbruch läuft die Uhr nicht weiter.</edit>
nun gegen den Zeitdrift ist das Kraut des NTP Servers gewachsen, und wer Angst vor gefakten NTP Zeiten hat oder schwankende Latenzen zum NTP Server zum Problem werden, gibts externe DCF77 Funkuhrmodule über die eine sehr exakte Zeit kommt.
Das Problem war bekannt, speziell bei vielen AMD CPUs, daß manchmal die Uhr auf einem Thread schneller läuft wie auf einem anderen Thread. Es kann aber auch von ungenauen Systemtakten am Mainboard kommen, denn EIGENTLICH sind Zeitdrifts seit 10 Jahren auf aktueller Hardware kein Thema mehr. Daß mal ein Server nach einem Monat ohne NTP Kontakt ein paar Minuten falsch geht, ist normal speziell bei sehr ungleichmäßiger Last.
Das Problem war bekannt, speziell bei vielen AMD CPUs, daß manchmal die Uhr auf einem Thread schneller läuft wie auf einem anderen Thread. Es kann aber auch von ungenauen Systemtakten am Mainboard kommen, denn EIGENTLICH sind Zeitdrifts seit 10 Jahren auf aktueller Hardware kein Thema mehr. Daß mal ein Server nach einem Monat ohne NTP Kontakt ein paar Minuten falsch geht, ist normal speziell bei sehr ungleichmäßiger Last.
Moin Window,
Na ja, ist ein DC, da installiere ich im Normalfall nichts ausser den notwendigen AD Diensten und AV, normalerweise auch keinen anderen Browser. Aber bei der falschen Zeit im Browser hattest du dennoch recht, habe den EDGE draufgeschmissen und schon wurde die Zeit zumindest auf der Webseite korrekt angezeigt. Die DC liefen aber dennoch zwei Minuten auseinander und liessen sich ums Verrecken nicht Synchronisieren.
Habe aber das Problem gefunden, siehe späteren Post.
Jup, auf den DC's schon.
Grüsse aus BaWü
Alex
Naja das erste was ich mal als Referenz tauschen würde ist der Browser, der IE ist doch kaum noch von Webseiten vernünftig supported da würde mich so ein Bug ehrlich gesagt auch nicht wundern ...
Na ja, ist ein DC, da installiere ich im Normalfall nichts ausser den notwendigen AD Diensten und AV, normalerweise auch keinen anderen Browser. Aber bei der falschen Zeit im Browser hattest du dennoch recht, habe den EDGE draufgeschmissen und schon wurde die Zeit zumindest auf der Webseite korrekt angezeigt. Die DC liefen aber dennoch zwei Minuten auseinander und liessen sich ums Verrecken nicht Synchronisieren.
Habe aber das Problem gefunden, siehe späteren Post.
HyperV-Host-Sync der Zeiten auch sicher abgeschaltet?
Jup, auf den DC's schon.
Grüsse aus BaWü
Alex
Moin Erik,
Nein mich hat da keiner reingelegt, habe das Video selbst aufgenommen und wie du siehst laufen die Zeiten sowohl in der linken VM als auch in der rechten VM abgesehen von der Differenz sauber weiter.
Das die Zeit im Browser nicht weiterläuft kennen ich. Das kommt meistens wenn die "verstärkte Sicherheitskonfiguration für IE" aktiviert ist, war hier aber nicht der Fall.
Grüsse aus BaWü
Alex
da hat Dich einer genatzt. Beim linken wurde der Refresh ausgeschaltet. Der rechte holt sich die Seite beim Reload erst aus dem Cache und macht dann den Refresh.
Nein mich hat da keiner reingelegt, habe das Video selbst aufgenommen und wie du siehst laufen die Zeiten sowohl in der linken VM als auch in der rechten VM abgesehen von der Differenz sauber weiter.
Das die Zeit im Browser nicht weiterläuft kennen ich. Das kommt meistens wenn die "verstärkte Sicherheitskonfiguration für IE" aktiviert ist, war hier aber nicht der Fall.
Grüsse aus BaWü
Alex
Moin GrueneSosseMitSpeck,
habe bei beiden DCs schon x Mal die NTP Konfiguration laut der folgenden Dokumentation reingeklopft.
https://docs.microsoft.com/en-us/windows-server/networking/windows-time- ...
Dafür verwende ich normalerweise den folgenden Befehl
die anschliessende Prüfung der Konfiguration brachte jedoch das folgende Ergebnis.
DC1:
PS C:\Users\Administrator> w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 4 (Sekund„rreferenz - synchr. ber (S)NTP)
Pr„zision: -6 (15.625ms pro Tick)
Stammverz”gerung: 0.0330811s
Stammabweichung: 0.0551110s
Referenz-ID: 0x3369D0AD (Quell-IP: 51.105.208.173)
Letzte erfolgr. Synchronisierungszeit: 10.11.2020 16:43:28
Quelle: time.windows.com,0x9
Abrufintervall: 8 (256s)
DC2:
PS C:\Users\Administrator> w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 1 (Prim„rreferenz - synchron. ber Funkuhr)
Pr„zision: -6 (15.625ms pro Tick)
Stammverz”gerung: 0.0000000s
Stammabweichung: 10.0000000s
Referenz-ID: 0x4C4F434C (Quellname: "LOCL")
Letzte erfolgr. Synchronisierungszeit: 10.11.2020 17:08:02
Quelle: Local CMOS Clock
Abrufintervall: 6 (64s)
Die von mir oben angesprochene und mehrfach ausgeführte Konfiguration wurde einfach nicht übernommen.
Quasi kurz vor dem durchdrehen hat mich dann doch ein Geistesblitz getroffen 🙃, bin in die Registry der DC's gegangen und habe dort den folgenden Ordner vollständig gelöscht.
Habe danach den Zeitserverdienst neu gestartet und bekam bei der anschliessenden Konfigurationsprüfung das folgende Ergebnis.
PS C:\Users\Administrator> w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 2 (Sekund„rreferenz - synchr. ber (S)NTP)
Pr„zision: -6 (15.625ms pro Tick)
Stammverz”gerung: 0.0312500s
Stammabweichung: 0.0287389s
Referenz-ID: 0xC0356768 (Quell-IP: 192.53.103.104)
Letzte erfolgr. Synchronisierungszeit: 10.11.2020 22:29:05
Quelle: ptbtime2.ptb.de
Abrufintervall: 8 (256s)
🤗
Ich vermute, dass GPO Altlasten das Problem verursacht haben, sicher bin ich mir da aber nicht so ganz.
Grüsse aus BaWü
Alex
habe bei beiden DCs schon x Mal die NTP Konfiguration laut der folgenden Dokumentation reingeklopft.
https://docs.microsoft.com/en-us/windows-server/networking/windows-time- ...
Dafür verwende ich normalerweise den folgenden Befehl
w32tm /config /manualpeerlist:"ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de" /syncfromflags:manual /update
net stop w32time
net start w32timedie anschliessende Prüfung der Konfiguration brachte jedoch das folgende Ergebnis.
DC1:
PS C:\Users\Administrator> w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 4 (Sekund„rreferenz - synchr. ber (S)NTP)
Pr„zision: -6 (15.625ms pro Tick)
Stammverz”gerung: 0.0330811s
Stammabweichung: 0.0551110s
Referenz-ID: 0x3369D0AD (Quell-IP: 51.105.208.173)
Letzte erfolgr. Synchronisierungszeit: 10.11.2020 16:43:28
Quelle: time.windows.com,0x9
Abrufintervall: 8 (256s)
DC2:
PS C:\Users\Administrator> w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 1 (Prim„rreferenz - synchron. ber Funkuhr)
Pr„zision: -6 (15.625ms pro Tick)
Stammverz”gerung: 0.0000000s
Stammabweichung: 10.0000000s
Referenz-ID: 0x4C4F434C (Quellname: "LOCL")
Letzte erfolgr. Synchronisierungszeit: 10.11.2020 17:08:02
Quelle: Local CMOS Clock
Abrufintervall: 6 (64s)
Die von mir oben angesprochene und mehrfach ausgeführte Konfiguration wurde einfach nicht übernommen.
Quasi kurz vor dem durchdrehen hat mich dann doch ein Geistesblitz getroffen 🙃, bin in die Registry der DC's gegangen und habe dort den folgenden Ordner vollständig gelöscht.
Habe danach den Zeitserverdienst neu gestartet und bekam bei der anschliessenden Konfigurationsprüfung das folgende Ergebnis.
PS C:\Users\Administrator> w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 2 (Sekund„rreferenz - synchr. ber (S)NTP)
Pr„zision: -6 (15.625ms pro Tick)
Stammverz”gerung: 0.0312500s
Stammabweichung: 0.0287389s
Referenz-ID: 0xC0356768 (Quell-IP: 192.53.103.104)
Letzte erfolgr. Synchronisierungszeit: 10.11.2020 22:29:05
Quelle: ptbtime2.ptb.de
Abrufintervall: 8 (256s)
🤗
Ich vermute, dass GPO Altlasten das Problem verursacht haben, sicher bin ich mir da aber nicht so ganz.
Grüsse aus BaWü
Alex
Ich tippe hat auf einen Caching-Fehler. IE ist der ärgste Müll was das angeht.
Hi,
was mir sofort aufgefallen ist:
Das sind 2 verschiedene URL und auch 2 verschiedene Webseiten. Also vergleichst Du da per se schon mal Äpfel mit Birnen.
E.
was mir sofort aufgefallen ist:
Das sind 2 verschiedene URL und auch 2 verschiedene Webseiten. Also vergleichst Du da per se schon mal Äpfel mit Birnen.
E.
Moin Emeriks,
da muss ich dir widersprechen, ist derselbe Webserver, schau dir das Video genauer an. 😉
Gruss Alex
was mir sofort aufgefallen ist:
Das sind 2 verschiedene URL und auch 2 verschiedene Webseiten. Also vergleichst Du da per se schon mal Äpfel mit Birnen.
Das sind 2 verschiedene URL und auch 2 verschiedene Webseiten. Also vergleichst Du da per se schon mal Äpfel mit Birnen.
da muss ich dir widersprechen, ist derselbe Webserver, schau dir das Video genauer an. 😉
Gruss Alex
Hallo,
Nee, normalerweise bekommen alle Domänenmember und alle DCs folgendes:
und nur der PDC bekommt
Wir machen das über GPO mit WMI-filtern für die PDC-Rolle, da stimmts dann auch bei Rollentransfers.
Grüße
lcer
Zitat von @MysticFoxDE:
habe bei beiden DCs schon x Mal die NTP Konfiguration laut der folgenden Dokumentation reingeklopft.
https://docs.microsoft.com/en-us/windows-server/networking/windows-time- ...
Dafür verwende ich normalerweise den folgenden Befehl
habe bei beiden DCs schon x Mal die NTP Konfiguration laut der folgenden Dokumentation reingeklopft.
https://docs.microsoft.com/en-us/windows-server/networking/windows-time- ...
Dafür verwende ich normalerweise den folgenden Befehl
> w32tm /config /manualpeerlist:"ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de" /syncfromflags:manual /update
> net stop w32time
> net start w32time
> Nee, normalerweise bekommen alle Domänenmember und alle DCs folgendes:
... /syncfromflags:domhier... /syncfromflags:manual /reliable:yesWir machen das über GPO mit WMI-filtern für die PDC-Rolle, da stimmts dann auch bei Rollentransfers.
Grüße
lcer
Moin Icer,
ich würde weder das eine als falsch betrachten noch das andere, sondern eher als so ne Art Glaubensfrage. 🙃
Mann kann natürlich den PDC nach aussen synchronisieren und alle anderen DCs gegen diesen fahren.
Aber es spricht auch nichts dagegen, dass sich jeder DC für sich nach aussen synchronisiert, vor allem wenn es dieselbe Zeitquelle ist.
Grüsse aus BaWü
Alex
Zitat von @lcer00:
Hallo,
Nee, normalerweise bekommen alle Domänenmember und alle DCs folgendes:
und nur der PDC bekommt
Hallo,
Zitat von @MysticFoxDE:
habe bei beiden DCs schon x Mal die NTP Konfiguration laut der folgenden Dokumentation reingeklopft.
https://docs.microsoft.com/en-us/windows-server/networking/windows-time- ...
Dafür verwende ich normalerweise den folgenden Befehl
habe bei beiden DCs schon x Mal die NTP Konfiguration laut der folgenden Dokumentation reingeklopft.
https://docs.microsoft.com/en-us/windows-server/networking/windows-time- ...
Dafür verwende ich normalerweise den folgenden Befehl
>> w32tm /config /manualpeerlist:"ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de" /syncfromflags:manual /update
>> net stop w32time
>> net start w32time
>> Nee, normalerweise bekommen alle Domänenmember und alle DCs folgendes:
... /syncfromflags:domhier... /syncfromflags:manual /reliable:yesich würde weder das eine als falsch betrachten noch das andere, sondern eher als so ne Art Glaubensfrage. 🙃
Mann kann natürlich den PDC nach aussen synchronisieren und alle anderen DCs gegen diesen fahren.
Aber es spricht auch nichts dagegen, dass sich jeder DC für sich nach aussen synchronisiert, vor allem wenn es dieselbe Zeitquelle ist.
Grüsse aus BaWü
Alex
Hallo
Grüße
lcer
Zitat von @MysticFoxDE:
ich würde weder das eine als falsch betrachten noch das andere, sondern eher als so ne Art Glaubensfrage. 🙃
Mann kann natürlich den PDC nach aussen synchronisieren und alle anderen DCs gegen diesen fahren.
Eine Glaubensfrage wäre es, sich zwischen Linux und Microsoft oder zwischen Macbook und Surface zu entscheiden.ich würde weder das eine als falsch betrachten noch das andere, sondern eher als so ne Art Glaubensfrage. 🙃
Mann kann natürlich den PDC nach aussen synchronisieren und alle anderen DCs gegen diesen fahren.
Aber es spricht auch nichts dagegen, dass sich jeder DC für sich nach aussen synchronisiert, vor allem wenn es dieselbe Zeitquelle ist.
Vor allem, dass es nicht Best-Practice von Microsoft (welches das Betriebssystem deiner DCs herstellt) ist. Und wenn Dein herangehen korrekt wäre, gäbe es vermutlich dieses Thread nicht.Grüße
lcer
Zitat von @MysticFoxDE:
da muss ich dir widersprechen, ist derselbe Webserver, schau dir das Video genauer an. 😉
Ja und? Was habe ich geschrieben? Schau Dir meinen Kommentar genauer an. da muss ich dir widersprechen, ist derselbe Webserver, schau dir das Video genauer an. 😉
Moin Emeriks,
du hast das hier geschrieben
und das stimmt eben nicht.
Gruss Alex
Ja und? Was habe ich geschrieben? Schau Dir meinen Kommentar genauer an.
du hast das hier geschrieben
Das sind 2 verschiedene URL und auch 2 verschiedene Webseiten. Also vergleichst Du da per se schon mal Äpfel mit Birnen.
und das stimmt eben nicht.
Gruss Alex
Es sind 2 verschiedene URL. So blind kann ich gar nicht sein.
Einmal
und einmal
Weiterhin sagt uns doch schon allein der Inhalt, dass das zwei verschiedene Seiten sind.
Edit:
Die Atomuhr wird GMT +-0 anzeigen, die "Uhrzeit" die lokal gerade gültige, hier wohl GMT +1.
Das wäre dann "nur" ein Fehler im Text der betreffenden Dokumente.
Einmal
und einmal
Weiterhin sagt uns doch schon allein der Inhalt, dass das zwei verschiedene Seiten sind.
Edit:
Die Atomuhr wird GMT +-0 anzeigen, die "Uhrzeit" die lokal gerade gültige, hier wohl GMT +1.
Das wäre dann "nur" ein Fehler im Text der betreffenden Dokumente.
Zitat von @MysticFoxDE:
Das sind 2 verschiedene URL und auch 2 verschiedene Webseiten. Also vergleichst Du da per se schon mal Äpfel mit Birnen.
https://de.wikipedia.org/wiki/Uniform_Resource_Locator
https://tools.ietf.org/html/rfc3986
Grüße
lcer
Moin Icer,
Das würde ich schon eher als Glaubenskrieg bezeichnen. 🙃
Microsoft und Best-Practice, nice, der war heute bisher der Beste. 😂🤣😂🤣
Deshalb müssen andere und auch ich, MS ständig hinterherrennen, damit die Ihren vermurksten Dokumentationen richtigstellen.
Und bevor du jetzt zu voreilig antwortest. Suche mal bei irgend einer Suchmaschine nach "Server 2019 performance", klicke auf den Spiceworks Post (Platz 1-5) und lese dir diesen in Ruhe durch. 😉
Diesen Thread habe ich hauptsächlich wegen des komischen Browserverhalten geöffnet, welches ich so noch nie war genommen habe.
Dieses Verhalten hat sich mit dem Wechsel des Browsers erledigt. Der Rest ist beiläufig entstanden.
Grüsse aus BaWü
Alex
Eine Glaubensfrage wäre es, sich zwischen Linux und Microsoft oder zwischen Macbook und Surface zu entscheiden.
Das würde ich schon eher als Glaubenskrieg bezeichnen. 🙃
Vor allem, dass es nicht Best-Practice von Microsoft (welches das Betriebssystem deiner DCs herstellt) ist.
Microsoft und Best-Practice, nice, der war heute bisher der Beste. 😂🤣😂🤣
Deshalb müssen andere und auch ich, MS ständig hinterherrennen, damit die Ihren vermurksten Dokumentationen richtigstellen.
Und bevor du jetzt zu voreilig antwortest. Suche mal bei irgend einer Suchmaschine nach "Server 2019 performance", klicke auf den Spiceworks Post (Platz 1-5) und lese dir diesen in Ruhe durch. 😉
Und wenn Dein herangehen korrekt wäre, gäbe es vermutlich dieses Thread nicht.
Diesen Thread habe ich hauptsächlich wegen des komischen Browserverhalten geöffnet, welches ich so noch nie war genommen habe.
Dieses Verhalten hat sich mit dem Wechsel des Browsers erledigt. Der Rest ist beiläufig entstanden.
Grüsse aus BaWü
Alex
Hallo,
Grüße
lcer
Zitat von @emeriks:
Na da kann man lesen, wo eine URL beginnt und wo sie endet. Lesen muss es der TO selbst.Zitat von @lcer00:
https://de.wikipedia.org/wiki/Uniform_Resource_Locator
https://tools.ietf.org/html/rfc3986
Ja, und?https://de.wikipedia.org/wiki/Uniform_Resource_Locator
https://tools.ietf.org/html/rfc3986
Grüße
lcer
Zitat von @MysticFoxDE:
Vor allem, dass es nicht Best-Practice von Microsoft (welches das Betriebssystem deiner DCs herstellt) ist.
Microsoft und Best-Practice, nice, der war heute bisher der Beste. 😂🤣😂🤣
Sachliche Diskussionen sind die Besten! Aber zumindest mit Smileys kennst Du Dich ja aus.Vor allem, dass es nicht Best-Practice von Microsoft (welches das Betriebssystem deiner DCs herstellt) ist.
Microsoft und Best-Practice, nice, der war heute bisher der Beste. 😂🤣😂🤣
Deshalb müssen andere und auch ich, MS ständig hinterherrennen, damit die Ihren vermurksten Dokumentationen richtigstellen.
Nun, Microsoft empfiehlt mindestens seit Server 2008, die Zeitsynchronisation über die Domänenhierachie laufen zu lassen. Etwas anders kann ich keinem Artikel von MS entnehmen. Du darfst gerne bei einem Artikel aus 2007 anfangen: https://docs.microsoft.com/de-de/archive/blogs/w32time/what-is-windows-t ... Die manuelle Synchronisation ist für Maschinen vorgesehen, die die Domänensynchronisation nicht nutzen können.Und bevor du jetzt zu voreilig antwortest. Suche mal bei irgend einer Suchmaschine nach "Server 2019 performance", klicke auch den Spiceworks Post (Platz 1-5) und lese dir diesen in Ruhe durch. 😉
Wo steht da was über die Zeitsynchronisation? Wenn du ein Problem mit Microsoft hast, dann wechsle doch einfach den Anbieter deines Betriebssystems (siehe oben, Glaubensfrage).Grüße
lcer
Moin Emeriks,
https://www.atomuhr.de/
https://www.atomuhr.de/#
https://www.atomuhr.de/uhrzeit/
https://www.atomuhr.de/uhrzeit/#
Jetzt bei jedem Link die F12 taste drücken und den Quellcode bitte genauer anschauen. 😉
Gruss Alex
Zitat von @emeriks:
Es sind 2 verschiedene URL. So blind kann ich gar nicht sein.
Einmal
und einmal
Weiterhin sagt uns doch schon allein der Inhalt, dass das zwei verschiedene Seiten sind.
Edit:
Die Atomuhr wird GMT +-0 anzeigen, die "Uhrzeit" die lokal gerade gültige, hier wohl GMT +1.
Das wäre dann "nur" ein Fehler im Text der betreffenden Dokumente.
Es sind 2 verschiedene URL. So blind kann ich gar nicht sein.
Einmal
und einmal
Weiterhin sagt uns doch schon allein der Inhalt, dass das zwei verschiedene Seiten sind.
Edit:
Die Atomuhr wird GMT +-0 anzeigen, die "Uhrzeit" die lokal gerade gültige, hier wohl GMT +1.
Das wäre dann "nur" ein Fehler im Text der betreffenden Dokumente.
https://www.atomuhr.de/
https://www.atomuhr.de/#
https://www.atomuhr.de/uhrzeit/
https://www.atomuhr.de/uhrzeit/#
Jetzt bei jedem Link die F12 taste drücken und den Quellcode bitte genauer anschauen. 😉
Gruss Alex
Jetzt bei jedem Link die F12 taste drücken und den Quellcode bitte genauer anschauen. 😉
; - )
Moin Icer,
Und genau das tue ich auch, somit entspricht mein Vorgehen ebenfalls der Empfehlung des Herstellers. 😉
Ich habe auch nichts geschrieben, dass dort etwas zur Zeit Synchronisation stehet, da geht es eher auch um das Thema "Microsoft und Best-Practice"
Grusse aus BaWü
Alex
Sachliche Diskussionen sind die Besten! Aber zumindest mit Smileys kennst Du Dich ja aus.
Aber sicher, siehe Unten, aber mit Smileys macht es eben mehr Spass. 😉Nun, Microsoft empfiehlt mindestens seit Server 2008, die Zeitsynchronisation über die Domänenhierachie laufen zu lassen. Etwas anders kann ich keinem Artikel von MS entnehmen. Du darfst gerne bei einem Artikel aus 2007 anfangen: https://docs.microsoft.com/de-de/archive/blogs/w32time/what-is-windows-t ... Die manuelle Synchronisation ist für Maschinen vorgesehen, die die Domänensynchronisation nicht nutzen können.
Und genau das tue ich auch, somit entspricht mein Vorgehen ebenfalls der Empfehlung des Herstellers. 😉
Wo steht da was über die Zeitsynchronisation? Wenn du ein Problem mit Microsoft hast, dann wechsle doch einfach den Anbieter deines Betriebssystems (siehe oben, Glaubensfrage).
Ich habe auch nichts geschrieben, dass dort etwas zur Zeit Synchronisation stehet, da geht es eher auch um das Thema "Microsoft und Best-Practice"
Grusse aus BaWü
Alex
but will go out of site/domain if needed
Wobei hier mit "site" ein AD Standort gemeint ist. Und mit "domain" eine AD Domäne. Nur, falls das nicht klar sein sollte.
Hallo,
Nun, bloß weil es möglich und zulässig ist, ist es nicht unbedingt sinnvoll. Man sollte hier stichhaltige Gründe haben, die gegen die (Default-)Zeitsynchronisation mit dem PDC sprechen. Wenn Du der Zeitsynchronisaton zwischen DC und PDC nicht vertraust, bricht ja im Grunde auch die Vertrauensbasis für Kerberos weg.
Wenn man mit einem externen Server synchronisiert, erfolgt das über NTP. Standard wäre NT5DS, was etwas komplexer arbeitet.
Hier wird ein eine Zeitquelle verworfen, wenn sie nicht als verlässlich eingestuft wird (NTP-Quellen werden ja nur bei größerer Abweichung verworfen). Also erhöhte Sicherheit innerhalb der Domäne. Was für Gründe sprechen da für NTP und Zeitquellen außerhalb der Domäne (mit Ausnahme einer externen Referenz am PDC)?
Grüße
lcer
Und genau das tue ich auch, somit entspricht mein Vorgehen ebenfalls der Empfehlung des Herstellers
Nun, bloß weil es möglich und zulässig ist, ist es nicht unbedingt sinnvoll. Man sollte hier stichhaltige Gründe haben, die gegen die (Default-)Zeitsynchronisation mit dem PDC sprechen. Wenn Du der Zeitsynchronisaton zwischen DC und PDC nicht vertraust, bricht ja im Grunde auch die Vertrauensbasis für Kerberos weg.
Wenn man mit einem externen Server synchronisiert, erfolgt das über NTP. Standard wäre NT5DS, was etwas komplexer arbeitet.
Domain joined computers utilize the NT5DS mode. This mode uses netlogon API calls to find an eligible peer to sync with.Grüße
lcer
Zitat von @lcer00:
Was für Gründe sprechen da für NTP und Zeitquellen außerhalb der Domäne (mit Ausnahme einer externen Referenz am PDC)?
Wenige.Was für Gründe sprechen da für NTP und Zeitquellen außerhalb der Domäne (mit Ausnahme einer externen Referenz am PDC)?
Wenn ein Standort mit DC mal eine nicht permanente Verbindung zu den anderen Standorten mit anderen DC's des selben Forest hat, dann kann sowas Sinn machen.
Moin Emeriks,
und was genau liegt ausserhalb einer site/domain?
Gruss Alex
Zitat von @emeriks:
but will go out of site/domain if needed
Wobei hier mit "site" ein AD Standort gemeint ist. Und mit "domain" eine AD Domäne. Nur, falls das nicht klar sein sollte.und was genau liegt ausserhalb einer site/domain?
Gruss Alex
Andere DC.
Wenn ein DC selbst der PDC einer der weiteren Domänen einer Gesamtstruktur ist, dann versucht sich dieser PDC mit dem PDC der Stammdomäne abzugleichen. Wenn dieser nicht erreichbar ist, dann mit einem anderen DC der Stammdomäne. Egal an welcher Site diese sind.
Wenn ein DC selbst nicht der PDC ist, dann versucht er sich mit PDC der eigenen Domäne abzugleichen, auch wenn dieser in einer anderen Site ist und in der eigenen Site noch ein weiterer DC ist.
Bei der Auswahl anderen DC als den PDC berücksichtigt er höchstwahrscheinlich die Konfiguration der Standortverknüpfungen. Das kann ich jetzt nicht schwören, aber es würde mich sehr wundern, wenn dem nicht so wäre.
Wenn ein DC selbst der PDC einer der weiteren Domänen einer Gesamtstruktur ist, dann versucht sich dieser PDC mit dem PDC der Stammdomäne abzugleichen. Wenn dieser nicht erreichbar ist, dann mit einem anderen DC der Stammdomäne. Egal an welcher Site diese sind.
Wenn ein DC selbst nicht der PDC ist, dann versucht er sich mit PDC der eigenen Domäne abzugleichen, auch wenn dieser in einer anderen Site ist und in der eigenen Site noch ein weiterer DC ist.
Bei der Auswahl anderen DC als den PDC berücksichtigt er höchstwahrscheinlich die Konfiguration der Standortverknüpfungen. Das kann ich jetzt nicht schwören, aber es würde mich sehr wundern, wenn dem nicht so wäre.
Moin Emeriks,
Moin Icer,
es ist schon spät und meine Laune ist heute auch nicht die beste, deshalb kürze ich den Spuck etwas ab.
Wollt ihr mir gerade tatsächlich weis machen, dass eine Konfiguration die einen SPOF produziert, in der heutigen Zeit tatsächlich sinnvoll ist.
Wenn Ihr alles nach Handbuch die Pyramide nach oben konfiguriert, was passiert den genau, wenn die Spitze (der Zeitserver des obersten PDC's) mal nicht so läuft wie er sollte?
Und dann bitte nachdenken, was bei meinem Konzept passieren würde. 😉
Grüsse aus BaWü
Alex
Moin Icer,
es ist schon spät und meine Laune ist heute auch nicht die beste, deshalb kürze ich den Spuck etwas ab.
Wollt ihr mir gerade tatsächlich weis machen, dass eine Konfiguration die einen SPOF produziert, in der heutigen Zeit tatsächlich sinnvoll ist.
Wenn Ihr alles nach Handbuch die Pyramide nach oben konfiguriert, was passiert den genau, wenn die Spitze (der Zeitserver des obersten PDC's) mal nicht so läuft wie er sollte?
Und dann bitte nachdenken, was bei meinem Konzept passieren würde. 😉
Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Wenn Ihr alles nach Handbuch die Pyramide nach oben konfiguriert, was passiert den genau, wenn die Spitze (der Zeitserver des obersten PDC's) mal nicht so läuft wie er sollte?
Und dann bitte nachdenken, was bei meinem Konzept passieren würde. 😉
Wenn Ihr alles nach Handbuch die Pyramide nach oben konfiguriert, was passiert den genau, wenn die Spitze (der Zeitserver des obersten PDC's) mal nicht so läuft wie er sollte?
Und dann bitte nachdenken, was bei meinem Konzept passieren würde. 😉
Deine User wissen trotzdem, wie spät es ist, die Kerberus-Tickets werden ungültig. Deine Pyramide bröckelt von oben.
Grüße
lcer
Moin Emeriks
Moin Icer,
ihr habt meine schlechte Laune nicht verschuldet, zusätzlich etwas angeheizt ja, aber eben nicht verschuldet
und deshalb sollte ich diese auch nicht an euch auslassen, sorry.
Ich würde nun folgend das was ich kurz angerissen habe auch gerne fachlich darstellen.
MS Standard NTP Konzept:
Fuchsisches NTP Konzept:
in der heutigen Welt ist es nicht mehr wichtig, dass man nur eine Synchrone Zeit innerhalb seines eigenen Forests hat, sondern eher, das diese synchron mit dem Rest der Welt ist, sprich Azure, Homeofficeclients, Partnernetzwerke die per Site to Site angebunden sind, u.s.w.
Daher betrachte ich persönlich, das etwas zu hierarchische Standartkonzept von MS als etwas unzeitgemäss. 🤪
Grüsse aus BaWü
Alex
Moin Icer,
ihr habt meine schlechte Laune nicht verschuldet, zusätzlich etwas angeheizt ja, aber eben nicht verschuldet
und deshalb sollte ich diese auch nicht an euch auslassen, sorry.
Ich würde nun folgend das was ich kurz angerissen habe auch gerne fachlich darstellen.
MS Standard NTP Konzept:
Fuchsisches NTP Konzept:
in der heutigen Welt ist es nicht mehr wichtig, dass man nur eine Synchrone Zeit innerhalb seines eigenen Forests hat, sondern eher, das diese synchron mit dem Rest der Welt ist, sprich Azure, Homeofficeclients, Partnernetzwerke die per Site to Site angebunden sind, u.s.w.
Daher betrachte ich persönlich, das etwas zu hierarchische Standartkonzept von MS als etwas unzeitgemäss. 🤪
Grüsse aus BaWü
Alex
Moin Icer,
Ne, die fuchsische NTP-Pyramide bröckelt eben nicht wenn die Spitze mal einen knacks abbekommen sollte. 😉😀
Grüsse aus BaWü
Alex
Deine User wissen trotzdem, wie spät es ist, die Kerberus-Tickets werden ungültig. Deine Pyramide bröckelt von oben.
Ne, die fuchsische NTP-Pyramide bröckelt eben nicht wenn die Spitze mal einen knacks abbekommen sollte. 😉😀
Grüsse aus BaWü
Alex
Moin Emeriks,
Du meinst bestimmt das hier.
https://docs.microsoft.com/en-us/windows-server/networking/windows-time- ...
Gruss Alex
Zitat von @emeriks:
Andere DC.
Wenn ein DC selbst der PDC einer der weiteren Domänen einer Gesamtstruktur ist, dann versucht sich dieser PDC mit dem PDC der Stammdomäne abzugleichen. Wenn dieser nicht erreichbar ist, dann mit einem anderen DC der Stammdomäne. Egal an welcher Site diese sind.
Wenn ein DC selbst nicht der PDC ist, dann versucht er sich mit PDC der eigenen Domäne abzugleichen, auch wenn dieser in einer anderen Site ist und in der eigenen Site noch ein weiterer DC ist.
Bei der Auswahl anderen DC als den PDC berücksichtigt er höchstwahrscheinlich die Konfiguration der Standortverknüpfungen. Das kann ich jetzt nicht schwören, aber es würde mich sehr wundern, wenn dem nicht so wäre.
Andere DC.
Wenn ein DC selbst der PDC einer der weiteren Domänen einer Gesamtstruktur ist, dann versucht sich dieser PDC mit dem PDC der Stammdomäne abzugleichen. Wenn dieser nicht erreichbar ist, dann mit einem anderen DC der Stammdomäne. Egal an welcher Site diese sind.
Wenn ein DC selbst nicht der PDC ist, dann versucht er sich mit PDC der eigenen Domäne abzugleichen, auch wenn dieser in einer anderen Site ist und in der eigenen Site noch ein weiterer DC ist.
Bei der Auswahl anderen DC als den PDC berücksichtigt er höchstwahrscheinlich die Konfiguration der Standortverknüpfungen. Das kann ich jetzt nicht schwören, aber es würde mich sehr wundern, wenn dem nicht so wäre.
Du meinst bestimmt das hier.
https://docs.microsoft.com/en-us/windows-server/networking/windows-time- ...
Gruss Alex
Hallo nochmal,
in diesem Konzept kann mal also durch manipulieren eines NTP-Servers den damit gefütterten DC aus der Domäne kicken. Gerade wenn Du mit Azure und Homeoffice argumentierst, solltest Du auch über Angriffsszenarien nachdenken.
Grüße
lcer
in diesem Konzept kann mal also durch manipulieren eines NTP-Servers den damit gefütterten DC aus der Domäne kicken. Gerade wenn Du mit Azure und Homeoffice argumentierst, solltest Du auch über Angriffsszenarien nachdenken.
Grüße
lcer
Moin Zusammen,
der Vollständigkeit halber würde ich noch die folgende Empfehlung loswerden.
Bei allen Domainmember (Clients), die auch ausserhalb des internen Netzwerks benutzt werden, sprich Notebooks von Aussendienstmitarbeitern oder Homeoffice Arbeitsplätzen u.s.w würde ich wärmstens empfehlen die Zeit Synchronisation folgend anzupassen.
So ist sichergestellt, dass sich die Clients innerhalb des internen Netwerks, die Zeit von den DC holen und ausserhalb des internen Netzwerks würden sich diese die Zeit dann eben von einem dedizierten (vertrauenswürdigen) externen Zeitserver holen.
Grüsse aus BaWü
Alex
der Vollständigkeit halber würde ich noch die folgende Empfehlung loswerden.
Bei allen Domainmember (Clients), die auch ausserhalb des internen Netzwerks benutzt werden, sprich Notebooks von Aussendienstmitarbeitern oder Homeoffice Arbeitsplätzen u.s.w würde ich wärmstens empfehlen die Zeit Synchronisation folgend anzupassen.
w32tm /config /manualpeerlist:"ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de" /syncfromflags:all /update So ist sichergestellt, dass sich die Clients innerhalb des internen Netwerks, die Zeit von den DC holen und ausserhalb des internen Netzwerks würden sich diese die Zeit dann eben von einem dedizierten (vertrauenswürdigen) externen Zeitserver holen.
Grüsse aus BaWü
Alex
Moin Icer,
aber selbstverständlich beachte ich auch die Möglichkeit eines eventuellen Angriffszenarios und deshalb habe ich überall auch nur die folgenden NTP Quellen verwendet "ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de".
Möchtest du nun etwa behaupten, dass diese nicht vertrauenswürdig sind?
Ausserdem konfiguriere ich auch mal solche Sachen. 😉
Grüsse aus BaWü
Alex
P.S. und nein, da kommt später keine ANY ANY ALLOW dahinter. 🙃
in diesem Konzept kann mal also durch manipulieren eines NTP-Servers den damit gefütterten DC aus der Domäne kicken. Gerade wenn Du mit Azure und Homeoffice argumentierst, solltest Du auch über Angriffsszenarien nachdenken.
aber selbstverständlich beachte ich auch die Möglichkeit eines eventuellen Angriffszenarios und deshalb habe ich überall auch nur die folgenden NTP Quellen verwendet "ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de".
Möchtest du nun etwa behaupten, dass diese nicht vertrauenswürdig sind?
Ausserdem konfiguriere ich auch mal solche Sachen. 😉
Grüsse aus BaWü
Alex
P.S. und nein, da kommt später keine ANY ANY ALLOW dahinter. 🙃
Moin Icer und natürlich auch alle Anderen,
es wird nun Zeit für den krönenden Abendabschluss. 😎
Wenn man auf dem obersten PDC das folgende ausführt (muss eh gemacht werden).
und auf allen anderen PDC's und oder DC's das folgende
Dann hat man praktisch das folgende Umgesetzt.
Also sowohl die Standardmethode vom MS als auch die Fuchsische gleichzeitig, sprich irgendwie mit SPOF (
Single Point of Failure) und gleichzeitig auch irgendwie ohne. 🤪
Wünsche allen eine entspannte und erholsame Nacht.
Alex
es wird nun Zeit für den krönenden Abendabschluss. 😎
Wenn man auf dem obersten PDC das folgende ausführt (muss eh gemacht werden).
w32tm /config /manualpeerlist:"ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de" /syncfromflags:manual /reliable:yes /update und auf allen anderen PDC's und oder DC's das folgende
w32tm /config /manualpeerlist:"ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de" /syncfromflags:all /reliable:yes /update Dann hat man praktisch das folgende Umgesetzt.
Also sowohl die Standardmethode vom MS als auch die Fuchsische gleichzeitig, sprich irgendwie mit SPOF (
Single Point of Failure) und gleichzeitig auch irgendwie ohne. 🤪
Wünsche allen eine entspannte und erholsame Nacht.
Alex
Bei diesem Verfahren geht es einzig und allein darum, dass man innerhalb des AD (dazu gehören DC's, Member und sonstige Kerberos-Clients) eine einheitliche Zeit hat. Nicht darum, die "richtige" Zeit zu haben.
Und: Wenn schon, denn schon.
Wenn man sich weitestmöglich gegen externe Ausfälle absichern willst, dann sollten die externen Redundanzen auch vollkommen unabhängig von einander sein. Dann macht also die Angabe mehrerer verschiedener NTP-Server vom selben Anbieter recht wenig Sinn. Wenn, dann sollte man alles ausschließen bzw. redundant genug halten. Sonst kann immer irgendjemand Schlaumeier spielen und von sich behaupten, die sicherste Variante der Welt zu haben.
- unabhängige Atomuhren (Betreiber, Anbieter)
- NTP-Server unabhängiger Anbieter
- auf verschiedenen Kontinenten
- in verschiedenen DNS-Domänen
- in verschiedenen Subnetzen
- über verschiedene Leitungen - also auch bei Dir Leitungen von verschiedenen, wirklich unabhängigen Anbietern
...
Wie weit will man das noch treiben? Irgendwo hast Du dann immer den SPOF.
Natürlich kann man das so machen, wie Du es beschrieben hast. Kein Thema. Das wird funktionieren. Aber ist das wirklich sicherer? Lohnt der Aufwand?
Beschreibe doch mal genau (detailliert!), was beim von Dir stilisierten SPOF alles passieren kann. Dann bewerte die einzelnen Szenarien und bewerte die nennenswerten Risiken, welche für Euch daraus bestehen. Und dann rechne den Aufwand gegen den Nutzen.
Noch was anderes:
Bei uns haben die DC gar keine Kontakt zum Internet. NULL! Und sie werden diesen auch nie bekommen. Nicht regulär, nicht bewusst und nicht freiwillig. Sie können sich also gar nicht über eine externe Zeitquelle abgleichen. Sie müssen sich über eine interne Quelle abgleichen.
Selbst der PDC unserer Stammdomäne gleicht sich über einen dedizierten, redundant gestalteten NTP-Server ab. Dieser NTP-Server holt sich die Zeit von externen Quellen.
Edit:
Du hast bei Deiner "Fuchsischen Methode" (als wenn Du der erste wärst, welcher darauf gekommen wäre ...) noch was vergessen:
Warum sollen sich alle anderen Geräte im Netz nicht auch direkt mit der externen Zeitquelle abgleichen? Wäre das nicht sehr inkonsequent, das dann nicht auch noch zu tun?
Und: Wenn schon, denn schon.
Wenn man sich weitestmöglich gegen externe Ausfälle absichern willst, dann sollten die externen Redundanzen auch vollkommen unabhängig von einander sein. Dann macht also die Angabe mehrerer verschiedener NTP-Server vom selben Anbieter recht wenig Sinn. Wenn, dann sollte man alles ausschließen bzw. redundant genug halten. Sonst kann immer irgendjemand Schlaumeier spielen und von sich behaupten, die sicherste Variante der Welt zu haben.
- unabhängige Atomuhren (Betreiber, Anbieter)
- NTP-Server unabhängiger Anbieter
- auf verschiedenen Kontinenten
- in verschiedenen DNS-Domänen
- in verschiedenen Subnetzen
- über verschiedene Leitungen - also auch bei Dir Leitungen von verschiedenen, wirklich unabhängigen Anbietern
...
Wie weit will man das noch treiben? Irgendwo hast Du dann immer den SPOF.
Natürlich kann man das so machen, wie Du es beschrieben hast. Kein Thema. Das wird funktionieren. Aber ist das wirklich sicherer? Lohnt der Aufwand?
Beschreibe doch mal genau (detailliert!), was beim von Dir stilisierten SPOF alles passieren kann. Dann bewerte die einzelnen Szenarien und bewerte die nennenswerten Risiken, welche für Euch daraus bestehen. Und dann rechne den Aufwand gegen den Nutzen.
Noch was anderes:
Bei uns haben die DC gar keine Kontakt zum Internet. NULL! Und sie werden diesen auch nie bekommen. Nicht regulär, nicht bewusst und nicht freiwillig. Sie können sich also gar nicht über eine externe Zeitquelle abgleichen. Sie müssen sich über eine interne Quelle abgleichen.
Selbst der PDC unserer Stammdomäne gleicht sich über einen dedizierten, redundant gestalteten NTP-Server ab. Dieser NTP-Server holt sich die Zeit von externen Quellen.
Edit:
Du hast bei Deiner "Fuchsischen Methode" (als wenn Du der erste wärst, welcher darauf gekommen wäre ...) noch was vergessen:
Warum sollen sich alle anderen Geräte im Netz nicht auch direkt mit der externen Zeitquelle abgleichen? Wäre das nicht sehr inkonsequent, das dann nicht auch noch zu tun?
Zitat von @emeriks:
Bei diesem Verfahren geht es einzig und allein darum, dass man innerhalb des AD (dazu gehören DC's, Member und sonstige Kerberos-Clients) eine einheitliche Zeit hat. Nicht darum, die "richtige" Zeit zu haben.
man lese auch https://docs.microsoft.com/de-de/windows-server/networking/windows-time- ...Bei diesem Verfahren geht es einzig und allein darum, dass man innerhalb des AD (dazu gehören DC's, Member und sonstige Kerberos-Clients) eine einheitliche Zeit hat. Nicht darum, die "richtige" Zeit zu haben.
Es gibt viele verschiedene Gründe, weshalb du eine genaue Zeit benötigen könntest. Der typische Fall für Windows ist Kerberos, bei dem eine Genauigkeit von 5 Minuten zwischen Client und Server erforderlich ist. Es gibt jedoch viele weitere Bereiche, die von der Zeitgenauigkeit betroffen sein können, dazu gehören:
- Behördliche Vorschriften wie:
- Genauigkeit von 50 ms für FINRA in den USA
- 1 ms ESMA (MiFID II) in der EU.
- Kryptografiealgorithmen
- Verteilte Systeme wie Cluster/SQL/Exchange und Document DBs
- Blockchain-Framework für Bitcoin-Transaktionen
- Verteilte Protokolle und Bedrohungsanalyse
- AD-Replikation
- Kartenzahlungsbranche (Payment Card Industry, PCI), zurzeit Genauigkeit von 1 SekundeZum Thema Vertrauenswürdigkeit der PTB. Es ist irrelevant ob dieser Institution vertraut. Relevant ist, ob die eingehenden NTP-Pakete vertrauenswürdig sind. Und die sind es für mich aus Sicht der AD-Domäne / Gesamtstruktur nicht. Das ändert sich auch durch das Nutzen von DNSSEC nicht. NTP ist angreifbar über to man-in-the-middle attacks. Du kannst natürlich fragen, ob die PTB Dir eine gesicherte VPN-Verbindung ermöglicht, durch die dann dein NTP läuft. Aber das alles nur damit der Fuchs recht hat?
Grüße
lcer
Moin Emeriks,
So weit, wie eben der Aufwand sinnvoll zu dem Nutzen steht.
Ja, und ich treibe diesen nicht aus Spass, sondern weil sich die Standardmethode bei vielen Kundensystemen als nicht mehr zuverlässig erwiesen hat.
Kein Problem, gehen wir von einer flachen Domänenstruktur mit nur einer Hauptdomäne aus, die so > 90% aller kleinen und mittelständischen Betriebe im Normalfall betreiben. Hier befinden sich je nach gösse 2-4 DCs. Für die Umstellung dieser benötige ich incl. VPN und RDP Aufbaus weniger wie 15 Minuten, vor Ort würde es sogar noch schneller gehen.
Ich habe erst vor Kurzem einen Kunden stundenlang unterstützen müssen, weil seine internen Zeiten der DCs auseinandergelaufen sind, weil der Zeitserver des PDCs einen Schuss hatte. Die virtualisierten Server sind ohne Aktualisierungsmöglichkeit innerhalb von wenigen Stunden um mehr als 5 Minuten auseinandergelaufen (bekanntes Problem bei virtuellen DCs). Intern hat so gut wie nichts mehr funktioniert. Datenbanken waren nicht mehr ansprechbar, Outlook versagte den Dienst u.s.w.. Der Kundenadmin war sehr verzweifelt und berichtete mir, dass er dieses Problem in der Vergangenheit schon öfters gehabt habe. Ich habe bei der Aktion mitunter die Zeitsynchronisation auf die oben beschriebene Methode umgestellt und seit dem sind bei diesem Kunden alle Zeiten der DCs und auch der Clients absolut synchron, sowohl intern gesehen als auch gegen externe Zeitgeber.
Und was spricht dagegen?
Ob deine (P)DC's sich die Zeit von einer internen NTP Quelle holen, die wiederum die Zeit auch nur von einer externen Quelle besorgt, oder ob die sich direkt an der externen quelle bedienen ist doch am Ende des Tages gehopft wie gesprungen.
Kannst du mir bei der Gelegenheit erklären, wie gemäss der oben abgebildeten Firewallregel ein mögliches Angriffsszenario aussehen könnte?
Ohh, möchtest du mir jetzt etwa selbst bestätigen, dass es auch andere gibt, die dasselbe Vorgehen als sinnvoll ansehen?
Das ist richtig und als Failover gibt es meiner Ansicht nach auch keinen sinnvollen Grund dagegen.
Ich wollte mit diesem Vorschlag, dir und Icer zugute, es gestern Abend bloss nicht mehr übertreiben aber jetzt hast du es ja schon selbst erwähnt. 😉
Grüsse aus BaWü
Alex
Und: Wenn schon, denn schon.
Wenn man sich weitestmöglich gegen externe Ausfälle absichern willst, dann sollten die externen Redundanzen auch vollkommen unabhängig von einander sein. Dann macht also die Angabe mehrerer verschiedener NTP-Server vom selben Anbieter recht wenig Sinn. Wenn, dann sollte man alles ausschließen bzw. redundant genug halten. Sonst kann immer irgendjemand Schlaumeier spielen und von sich behaupten, die sicherste Variante der Welt zu haben.
- unabhängige Atomuhren (Betreiber, Anbieter)
- NTP-Server unabhängiger Anbieter
- auf verschiedenen Kontinenten
- in verschiedenen DNS-Domänen
- in verschiedenen Subnetzen
- über verschiedene Leitungen - also auch bei Dir Leitungen von verschiedenen, wirklich unabhängigen Anbietern
...
Wie weit will man das noch treiben? Irgendwo hast Du dann immer den SPOF.
Wenn man sich weitestmöglich gegen externe Ausfälle absichern willst, dann sollten die externen Redundanzen auch vollkommen unabhängig von einander sein. Dann macht also die Angabe mehrerer verschiedener NTP-Server vom selben Anbieter recht wenig Sinn. Wenn, dann sollte man alles ausschließen bzw. redundant genug halten. Sonst kann immer irgendjemand Schlaumeier spielen und von sich behaupten, die sicherste Variante der Welt zu haben.
- unabhängige Atomuhren (Betreiber, Anbieter)
- NTP-Server unabhängiger Anbieter
- auf verschiedenen Kontinenten
- in verschiedenen DNS-Domänen
- in verschiedenen Subnetzen
- über verschiedene Leitungen - also auch bei Dir Leitungen von verschiedenen, wirklich unabhängigen Anbietern
...
Wie weit will man das noch treiben? Irgendwo hast Du dann immer den SPOF.
So weit, wie eben der Aufwand sinnvoll zu dem Nutzen steht.
Natürlich kann man das so machen, wie Du es beschrieben hast. Kein Thema. Das wird funktionieren. Aber ist das wirklich sicherer? Lohnt der Aufwand?
Ja, und ich treibe diesen nicht aus Spass, sondern weil sich die Standardmethode bei vielen Kundensystemen als nicht mehr zuverlässig erwiesen hat.
Beschreibe doch mal genau (detailliert!), was beim von Dir stilisierten SPOF alles passieren kann. Dann bewerte die einzelnen Szenarien und bewerte die nennenswerten Risiken, welche für Euch daraus bestehen. Und dann rechne den Aufwand gegen den Nutzen.
Kein Problem, gehen wir von einer flachen Domänenstruktur mit nur einer Hauptdomäne aus, die so > 90% aller kleinen und mittelständischen Betriebe im Normalfall betreiben. Hier befinden sich je nach gösse 2-4 DCs. Für die Umstellung dieser benötige ich incl. VPN und RDP Aufbaus weniger wie 15 Minuten, vor Ort würde es sogar noch schneller gehen.
Ich habe erst vor Kurzem einen Kunden stundenlang unterstützen müssen, weil seine internen Zeiten der DCs auseinandergelaufen sind, weil der Zeitserver des PDCs einen Schuss hatte. Die virtualisierten Server sind ohne Aktualisierungsmöglichkeit innerhalb von wenigen Stunden um mehr als 5 Minuten auseinandergelaufen (bekanntes Problem bei virtuellen DCs). Intern hat so gut wie nichts mehr funktioniert. Datenbanken waren nicht mehr ansprechbar, Outlook versagte den Dienst u.s.w.. Der Kundenadmin war sehr verzweifelt und berichtete mir, dass er dieses Problem in der Vergangenheit schon öfters gehabt habe. Ich habe bei der Aktion mitunter die Zeitsynchronisation auf die oben beschriebene Methode umgestellt und seit dem sind bei diesem Kunden alle Zeiten der DCs und auch der Clients absolut synchron, sowohl intern gesehen als auch gegen externe Zeitgeber.
Noch was anderes:
Bei uns haben die DC gar keine Kontakt zum Internet. NULL! Und sie werden diesen auch nie bekommen. Nicht regulär, nicht bewusst und nicht freiwillig. Sie können sich also gar nicht über eine externe Zeitquelle abgleichen. Sie müssen sich über eine interne Quelle abgleichen.
Selbst der PDC unserer Stammdomäne gleicht sich über einen dedizierten, redundant gestalteten NTP-Server ab. Dieser NTP-Server holt sich die Zeit von externen Quellen.
Bei uns haben die DC gar keine Kontakt zum Internet. NULL! Und sie werden diesen auch nie bekommen. Nicht regulär, nicht bewusst und nicht freiwillig. Sie können sich also gar nicht über eine externe Zeitquelle abgleichen. Sie müssen sich über eine interne Quelle abgleichen.
Selbst der PDC unserer Stammdomäne gleicht sich über einen dedizierten, redundant gestalteten NTP-Server ab. Dieser NTP-Server holt sich die Zeit von externen Quellen.
Und was spricht dagegen?
Ob deine (P)DC's sich die Zeit von einer internen NTP Quelle holen, die wiederum die Zeit auch nur von einer externen Quelle besorgt, oder ob die sich direkt an der externen quelle bedienen ist doch am Ende des Tages gehopft wie gesprungen.
Kannst du mir bei der Gelegenheit erklären, wie gemäss der oben abgebildeten Firewallregel ein mögliches Angriffsszenario aussehen könnte?
Edit:
Du hast bei Deiner "Fuchsischen Methode" (als wenn Du der erste wärst, welcher darauf gekommen wäre ...) noch was vergessen:
Du hast bei Deiner "Fuchsischen Methode" (als wenn Du der erste wärst, welcher darauf gekommen wäre ...) noch was vergessen:
Ohh, möchtest du mir jetzt etwa selbst bestätigen, dass es auch andere gibt, die dasselbe Vorgehen als sinnvoll ansehen?
Warum sollen sich alle anderen Geräte im Netz nicht auch direkt mit der externen Zeitquelle abgleichen?
Wäre das nicht sehr inkonsequent, das dann nicht auch noch zu tun?
Wäre das nicht sehr inkonsequent, das dann nicht auch noch zu tun?
Das ist richtig und als Failover gibt es meiner Ansicht nach auch keinen sinnvollen Grund dagegen.
Ich wollte mit diesem Vorschlag, dir und Icer zugute, es gestern Abend bloss nicht mehr übertreiben aber jetzt hast du es ja schon selbst erwähnt. 😉
Grüsse aus BaWü
Alex
Hi Icer,
Das kann schon sein, dass dich deine User nicht interessieren, aber die meisten Admin's die ich kenne, bemühen sich (zumindest meistens) schon die Probleme der User ernst zu nehmen und diesen auch zu helfen.
Vor allem das von dir oben beschriebene Szenarion, hat einigen Administratoren dieses Jahr dank Corona und Homeoffice mitunter sehr überraschend neue und nicht umspannende Herausforderungen gebracht. Schick mal ein paar hundert User von heute auf morgen ins Homeoffice, ohne dass du vorher sichergestellt hast, dass die für das Homeoffice verwendeten Clients Ihre Zeit auch ohne ständig mit der Domäne verbunden zu sein noch sauber synchronisieren. Wenn du Erfahrung in diesem Bereich hast, dann wirst du dir die Folgen recht schnell selbst ausmahlen können. 😉
Aha ... 😦🥴😧
Relevant ist also nur, dass die eingehenden NTP-Pakete vertrauenswürdig sind, nicht aber, dass die Quelle dieser Pakete es selbst ist.
Kannst du das bitte etwas genauer erklären, ich komme da irgendwie nicht so ganz mit.
Warum sollte ich zwischen mir (Standort in Deutschland) und PTB (Standort in Deutschland) für einen Zeitabgleich ein VPN Augbauen?
Kannst du mir bitte genauer erklären, wie hier das mögliche "man-in-the-middle" Szenario aussehen könnte?
Grüsse aus BaWü
Alex
Die meisten Gründe haben etwas mit kryptographischer Absicherung zu tun. Da interessiert mich kein Laptop-User im Homeopffice, der 1x in 10 Jahren vielleicht erst seine Uhr stellen muss um sich verbinden zu können.
Das kann schon sein, dass dich deine User nicht interessieren, aber die meisten Admin's die ich kenne, bemühen sich (zumindest meistens) schon die Probleme der User ernst zu nehmen und diesen auch zu helfen.
Vor allem das von dir oben beschriebene Szenarion, hat einigen Administratoren dieses Jahr dank Corona und Homeoffice mitunter sehr überraschend neue und nicht umspannende Herausforderungen gebracht. Schick mal ein paar hundert User von heute auf morgen ins Homeoffice, ohne dass du vorher sichergestellt hast, dass die für das Homeoffice verwendeten Clients Ihre Zeit auch ohne ständig mit der Domäne verbunden zu sein noch sauber synchronisieren. Wenn du Erfahrung in diesem Bereich hast, dann wirst du dir die Folgen recht schnell selbst ausmahlen können. 😉
Zum Thema Vertrauenswürdigkeit der PTB. Es ist irrelevant ob dieser Institution vertraut. Relevant ist, ob die eingehenden NTP-Pakete vertrauenswürdig sind. Und die sind es für mich aus Sicht der AD-Domäne / Gesamtstruktur nicht.
Aha ... 😦🥴😧
Es ist irrelevant ob dieser Institution vertraut. Relevant ist, ob die eingehenden NTP-Pakete vertrauenswürdig sind.
Relevant ist also nur, dass die eingehenden NTP-Pakete vertrauenswürdig sind, nicht aber, dass die Quelle dieser Pakete es selbst ist.
Kannst du das bitte etwas genauer erklären, ich komme da irgendwie nicht so ganz mit.
Das ändert sich auch durch das Nutzen von DNSSEC nicht. NTP ist angreifbar über to man-in-the-middle attacks. Du kannst natürlich fragen, ob die PTB Dir eine gesicherte VPN-Verbindung ermöglicht, durch die dann dein NTP läuft. Aber das alles nur damit der Fuchs recht hat?
Warum sollte ich zwischen mir (Standort in Deutschland) und PTB (Standort in Deutschland) für einen Zeitabgleich ein VPN Augbauen?
Kannst du mir bitte genauer erklären, wie hier das mögliche "man-in-the-middle" Szenario aussehen könnte?
Grüsse aus BaWü
Alex
oder ob die sich direkt an der externen quelle bedienen ist doch am ende des Tages gehopft wie gesprungen.
Nein, ist es nicht.Ich betrachte jede nicht notwendige Sache einfach als zusätzliche potentielle Fehlerquelle. Sei es technischer, organisatorischer oder menschlicher Art.
Ohh, möchtest du mir jetzt etwa selbst bestätigen, dass es auch andere gibt, die dasselbe Vorgehen als sinnvoll ansehen?
Ich kenne niemanden, der das so macht. Und selbst wenn es jemand so machen würde, hätte ich kein Problem damit, Dir das hier so zu bestätigen. Oder was wolltest Du mit dieser Formulierung ausdrücken?Das ist richtig und als Failover gibt es meiner Ansicht nach auch keinen sinnvollen Grund dagegen.
Ich hätte welche: Kosten. Arbeitszeit. Und andere.Zu VM-Umgebung & DC's:
Ich kann nur sagen, dass wir seit über 10 Jahren fast vollständig auf virtualisierte Umgebungen bauen. Bis auf einen DC laufen alle anderen DC als VM (zig DC's). Fast alle Server als VM (hunderte). Auf verschiedenen Hypervisor-Host, in verschieden VM-Umgebungen, an verschiedenen Standorten. Und wir hatten (außer in der Anfangsphase vor zig Jahren, als die Admins dies bzgl. noch den handwerklichen Fehler mit der Uhrzeitübernahme von Host auf VM gemacht haben) noch nie das Problem, dass es im Zusammenhang mit der Virtualisierung zu einem generellen Problem der Uhrzeiten innerhalb der VM's gekommen ist.
Wenn es Deine Zeit zulässt und/oder Dir die Kunden das bezahlen: Mach!
Hallo,
Aha ... 😦🥴😧
Relevant ist also nur, dass die eingehenden NTP-Pakete vertrauenswürdig sind, nicht aber, dass die Quelle dieser Pakete es selbst ist.
Kannst du das bitte etwas genauer erklären, ich komme da irgendwie nicht so ganz mit.
Nicht nur Smileys, auch Rhetorisch bist Du richtig gut.
Warum sollte ich zwischen mir (Standort in Deutschland) und PTB (Standort in Deutschland) für einen Zeitabgleich ein VPN Augbauen?
Kannst du mir bitte genauer erklären, wie hier das mögliche "man-in-the-middle" Szenario aussehen könnte?
Alles klar, Du behältst immer recht. Und ein so großer Admin wie Du wird sicherlich nie Probleme bekommen.
Ich bin da jetzt raus. Und viel Spaß beim ständigen Überprüfen der DC Zeiten - ach nein, brauchst Du ja nicht, denn Du arbeitest ja Kundenorientiert und die haben kein Problem, solange nichts schiefgeht. Achso - wie konnte es da sein, dass da bei einem professionellen System keine sofort mitbekommen hat, dass der PDC einen Fehler hatte? Vermutlich nicht, weil da ja kein User am PDC sitzt, dessen Probleme man ernst nehmen könnte.
Grüße
lcer
Zitat von @MysticFoxDE:
Hi Icer,
Das kann schon sein, dass dich deine User nicht interessieren, aber die meisten Admin's die ich kenne, bemühen sich (zumindest meistens) schon die Probleme der User ernst zu nehmen und diesen auch zu helfen.
Vor allem das von dir oben beschriebene Szenarion, hat einigen Administratoren dieses Jahr dank Corona und Homeoffice mitunter sehr überraschend neue und nicht umspannende Herausforderungen gebracht. Schick mal ein paar hundert User von heute auf morgen ins Homeoffice, ohne dass du vorher sichergestellt hast, dass die für das Homeoffice verwendeten Clients Ihre Zeit auch ohne ständig mit der Domäne verbunden zu sein noch sauber synchronisieren. Wenn du Erfahrung in diesem Bereich hast, dann wirst du dir die Folgen recht schnell selbst ausmahlen können. 😉
Das ist eine Frage der Prioritäten. Deine Sicht kann ich da nicht teilen. Sicherheit und Komfort sehen einander im Weg, Für Mich ist Sicherheit wichtiger.Hi Icer,
Die meisten Gründe haben etwas mit kryptographischer Absicherung zu tun. Da interessiert mich kein Laptop-User im Homeopffice, der 1x in 10 Jahren vielleicht erst seine Uhr stellen muss um sich verbinden zu können.
Das kann schon sein, dass dich deine User nicht interessieren, aber die meisten Admin's die ich kenne, bemühen sich (zumindest meistens) schon die Probleme der User ernst zu nehmen und diesen auch zu helfen.
Vor allem das von dir oben beschriebene Szenarion, hat einigen Administratoren dieses Jahr dank Corona und Homeoffice mitunter sehr überraschend neue und nicht umspannende Herausforderungen gebracht. Schick mal ein paar hundert User von heute auf morgen ins Homeoffice, ohne dass du vorher sichergestellt hast, dass die für das Homeoffice verwendeten Clients Ihre Zeit auch ohne ständig mit der Domäne verbunden zu sein noch sauber synchronisieren. Wenn du Erfahrung in diesem Bereich hast, dann wirst du dir die Folgen recht schnell selbst ausmahlen können. 😉
Zum Thema Vertrauenswürdigkeit der PTB. Es ist irrelevant ob dieser Institution vertraut. Relevant ist, ob die eingehenden NTP-Pakete vertrauenswürdig sind. Und die sind es für mich aus Sicht der AD-Domäne / Gesamtstruktur nicht.
Aha ... 😦🥴😧
Es ist irrelevant ob dieser Institution vertraut. Relevant ist, ob die eingehenden NTP-Pakete vertrauenswürdig sind.
Relevant ist also nur, dass die eingehenden NTP-Pakete vertrauenswürdig sind, nicht aber, dass die Quelle dieser Pakete es selbst ist.
Kannst du das bitte etwas genauer erklären, ich komme da irgendwie nicht so ganz mit.
Das ändert sich auch durch das Nutzen von DNSSEC nicht. NTP ist angreifbar über to man-in-the-middle attacks. Du kannst natürlich fragen, ob die PTB Dir eine gesicherte VPN-Verbindung ermöglicht, durch die dann dein NTP läuft. Aber das alles nur damit der Fuchs recht hat?
Warum sollte ich zwischen mir (Standort in Deutschland) und PTB (Standort in Deutschland) für einen Zeitabgleich ein VPN Augbauen?
Kannst du mir bitte genauer erklären, wie hier das mögliche "man-in-the-middle" Szenario aussehen könnte?
Ich bin da jetzt raus. Und viel Spaß beim ständigen Überprüfen der DC Zeiten - ach nein, brauchst Du ja nicht, denn Du arbeitest ja Kundenorientiert und die haben kein Problem, solange nichts schiefgeht. Achso - wie konnte es da sein, dass da bei einem professionellen System keine sofort mitbekommen hat, dass der PDC einen Fehler hatte? Vermutlich nicht, weil da ja kein User am PDC sitzt, dessen Probleme man ernst nehmen könnte.
Grüße
lcer
Moin Emeriks,
Ich hätte auch welche.
Kosten (verursachte Datenpakete): < 0,001 % des Gesamten Datenverkehrs nach aussen, ist somit vollkommen irrelevant.
(Wenn intern die (P)DC's erreichbar sind, dann aktualisieren sich diese und auch die Clients durch das setzen des Parameters "/syncfromflags:all" weiterhin primär über die Domänenstruktur und als Failover über die manualpeerlist)
Arbeitszeit: DCs manuell umstellen < 15 Min, per GPO auch. Clients per GPO kleiner 15 Min., somit in Summe etwa 30 Min. was volkommen überschaubar ist.
Nachtrag: es kommen noch 15 Min. für die Konfiguration der FW dazu, auch das macht das Ganze nicht unüberschaubar.
Grüsse aus BaWü
Alex
Das ist richtig und als Failover gibt es meiner Ansicht nach auch keinen sinnvollen Grund dagegen.
Ich hätte welche: Kosten. Arbeitszeit. Und andere.Ich hätte auch welche.
Kosten (verursachte Datenpakete): < 0,001 % des Gesamten Datenverkehrs nach aussen, ist somit vollkommen irrelevant.
(Wenn intern die (P)DC's erreichbar sind, dann aktualisieren sich diese und auch die Clients durch das setzen des Parameters "/syncfromflags:all" weiterhin primär über die Domänenstruktur und als Failover über die manualpeerlist)
Arbeitszeit: DCs manuell umstellen < 15 Min, per GPO auch. Clients per GPO kleiner 15 Min., somit in Summe etwa 30 Min. was volkommen überschaubar ist.
Nachtrag: es kommen noch 15 Min. für die Konfiguration der FW dazu, auch das macht das Ganze nicht unüberschaubar.
Grüsse aus BaWü
Alex
Moin Icer,
Ah, nein, eine synchrone Zeit ist heutzutage sowohl innerhalb des intern Netzes extrem sicherheitsrelevant als auch gegenüber externen Netzen (WAN, Cloud & Co.KG). 😉
Der eine klagt, dass meine Methode zu aufwendig ist und der andere, dass diese zu komfortabel ist. Ich bin nun etwas verwirrt. 😵
Folgend empfiehlt VMware, auf allen Windows VMs, unabhängig davon ob (P)DC oder nicht, die Zeitsynchronisation über eine externe Zeitquelle zu realisieren.
https://kb.vmware.com/s/article/1318
Den folgenden Satz finde ich besonders spannend.
Von Rhetorik sind wir meinerseits noch weit entfernt, ich habe dir bisher, bis auf die eine oder andere spassige Untermalung immer sachlich und begründet geantwortet. Du hingegen, schaffst es schon zum x-ten Mal nicht, auf eine gezielt gestellte Frage, nicht ausweichen zu Antworten.
Weil die meisten Administratoren, Systemintegratoren, Securityexperten & Co absolut überlastet sind und es trotzt eines guten Willen nicht mehr schaffen, noch alles und immer im Auge zu behalten, auch und vor allem die guten. 😉
Grüsse aus BaWü
Alex
Das ist eine Frage der Prioritäten. Deine Sicht kann ich da nicht teilen. Sicherheit und Komfort sehen einander im Weg, Für Mich ist Sicherheit wichtiger.
Ah, nein, eine synchrone Zeit ist heutzutage sowohl innerhalb des intern Netzes extrem sicherheitsrelevant als auch gegenüber externen Netzen (WAN, Cloud & Co.KG). 😉
Der eine klagt, dass meine Methode zu aufwendig ist und der andere, dass diese zu komfortabel ist. Ich bin nun etwas verwirrt. 😵
Folgend empfiehlt VMware, auf allen Windows VMs, unabhängig davon ob (P)DC oder nicht, die Zeitsynchronisation über eine externe Zeitquelle zu realisieren.
https://kb.vmware.com/s/article/1318
Den folgenden Satz finde ich besonders spannend.
Nicht nur Smileys, auch Rhetorisch bist Du richtig gut.
Von Rhetorik sind wir meinerseits noch weit entfernt, ich habe dir bisher, bis auf die eine oder andere spassige Untermalung immer sachlich und begründet geantwortet. Du hingegen, schaffst es schon zum x-ten Mal nicht, auf eine gezielt gestellte Frage, nicht ausweichen zu Antworten.
Achso - wie konnte es da sein, dass da bei einem professionellen System keine sofort mitbekommen hat, dass der PDC einen Fehler hatte? Vermutlich nicht, weil da ja kein User am PDC sitzt, dessen Probleme man ernst nehmen könnte.
Weil die meisten Administratoren, Systemintegratoren, Securityexperten & Co absolut überlastet sind und es trotzt eines guten Willen nicht mehr schaffen, noch alles und immer im Auge zu behalten, auch und vor allem die guten. 😉
Grüsse aus BaWü
Alex
Eigentlich wollte ich nichts mehr dazu schreiben. Es scheint ja auch einfach nur eine Glaubensfrage zu sein. Jede/r, wie er/sie mag. Solange, wie es funktioniert, ist es doch gut. So oder so.
Aber wenn Du schon so damit winkst ...
--> Deine rote Markierung:
Bist Du des Englischen und Deutschen soweit mächtig, dass Du diesen Halbsatz auch inhaltlich wirklich verstehst?
Da steht nichts weiter, als dass das mit dem Weg über die Domänenhierarchie möglich ist, dies aber in "diesem BPA Guide" (dem von VMware) nicht weiter betrachtet/untersucht wird. So wie: Man kann auch bei Grün über die Ampel gehen, aber das betrachten wir in diesem Dokument nicht. Oder: Es ist möglich, bei Regen einen Regenschirm zu verwenden, um trocken zu bleiben, aber das interessiert uns gerade nicht. Oder: Das Auto kann auch mehr als 200 Km/h fahren, aber das ist für die Betrachtung des Anhebens des Autos mit einer Hebebühne nicht von Belang. Oder: .....
Frag 10 Fachleute und Du bekommst 12 Meinungen. Das war noch nie anders. Warum sollte es also bei irgendwelchen BPA's oder irgendwelchen Artikeln Dritter über das Wurmloch in Deinen Ansichten über die Zeit anders sein?
Aber wenn Du schon so damit winkst ...
--> Deine rote Markierung:
Bist Du des Englischen und Deutschen soweit mächtig, dass Du diesen Halbsatz auch inhaltlich wirklich verstehst?
Da steht nichts weiter, als dass das mit dem Weg über die Domänenhierarchie möglich ist, dies aber in "diesem BPA Guide" (dem von VMware) nicht weiter betrachtet/untersucht wird. So wie: Man kann auch bei Grün über die Ampel gehen, aber das betrachten wir in diesem Dokument nicht. Oder: Es ist möglich, bei Regen einen Regenschirm zu verwenden, um trocken zu bleiben, aber das interessiert uns gerade nicht. Oder: Das Auto kann auch mehr als 200 Km/h fahren, aber das ist für die Betrachtung des Anhebens des Autos mit einer Hebebühne nicht von Belang. Oder: .....
Frag 10 Fachleute und Du bekommst 12 Meinungen. Das war noch nie anders. Warum sollte es also bei irgendwelchen BPA's oder irgendwelchen Artikeln Dritter über das Wurmloch in Deinen Ansichten über die Zeit anders sein?
