Zeitprobleme in Domäne und Windows 10

[Marco31 33]

Ja, das stimmt. Blöderweise konnte es aber offensichtlich noch niemand lokalisieren

[doc_jochim 0]

Hallo,

 

so'n shice...!

 

Zu früh gefreut. An dem Rechner, an dem ich angefangen habe, die W32time-Einstellungen so wie oben von mir beschrieben zurückzusetzen, gab es heute dann doch wieder einen Zeitsprung. Diesmal aber nicht auf das Installationsdatum des W10-Updates (bei mir sind die Pro-Versionen installiert), sondern auf das Datum, an dem ich den Zeitdienst de- und wieder neu registriert habe

 

:confused:

 

Warum nur?

 

Ich hatte vor dem ersten Zurücksetzen des Zeitgeber-Dienstes an den betroffenen clients mal debug-log-files vom Zeitgeberdienst geschrieben. Die dazugehörigen Dateien habe ich mal hier hinterlegt. Für mich ist das nur Chinesisch, aber vielleicht kann jemand von Euch daraus etwas erkennen?

 

André

[blub 115]

Ist mir grad zufällig über den Bildschirm gelaufen

https://support.microsoft.com/en-us/kb/816043

 

 

the highest possible value is 0-300 for most detailed logging

vielleicht gibt es einen Hinweis auf betroffenen Maschinen

[Forseti2003 14]

mal ganz doof zwischengefragt, kann es sein das die User eine andere Zeitzone bei sich haben und daher der Client bei der Anmeldung nachträglich auf eine andere Zeit springt?

[doc_jochim 0]

Ist mir grad zufällig über den Bildschirm gelaufen

https://support.microsoft.com/en-us/kb/816043

 

vielleicht gibt es einen Hinweis auf betroffenen Maschinen

 

Ich hatte oben doch bereits geschrieben, daß ich debug-logfiles erstellt habe und den link zu den files gepostet. Genau so wurde das debug-logging aktiviert. Am einfachsten ist es aber, wenn man sich eine kurze Batchdatei zum Einschalten des debug-loggings erstellt und eine zu Ausschalten:

 

ON.bat:

w32tm /debug /enable /file:C:\windows\temp\w32time.log /size:10000000 /entries:0-300

 

OFF.bat:

w32tm /debug /disable

 

Damit werden dann automatisch (als Administrator ausführen) die beschriebenen Reg-Einträge erstellt bzw. wieder aus der Registry herausgenommen.

 

 

Aber ich selbst kann mit den logfiles nicht wirklich etwas anfangen.

 

 

mal ganz doof zwischengefragt, kann es sein das die User eine andere Zeitzone bei sich haben und daher der Client bei der Anmeldung nachträglich auf eine andere Zeit springt?

 

So doof ist das doch gar nicht. Aber es ist leider nicht so. Die Zeitzone ist die Gleiche. Außerdem würde dann sicher nur die Uhrzeit um ganze Stunden versetzt werden und nicht gleich das Datum einen großen Sprung machen, zusammen mit einer Uhrzeit, die nicht um ganze Stunden verschoben ist.

 

André

[blub 115]

was du unter "debug-logfiles" verstehst, solltest du dann auch dazu schreiben.

 

Ich habe mir mal dein Logfile angesehen:

 

Diese Zeilen wiederholen sich laufend:

 

151743 07:29:20.1419347s - Sample Prepared at 131106221601419282 for peer XP1.Praxis.local (ntp.d|0.0.0.0:123->192.168.200.52:123)

 

151743 07:44:20.1739824s - Secure Time value is of low confidence and cannot be used for time comparisons.
151743 07:44:20.1739958s - System clock not modified
151743 07:46:09.2445818s - PeerPollingThread: WaitTimeout
151743 07:46:09.2446297s - Polling peer XP1.Praxis.local (ntp.d|0.0.0.0:123->192.168.200.52:123)

 

 

wenn du dann hier liest:

