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

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)

Was reading last night and think possibly the Kerberos aspect is an effect of the issue rather than the route cause, as it appears the machine password change process is totally controlled by the local machine and uses Netlogon (RPC) to do it, so am wondering if theres something broken in that, possibly related to the below hardening on server 2025. Just another possibility as I'm going in a bunch of different directions with possible fixes at the moment but as yet nothing appears to rectify it.

So my colleague setup a clean infrastructure, process was as below and shows this is a legitimate issue with something on one of the operating systems.

1. Install Server 2019, upgrade to server 2022, upgrade to server 2025 (this follows the setup for most of our DC's though we have seen same behaviour at 1 of our sites that was freshly built to 2025 due to a hardware failure)
2. Install 2 workstations with windows 11 23H2
3. Set machine account password max age for the machines to 1 day.
4. NO GPO's added or amended, only the default domain controller and domain policy are in place + the 1 setting to amend machine password max age.

First workstation has just trust relationshipped itself into oblivion. We expect the second one to do so shortly as it passes the 1 day mark.

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.

Then i will Post my experience here also.

I can say that the Version of Windows 11 is not interesting. Im also in a school and we have win11 22h2,23h2,24h2 clients. Everybody has the Mistake. I think it is not possibile to fix at the moment. Only with gpo for machinepassword.

Im really sure that it has something to do with Kerberos Error ID 7. Everytime when someone is logging in with trust Problems it will show up in event log of the dc.Maybe server patch from tomorrow will fix it?
We will see