Secure Time Seeding - STS - in Windows Server: Was ist das und warum sollte man es deaktivieren?

Moin,

Microsoft hat vor kurzem einen neuen Artikel mit Empfehlungen für STS herausgebracht.

Was ist STS?

Quelle: KI

Secure Time Seeding (kurz: STS) ist eine Funktion, die Microsoft ab Windows 10 Version 1511 und Windows Server 2016 eingeführt hat. Sie dient dazu, die Systemzeit auf einem Computer automatisch zu korrigieren, wenn große Zeitabweichungen auftreten, zum Beispiel nach Hardwarefehlern oder bei Geräten ohne Batterie (z. B. VMs oder IoT-Geräte).

STS nutzt dafür Zeitinformationen aus SSL/TLS-Verbindungen zu externen Servern. Die Idee: Wenn dein Server mit einem TLS-fähigen Server kommuniziert, kann STS aus den Zertifikatsdaten grob ableiten, welches Datum aktuell sein sollte – und damit große Zeitabweichungen erkennen und gegebenenfalls korrigieren.

Jeder der sich mit TLS auskennt, erkennt direkt, warum der Mechanismus nicht funktionieren kann. OpenSSL verschickt beispielsweise keine akkuraten Zeitstempel, sondern zufällige:

Do not include a timestamp in the Client/ServerHello Random field.
Instead, send random bytes, unless SSL_SEND_{CLIENT,SERVER}RANDOM_MODE is set.

(aus einer alten commit message)

Zusammenfassung des Artikels

STS sollte auf allen Windows-Servern, die zeitkritische Funktionen bereitstellen, deaktiviert werden. Es funktioniert nicht immer richtig und kann für riesige Probleme sorgen, in dem die Zeit des Servers auf einen Zufallswert, der Jahre von der Realität weg sein kann, gestellt wird.
Wir haben es mittlerweile auf allen Servern deaktiviert, da wir eine zuverlässige NTP-Infrastruktur haben, und keinen Mehrwert in STS sehen.

Genannt wurden u.A. Domänencontroller und VM-Hosts.

Wie kann ich prüfen, ob STS aktiviert ist?

Ab Server 2016 bis inkl. Server 2022 war STS standartmäßig aktiviert. Prüfen kann man es mit diesen Methoden:

Registry:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config" -Name "UtilizeSslTimeData"  

Eventlog, prüft ob UtilizeSslTimeData in den Events nicht 0 (deaktiviert) ist

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-Time-Service/Operational'  
    ID        = 257,260,263
    StartTime = (Get-Date).AddDays(-7)
} | Where-Object {
    if ($_.Message -match 'UtilizeSslTimeData:\s*(\d+)') {  
        [int]$Matches[1] -ne 0
    }
}

w32tm debug log:

w32tm.exe /debug /enable /file:c:\w32time.log /size:100000000 /entries:0-300
net stop w32time
net start w32time

nun in c:\w32time.log prüfen ob UtilizeSslTimeData nicht auf 0 steht

danach das debug log wieder deaktivieren nicht vergessen:

w32tm.exe /debug /disable
net stop w32time
net start w32time

Wie deaktiviere ich es?

Entweder lokal per Registry

reg.exe add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config" /v "UtilizeSslTimeData" /t REG_DWORD /d 0 /f  

oder zentral per GPO

Computerkonfiguration → Administrative Vorlagen → System → Windows-Zeitdienst → Globale Konfigurationseinstellungen aktivieren, UtilizeSslTimeData auf 0 setzen. Die restlichen Einstellungen in der Vorlage entsprechen dem Standard.

Danach gpupdate + w32time oder den Server neu starten.

Wir hatten bei der Dekativierung von ~20 Servern keine Probleme. Natürlich vorher in Testumgebung oder vereinzelt ausführen.

Lesenswert:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-dir ...
https://www.reddit.com/r/sysadmin/comments/sedth9/issues_with_windows_ti ...
https://ryanries.github.io/?title=beware_of_secure_time_seeding.html
https://www.reddit.com/r/sysadmin/comments/61o8p0/system_time_jumping_ba ...

Gruß und schönen Feiertag
CamelCase

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 672690

Url: https://administrator.de/tutorial/secure-time-seeding-sts-in-windows-server-was-ist-das-und-warum-sollte-man-es-deaktivieren-672690.html

Ausgedruckt am: 01.05.2025 um 13:05 Uhr

3 Kommentare

Neuester Kommentar

Und warum soll man es nun deaktivieren? Du sagst ihr habt ne funktionierende NTP-Struktur, damit würde ja "bei zu grosser Abweichung" eh nie zum Tragen kommen - fertig...

