Server 2025 Domain Controllers - Trust relationship issues on workstations after 30 days as "pwdLastSet" value unable to be updated

I have been continuing to test and in my main test environment where i have a 23H2 device and 24H2 device to test against, i applied the below setting (which i mentioned earlier in the post but never actually tested initially) onto the DC's at that site. This seems to have allowed 23H2 to update password correctly for the last 2 days.

The 24H2 device at my main test location continues to not update password but also not to lose trust relationship with the domain. However a fresh 24H2 device at a second location (Second location's DC does not have the below setting applied to it) is updating its password daily so i suspect the one not updating has a separate issue.

Hey Gabriel,

your Point: - User passwords change via Ctrl+Alt+Supr options is also affected.

shouldnt be a Problem actually but i can say i also had it after installing my 2025 DCs.

For me it was a Different Time between my two DCs. 2025 has a Time Issue.

Maybe it can help you

Just wanted to report that my business is also suffering from this bug. We are working as fast as we can to roll out 24H2 but it crippled my IT department for a day trying to deal with trust issues on thousands of devices.

This is indeed a legitimate issue. We had the same issue, still with varying drops among members (no servers dropped). It seems that older machines are not affected, they may have a RC4+AES128/256 SHA1 encryption type only (with no futures), just guessing, no tests have been done.
Still i tested Linux Kerberos clients extensively, they are affected too:

https://gitlab.freedesktop.org/realmd/adcli/-/issues/40

We had to change password computer account via ldap password reset (it directly writing ldap object properties).

What happens:

• Trust-dropping machines: Password is actually changed via Kerberos flow (DC writes the new value in AD DS), but it reports an error message. Machine receives the error, so it discards the new krb5.keytab and maintains the older one. This results in a mismatch between lcoal machine password, and AD DS hashes. Machine passwords do not expire, so it is the password resets that breaks trust between machine and ADDS, we put a password reset cycle of 120d so we can wait a CU.
• Non trust dropping machines, but they have not updated password in a while. Same as before, but they fail before, and password is not actually changed in DS.
• User passwords change via Ctrl+Alt+Supr options is also affected.

Hello Erin Teu,

Greetings！

If Microsoft sees the feedback, they will definitely be active in fixing or fixing the problem. I've seen other people on the forum have the same issue as you, and I think they're going to give feedback, too, and I'm sure Microsoft will take this issue very seriously.

As a temporary solution, it is recommended that you update your computer's password for a longer period of time. Please be patient and wait for Microsoft's update.

Thank you for your efforts, understanding and support.

Best Regards,
Daisy Zhou