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

Question

Hi

We have 4 Domain controllers upgraded to server 2025 and about 30+ still on 2022. The newly upgraded servers appear to have a bug where by any workstations going through them are unable to update their "pwdLastSet" value and so after the 30 day limit on that field is hit they then fall into a trust relationship issue with the domain. Is this a known bug of server 2025? Are there any known fixes for this issue?

Answer 1

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!

Answer 2

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.

Answer 3

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.

Answer 4

Hi,

Just to add my experience. This is something broken in Windows Server 2025.

Since upgrading my DCs to 2025 my ESXi servers which are domain members also complain they can’t update their computer account passwords (it’s a pretty constant error).

Those errors on ESXi are:

<27>2025-01-17T12:01:39.026Z <ESXI SERVER> lwsmd[265009]: [lsass] Error: Failed to change machine password for <AD DOMAIN NAME> (error = 5)

Also, if I try and join a RedHat instance to the domain using the SSSD method it fails saying it can’t set the machine password in AD. If I join them using the old winbind method they work.

Server 2025 has broken something for most computers trying to change their AD machine password.

Answer 5

Hi, we have the same problem like everyone is talking about.

As a workaround we created a gpo to put it on 60 days. Also we are fast deploying 24H2 to all of our pc's. As we can't see any bugs anymore.

When will there be a fix? This is a major bug i presume? Does Microsoft acknowledge the problem and are writing on a fix?

Thx for the update!