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

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.

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.

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

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.

That RPC methods setting is missing from my group policy console even though my entire domain is at the 2025 level. Not sure why I didn't get it. I will try and re-apply the Server 2025 ADMX files. (Edit: reapplying the 2025 Group Policy pack to my DC fixed this missing RPC Methods policy)

I did want to add this update I saw on the Server 2025 release notes:

• Legacy Security Account Manager (SAM) remote procedure call (RPC) password change behavior: Secure protocols such as Kerberos are the preferred way to change domain user passwords. On DCs, the latest SAM RPC password change method SamrUnicodeChangePasswordUser4 by using Advanced Encryption Standard (AES) is accepted by default when it's called remotely. The following legacy SAM RPC methods are blocked by default when they're called remotely:
  • SamrChangePasswordUser
  • SamrOemChangePasswordUser2
  • SamrUnicodeChangePasswordUser2
  For domain users that are members of the Protected Users group and for local accounts on domain member computers, all remote password changes through the legacy SAM RPC interface are blocked by default, including SamrUnicodeChangePasswordUser4. To control this behavior, use the following GPO setting: Computer Configuration > Administrative Templates > System > Security Account Manager > Configure SAM change password RPC methods policy