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

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.

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.

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.

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)

This is very much the same as we have in our environment, doing all sorts of testing with kerberos etc at the moment but nothing sticks as a fix as of yet. A colleague has built up a domain with a couple of computer and upgraded the DC's from 2019 to 2022 and then 2025 and will see if there is any similar behaviour.

I was going to look at getting my test machine up to 24H2 from 23H2 but from what you have said im not holding my breath that thats the issue. Its odd though as it appears some devices like some windows 10 devices and iMac's embedded into AD have been able to do the process fine as we have a few of each in the location I'm testing.

Logs im keeping an eye on are

Schannel - 36871

Kerberos – 4768/4769/4770/4771/   

If you run the command i mentioned earlier in the post logs for 4742 are output as per below screenshot and it will change the password last set field for the account as you would expect.

I'm wondering if the password reset actually isn't syncing the passwords on the machine and whilst it does update the password last set field in AD to give another 30 days leeway, that the password the machine holds and the password in AD is actually different from the point of running the command, but im not sure how to check that yet and its probably not the case, as seems more likely to me they are in sync but that the update process is broken.

I set the maximum machine age policy to 3 days on a test domain with Windows 11 24H2 clients and they all lost their trust relationship and would not authenticate. They also did not update their pwdlastset values in AD.

Immediately after unlinking the GPO, they were able to authenticate again. Setting to a higher value of 365 days and linking the GPO also allowed them to authenticate.

Using the reset-computermachinepassword command does change the pwdlastset date.

I've enabled several logs on the domain controllers and am attempting to decipher which may be of value. The biggest standout is a large number of event 4771 pre-kerberos authentication events from the workstations

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 1/9/2025 8:04:41 AM

Event ID: 4771

Task Category: Kerberos Authentication Service

Level: Information

Keywords: Audit Failure

User: N/A

Computer: DC.domain.com

Description:

Kerberos pre-authentication failed.

Account Information:

Security ID: domain\workstation$

Account Name: workstation$

Service Information:

Service Name: krbtgt/domain.com

Network Information:

Client Address: ::ffff:10.0.44.102

Client Port: 65463

Additional Information:

Ticket Options: 0x40810010

Failure Code: 0x18

Pre-Authentication Type: 2

Certificate Information:

Certificate Issuer Name:

Certificate Serial Number:

Certificate Thumbprint:

Certificate information is only provided if a certificate was used for pre-authentication.

Pre-authentication types, ticket options and failure codes are defined in RFC 4120.

If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.