https://technet.microsoft.com/en-us/library/cc773013.aspx

-> NTP Security

 

würde ich auf die Schnelle sagen, dass es zwischen Client und Zeitserver "192.168.200.52" ein Kerberosproblem gibt.

[doc_jochim 0]

würde ich auf die Schnelle sagen, dass es zwischen Client und Zeitserver "192.168.200.52" ein Kerberosproblem gibt.

 

Hmmm... - kommen die Kerberos-Probleme denn nicht immer erst dann, wenn der Zeitsprung stattgefunden hat? Dann wäre es ja klar, daß hier eine Kommunikation wegen eines total falschen Zeitstempels nicht mehr möglich ist. Dann kann ich nämlich auch von anderen Clients aus bei den in die Vergangenheit gefallenen Clients nicht mehr auf die administrativen Freigaben der Laufwerke zugreifen.

 

Immer kehren auch die folgende Zeilen wieder:

 

 

Setting the system time because it is outside the secure time limits.

Current system time:  9:44:57.850 6/17/2016

Target system time:  12:6:57.556 6/1/2016

 

 

 

Und danach gibt es im Debug-Logfile (wie heisst denn das Ding nun richtig?) immer den Zeitsprung. Und - wie man erkennen kann - immer auf das gleiche Datum und die gleiche Uhrzeit. Nur woher nimmt der Rechner denn dieses immer wiederkehrende Ziel?

 

Sind die Kerberos-Probleme denn dann der Grund oder die Folge der Zeitsprünge?

 

Secure Time value is of low confidence and cannot be used for time comparisons

 

 

Warum vertraut der Client denn dem Server nicht?

 

Ich habe am Server jetzt nochmal 'w32tm /config /reliable:yes' eingegeben. Mal sehen, ob die Fehler jetzt immer noch auftreten.

 

André

[Weingeist 159]

Fragt sich, ob er die Zeit von extern oder intern bekommt. Würde mich nicht wundern bei W10, dass irgend nen Quatsch zu MS nach Hause telefoniert weil es ja bei älteren OS kein Problem ist wenn es korrekt konfiguriert wurde.

 

Da alles ins leere führt, würde ich mal die Firewall auf Port UDP 123 (Time Service) auf den internen DC limitieren. In und Out Kommunikation. So kannst Du ausschliessen, dass auf regulärem Wege etwas auf deinen Client von extern kommt.

Sowie dann evtl. beides protokollieren lassen. Entweder das extensive logging per Kommandozeile oder eben das schlichte innerhalb der Firewall.

bearbeitet 1. Juli 2016 von Weingeist

[doc_jochim 0]

Fragt sich, ob er die Zeit von extern oder intern bekommt.

 

Die Frage lässt sich ganz einfach beantworten: Unser Netz ist eine kleine glückliche Insel ohne irgendeine Verbindung nach draußen. Kein Stecker, kein Kabel, kein WLAN. Also von außen kann hier niemand seine Zeit beziehen.

 

Der DHCP-Server ist so konfiguriert, daß die Clients auch keinen Standard-Gateway zugewiesen bekommen. Das Feld ist leer.

 

Wollen die Clients hier partout nach draußen und beschweren sich dann, wenn es nicht geht? Wird Win10 wild, wenn es eingesperrt wird?

 

André

[Nobbyaushb 1.472]

Wie kommen denn Mails auf die Insel, mit ´ner Brieftaube?

 

Und die Updates?

 

;)

[blub 115]

Sind die Kerberos-Probleme denn dann der Grund oder die Folge der Zeitsprünge?

Kannst du auf einem Client, bei dem das Problem auftritt,  ein Log ziehen,

a) wenn er keinen Zeitsprung hat. (ca. 24h)

dann versuchen, den Zeitsprung in einem zweiten Log einzufangen. Vielleicht kannst du den Zeitpunkt des Sprungs zusätzlich noch etwas eingrenzen, dann tut man sich bei der Auswertung leichter und kann deine Frage beantworten.