Gleichzeitig kann ich natürlich aus SSL problemlos einige Dinge ableiten sofern ich weiss das der Server korrekt ist. Denn was passiert wenn zB. die Batterie alle ist? Dann sagt dir dein Windows das es 1970 ist (oder ggf. mittlerweile auch 2000, 2020,... spielt keine wirkliche Rolle). Lese ich jetzt also ein Zertifikat aus (und WEISS der Server ist gültig, was MS ja zB. bei eigenen Servern durchaus weiss) und es ist "valid from" 01.01.2025, meine Systemuhr sagt aber "is aber Jahr 2020" dann wird vermutlich meine Uhr falsch sein, es ist nicht zu erwarten das du heute ein Zert hast was erst in x Jahren gültig wird. Ist das "valid until" dann 01.06.2025", meine Systemuhr sagt aber "is heute 01.01.2030" dann wird auch wohl was nicht stimmen da ich ja auch weiss das der Server ein gültiges Zertifikat hat...

Wenn du also eine funktionierende Infra hast die dir nen gültiges NTP gibt - dann kommt das eh nicht zum tragen. Hast du dagegen einen Ausfall würde sich die Uhr schonmal angeleichen während normales NTP zum einen gerne mal bei zu grosser Abweichung sagt "lass ma lieber, ich warte mal auf den Admin" und selbst sonst die Anpassung nur langsam macht. Nehmen wir also an dein NTP is ausgefallen und du hast 2 Server die ne Abweichung haben (einer in der Zukunft, einer in der Vergangenheit). Deine Systemuhr im "Auto-Modus" gleicht sich bei kleinen Abweichungen ja problemlos selbst an - indem eine Systemuhr im Takt beschleunigt und die andere abgebremst wird... BIS also beide wieder gleich laufen hast du ggf. Probleme. Ist die Abweichung zu gross hast du ggf. sogar richtig grosse Probleme...

Welchen Vorteil bringt also das Abschalten? Oder warum rätst du pauschal diese Funktion abzuschalten?

Moin @maretz,

Und warum soll man es nun deaktivieren? Du sagst ihr habt ne funktionierende NTP-Struktur, damit würde ja "bei zu grosser Abweichung" eh nie zum Tragen kommen - fertig...

weil es z.B. nur unnötiger Ressourcen frisst und auch zusätzliche Probleme bereiten kann.

https://www.kaspersky.de/blog/windows-system-time-sudden-changes/30440/
https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-dir ...

https://techcommunity.microsoft.com/blog/askds/secure-time-seeding-on-dc ...

"To compound the issue even further, there is no logging that will point to STS as having set the time. The only way to know that it made the change is to already have w32tm debug logging enabled before it happens"

🙊🙈

Gruss Alex

Welchen Vorteil bringt also das Abschalten? Oder warum rätst du pauschal diese Funktion abzuschalten?

Verlinkten Artikel nicht gelesen?

Nicht nur ich, sondern vor Allem Microsoft (und viele weitere Experten, google mal danach) rät dazu, weil es durch STS zu Problemen kam. Uhren haben sich ohne Zutun um Monate oder gar Jahre verstellt, weil w32time die Zeit aus SSL/TLS-Anforderungen als richtiger ansah als die lokale Zeit.
TLS war nie dazu gedacht, autoritativ Uhrzeiten anzugeben.

Nicht zum Spaß ist es ab Server 2025 standardmäßig deaktiviert.

Du kannst es ja gerne anlassen, ist ja nur ein Hinweis. Wenn du Glück hast, wird nie etwas passieren. Wenn du Pech hast und deine DC haben plötzlich 23.05.2002, 14:00, viel Spaß

Based on customer reports and the associated feedback, we recommend disabling the STS feature in Windows Server 2016 and later Windows Server machines hosting time-sensitive workloads. This includes any Active Directory Domain Services (ADDS) domain controllers, virtual machine (VM) hosts, and servers that use time for critical functionality, providing connectivity, or data processing in your deployments.

We recommend that you consider disabling the STS feature in all Windows Server 2016 and later Windows Server machines hosting generic/non-time-sensitive workloads to avoid unforeseen timekeeping-related incompatibility issues arising from STS.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-dir ...

Auch lesenswert:
https://www.reddit.com/r/sysadmin/comments/sedth9/issues_with_windows_ti ...
https://ryanries.github.io/?title=beware_of_secure_time_seeding.html
https://www.reddit.com/r/sysadmin/comments/61o8p0/system_time_jumping_ba ...

Tweet von Joseph Ryan Ries, Senior Escalation Engineer im Windows Debug-Team