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

Hello

Good day!

My test workstation is one member server 2025.

I can try to find one windows 11 23H2 machine if you need? Please tell me.

Do you mean "Trust relationship issue" that you can not sign in the windows 11 23H2 machine using any domain accounts (sign in previous and new account that never sign in)?

Best Regards,
Daisy Zhou

Hi Daisy

Yes that's the issue, the Domain Controllers are fine, the workstations using them are not after 30 days as they fall into a trust relationship issue because they cannot reset their pwdlastset field, or more likely they are resetting the value but only on the workstation while the DC is not updating AD and so they are out of sync.

Hello

Good day!

My test workstation is one member server 2025.

I can try to find one windows 11 23H2 machine if you need? Please tell me.

Do you mean "Trust relationship issue" that you can not sign in the windows 11 23H2 machine using any domain accounts (sign in previous and new account that never sign in)?

Best Regards,
Daisy Zhou

Hello

I can sign in using domain Admin on this member server.

And I check the pwdlastset on this member server, it changed as below.

Yesterday and today.

I will check win 11 23h2 tomorrow, and if there is any update, I will update here.

Best Regards,
Daisy Zhou

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.

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.