[Weingeist 159]

Also wenn das auch in abgeschotteten Umgebungn auftritt, tippe ich auf Authentifizierungsprobleme mit einem unsäglichen "Korrekturverhalten" das gegen DC läuft oder aber W10 hat zwischendurch das Bedürfnis sich eben doch extern abzugleichen mit höherer Prio als DC wobei DC gar nicht mehr gefragt wird.

Ist also extern nicht erreichbar, wird eben die Zeit auf irgendwas das von der Bios-Zeit abhängig ist (evtl. Redmonder Zeitverschiebung, abweichung zu Bios jeweils identisch?) anstelle DC genommen oder sonst auf irgend Zeit gestellt. Irgendwoher muss er diese ja haben.

 

Würde nach wie vor mal das Security Journaling einschalten um herauszufinden ob indem moment eine externe Anfrage läuft oder nicht. Aufgrund des Zeitstempels im Security-Log siehst dann auch gleich wo es Zeitsprünge gab und was auf welchem Port an die Kiste angekomen ist, raus ging bzw. raus wollte.

 

Eventuell reichen die verworfenen Pakete schon aus. Ansonsten eben alles loggen. Würde mal damit beginnen.

Einschalten: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:disable /failure:enable

 

Tipp: Schreibe dir immer auf was du mit Auditpol aktivierst/deaktivierst. Damit Du nachher wieder weisst wie Du es abschalten kannst. Sonst wird Dein Log unter Umständen ohne Ende geflutet. ;)

 

Wenn es von extern kommt bzw. nahc extern geht via UDP 123 kannst vor Auditpol auch mit dem normalen Firewall-Journaling prüfen ob da Pakete im Success oder Failure raus oder reingehen. Mit Auditpol hast den Vorteil, dass eben die Prozesse auch mitgeliefert werden, nicht nur Adressen. Diese findest dann wiederum mit der Tasklist in ner Kommandozeile (sofern sie noch laufen - was sie tun wenn es sich um Dienste handelt).

bearbeitet 2. Juli 2016 von Weingeist

[doc_jochim 0]

Wie kommen denn Mails auf die Insel, mit ´ner Brieftaube?

 

Und die Updates?

 

;)

 

Auf dem System laufen keine Programme, die eine Anbindung nach draußen brauchen. Keine Mails, keine Brieftauben. Für Updates wird zwischendurch mal eine LAN-Verbindung zur Fritz!Box erstellt und die Updates eingespielt.

 

Kannst du auf einem Client, bei dem das Problem auftritt,  ein Log ziehen,

a) wenn er keinen Zeitsprung hat. (ca. 24h)

dann versuchen, den Zeitsprung in einem zweiten Log einzufangen. Vielleicht kannst du den Zeitpunkt des Sprungs zusätzlich noch etwas eingrenzen, dann tut man sich bei der Auswertung leichter und kann deine Frage beantworten.

 

Das Logfile hatte ich doch erstellt und wie hier geschrieben dort zum Herunterladen bereitgestellt.Allerdings nicht 24h ohne Zeitsprung, da die Zeitsprünge mehrfach täglich auftraten. Mit meinem Batchfile habe ich auch die zugehörigen Zeitpunkte protokolliert und in einem Textfile abgespeichert (Allerdings stehen im Debugging-Log des Zeitdienstes die Uhrzeiten ohne Berücksichtigung der Zeitzone und sind im Verhältnis zu den abgespeicherten Zeitpunkten um 2h verschoben)

 

Also wenn das auch in abgeschotteten Umgebungn auftritt, tippe ich auf Authentifizierungsprobleme mit einem unsäglichen "Korrekturverhalten" das gegen DC läuft oder aber W10 hat zwischendurch das Bedürfnis sich eben doch extern abzugleichen mit höherer Prio als DC wobei DC gar nicht mehr gefragt wird.

