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.

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.

I can only confirm this behavior. Windows 10 machines are fine, Windows 11 24H2 is also fine. Only Windows 11 23H2 is affected by this. Forest and Domain level are not affecting this. One Domain is upgraded to 2025 level, the other one is still on 2016 level and both have the Problem, so its purely Server 2025 and Windows 11 23H2 in conjuction.

Hi

My colleague has tested further and now done a second stand alone domain setup as per the below.

1. Setup fresh server 2025 Domain controller (forest/domain functional level at 2025)
2. Install 2 workstations on windows 11 23h2
3. Set machine account password max age to 1 day
4. no GPO's added other than to set max machine account password age to 1 day.

Both workstations have now trust relationshiped themselves into oblivion, so upgrade or fresh the issue is still there on 2025.

I have also separately on my 2 test machines within our production environment (where the issue was first found) done the below.

Both machines have machine account password max age set to 1 day.

Test Machine 1

• Upgrade from 23H2 to 24H2 - This was done on the 09/01/2025
• Rebooted daily to ensure the machine account password change process runs (believe it should anyways but just in case).
• Local Machine account password on the workstation has stayed on 09/01/2025 on the workstation and stayed 09/01/2025 in AD
• Trust relationship has yet to break 4 days on from this change but the local and AD passwords are not updating.

Test Machine 2

• Kept device on 23H2
• Rebooted daily to ensure the machine account password change process runs (believe it should anyways but just in case).
• Local machine account password on workstation updated yesterday to be 12/01/2025 on the workstations but stayed at 09/01/2025 in AD
• Trust relationship broke as we are seeing within our environment more generally.

Code used to find local machine account password date on device to compare to AD is below (may need to be run as system).

Get-date –date ([DateTime]::FromFileTime([System.BitConverter]::ToInt64((Get-ItemProperty -path "HKLM:\SECURITY\Policy\Secrets`$MACHINE.ACC\CupdTime").'(default)',0))) -Format 'dd-MM-yyyy'

My best guess at the moment is 23H2/Server 2025 is broken and so makes a change to the local machine account password when its not being done in AD where 24H2 is aware that the machine account password hasn't updated in AD and so keeps the local password.

What's more concerning is that on 24H2 while the machine isn't trust relationshipping itself into oblivion (yet) it also isn't correctly updating the passwords, they are just sitting at the old values. But i need a few more days to ensure the above continues to behave as described.

I have also asked my colleague to move a machine in each of his test instances up to 24H2 and leave one at 23H2 to further test the above from a totally empty environment.

Hopefully this is helpful for the other people with the same issue i can see are starting to show interest in this thread.

I am also noticing the last logon date is not updating either. This is very specifically on newer OS build versions

#Single machine
get-adcomputer -identity $computername -properties lastbadpasswordattempt, PasswordLastSet, whenchanged,LastLogonDate | select Name,LastBadPasswordAttempt,PasswordLastSet, LastLogonDate, whenChanged

#All machines
get-adcomputer -filter * -properties lastbadpasswordattempt, PasswordLastSet, whenchanged,LastLogonDate,OperatingSystemVersion | select Name,OperatingSystemVersion, LastBadPasswordAttempt,PasswordLastSet, LastLogonDate, whenChanged | Format-Table

This is a test network
26100 represents my DCs and some HyperV hosts (Server 2025 24H2)

The rest are workstations representing a variety of build versions in both physical and virtual, wired and wireless
22621 (Windows 10 23H2) and 22631 (Windows 10 24H2)