![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
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.