Ist also extern nicht erreichbar, wird eben die Zeit auf irgendwas das von der Bios-Zeit abhängig ist (evtl. Redmonder Zeitverschiebung, abweichung zu Bios jeweils identisch?) anstelle DC genommen oder sonst auf irgend Zeit gestellt. Irgendwoher muss er diese ja haben.

 

Das komische ist ja, daß die Zeit / das Datum nicht auf einen im bestimmten Verhältnis zum Bios oder zu der Systemzeit stehenden Zeitpunkt verschoben wird, sondern immer auf den gleichen fixen Zeitpunkt gesetzt wird.

 

 

Würde nach wie vor mal das Security Journaling einschalten um herauszufinden ob indem moment eine externe Anfrage läuft oder nicht. Aufgrund des Zeitstempels im Security-Log siehst dann auch gleich wo es Zeitsprünge gab und was auf welchem Port an die Kiste angekomen ist, raus ging bzw. raus wollte.

 

Eventuell reichen die verworfenen Pakete schon aus. Ansonsten eben alles loggen. Würde mal damit beginnen.

Einschalten: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:disable /failure:enable

 

Tipp: Schreibe dir immer auf was du mit Auditpol aktivierst/deaktivierst. Damit Du nachher wieder weisst wie Du es abschalten kannst. Sonst wird Dein Log unter Umständen ohne Ende geflutet. ;)

Security Journaling? Bahnhof... :confused:

auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:disable /failure:enable?

Das ist der Befehl, um das logging zu aktivieren? Die Daten stehen dann im Ereignisprotokoll?

Und wie wird das wieder ausgeschaltet? Mit dem gleichen Befehl, nur disable statt enable?

 

 

Wenn es von extern kommt bzw. nahc extern geht via UDP 123 kannst vor Auditpol auch mit dem normalen Firewall-Journaling prüfen ob da Pakete im Success oder Failure raus oder reingehen.

Ähhh... - wie?

 

André

bearbeitet 3. Juli 2016 von doc_jochim

[blub 115]

 

151743 07:46:09.2465914s - Response received from domain controller XP1.Praxis.local authenticated successfully (using digest format)

auf welchem Betriebssystem laufen deine DCs?

Gibt es noch Windows2000/ 2003er als DCs?

Welches OS hat XP1.Praxis.local ?

 

wdigest ist alt, unsicher und sollte schon längst disabled sein. (Außer man hat noch 2003/ XP etc.).

https://blogs.technet.microsoft.com/kfalde/2014/11/01/kb2871997-and-wdigest-part-1/

Würde mich jetzt nicht wundern, wenn Windows10 default das "digest format" ablehnt

[doc_jochim 0]

auf welchem Betriebssystem laufen deine DCs?

Gibt es noch Windows2000/ 2003er als DCs?

Welches OS hat XP1.Praxis.local ?

 

wdigest ist alt, unsicher und sollte schon längst disabled sein. (Außer man hat noch 2003/ XP etc.).

https://blogs.technet.microsoft.com/kfalde/2014/11/01/kb2871997-and-wdigest-part-1/

Würde mich jetzt nicht wundern, wenn Windows10 default das "digest format" ablehnt

 

Also:

Es gibt nur einen Server2003Standard-DC, der alle Rollen innehat und PDC, DHCP-Server, DNS-Server, WINS-Server usw. ist, sonst keine weiteren Server / DCs

Der Rechner xp1 ist der o.g. DC

Die Clients sind alle Win7pro64bit und sind so nach und nach jetzt auf Win10pro64bit umgestellt worden. Einer ist noch auf Win7. Und einen weitereren Client hatte ich wegen 'antiker' Hardware immer noch auf XP laufen. Aber der wird jetzt auch auf Win7 und dann mit Upgrade auf Win10 umgestellt werden können.

 

wdigest ist alt, unsicher und sollte schon längst disabled sein. (Außer man hat noch 2003/ XP etc.).

 

Was macht eigentlich dieses wdigest?

 

Oh je - immer mehr Löcher in meinem Wissen tun sich auf... :shock:

 

André