Forum Discussion
ATP sensor fails to start since yesterday
Similar scenario to the OP, where one DC out of 20+ is fine, but the others are busted. Strangely, the GSMA is being used across a forest trust and those DCs are all fine.
So in the end, our issue turned out to be in relation to the awful Secure Time Seeding service, which caused a domain controller to jump into the future by two months and back again. During that interval, it seems that our GMSA did a password reset, and now the "lastlogondate" and "passwordlastset" dates are still in the future, so now none of the DCs (other than the one where the time jump occurred) can retrieve the password.
These are the selected date properties for the account - note the password/lastlogon dates are still a month from now.
Get-ADServiceAccount -Identity [SVC_ACCOUNT] -Properties *
... badPasswordTime : 133693679012898018 badPwdCount : 28 LastBadPasswordAttempt : 29/08/2024 11:18:21 AM lastLogon : 133690172347063244 LastLogonDate : 17/09/2024 1:27:15 PM lastLogonTimestamp : 133710172352439465 PasswordLastSet : 17/09/2024 1:27:15 PM pwdLastSet : 133710172352439465
In a domain environment, where your DCs are syncing with a good NTP source, you MUST disable this STS garbage, which is enabled by default. https://arstechnica.com/security/2023/08/windows-feature-that-resets-system-clocks-based-on-random-data-is-wreaking-havoc/
The only fix for us now, according to Microsoft Support, is to create a new GMSA ...or wait another month until it starts working.
Sorry not to reply earlier, but I hope you saw the previous comment about disabling STS using the UtilizeSslTimeData registry key. I just added another comment about using a Group Policy setting to configure all DCs (and I recommend all servers too).
Definitely recommend setting the group policy in a domain environment - unsure why this is barely ever mentioned. In GPMC or GPEdit, browse to:
Computer / Administrative Templates / System / Windows Time Service
- Global Configuration Settings: set to Enabled
- UtilizeSslTimeData: set to 0The other settings under Global Configuration can be left as default (or customised per your environment)
I strongly recommend adding this to the Default Domain Controllers policy (or whatever policy is applied to all DCs) and to your entire server fleet, assuming it's on wired networks (and even if not).
I also strongly believe MSFT should have ensured Windows defaulted to the UtilizeSslTimeData setting not being enabled unless there was no configured NTP or domain timesource. It's a terrible idea to use network packet data that was never designed to be highjacked for this purpose, full stop.
It's even worse that STS supersedes time settings that ARE configured with an NTP or domain time source and can cause the system to jump time way in excess of the configured W32time service limits.
- To disable the secure time seeding feature, go to the below mentions registry key and set the registry value to ‘0’ for the following Registry Key (or GPO of course 😉 😞
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
Value Name: UtilizeSslTimeData
Value Type: REG_DWORD - Thanks for this info! Troubleshooting the same thing and with your help discovered 2 out of 5 gmsa accounts have the same issue. If we recreate the accounts what is to stop it from happening again? Any info or articles is greatly appreciated!
