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

Our affected systems so far are:

• Member Server: Windows Server 2022 LTSC (Version 21H2)
• Client Systems: Windows 10 LTSC (Version 21H2)
• Member Server: Ubuntu Server 22.04

Our domain level is 2016.

We are having the problem as well.

DC at 2025.

Win11 at 23H2 (due to really buggy 24H2 and hybrid domain trust problems).

Using the Reset-ComputerMachinePassword does fix the problem for the domain members temporarily but I've noticed not always. I wrote a script to do a domain trust audit on everything (using Test-ComputerSecureChannel that returns false) and noticed that there are a couple machines already with domain trust problems with pwdLastSet being just a few days old. So I had fixed a machine and it's now broken even before the 30 day mark.

I have the password change issue on AD member servers based on Windows Server 2025.

AD is on Server 2019 or 2022. Domain and forest level is on 2016.

Doesn't matter if upgraded or fresh installed. All my Windows Server 2025 cannot automatically update their password.

They keep the initial password and do still work after the 30 days expiry date.

Windows 11 23H2 or 24H2 have no issue.

Password can be updated with the PowerShell command but not automatically.

January 2025 patches did not help.

Waiting for MS to solve this issue!

I can also confirm that the only machines affected are Win11 22H2 or Win11 23H2. Win10 anything seems to be fine. So far, I haven't had any problems with Server 2019 or server 2022.

I've created an OU in our domain that uses GP to set the machine password reset to 1 day and moved a couple test machines into there. On the Win11 22H2 and 23H2 machines break each day. The ones that were 22H2 and 23H2 and were upgraded to 24H2 are fine.

So it's some kind of bug that the Win11 22H2/23H2 machines, but only wit DCs that are running 2025. And I might know what that is. I used GP to turn on NETLOGON debug logging. In the clients I am seeing it attempt to update the machine password in AD, but the update is getting denied with a 0xC0000022 code, which is "access denied". The NETLOGON debugs on the DCs show the same thing, but preceding that error is an additional error of "decrypted password is too long".

Putting that together, I'm guessing that 22H2/23H2 is somehow making a password that's longer than allowed and server 2025 is rejecting it. Whereas previous Servers took the password. Sounds like the kind of thing that happens as they update the code and notice it wasn't checking lengths. Buffer overruns or something like that. This is a guess as to what was changed based entirely on the NETLOGON debug logs.

But upgrading to 24H2 definitely fixes the Win11 machines. And all variations of Win10 seem unaffected.

More confirmation that this is an issue with 23H2

Anything with version 26100 (24H2) is updating.

Anything with version 22631 (23H2) is not updating and generating bad password attempts.

I also am seeing kerberos preauth failures in wireshark captures from both the client and domain controller.

As a test I also added a computer to the domain administrators group in case there may be some strange permissions issue, forced a computer password change, then waited a day (per the test GPO requirements) and the password did not change.