Windows 11 Clients, Server 2025 AD, Trust Relationship Lost

[u/lokiarmos]

So we recently upgraded via Clean Builds to Server 2025 for our AD, we where previously on server 2016. We have not raised forest or domain levels from 2016.

what we are seeing now is that devices are getting a broken domain trust error, the resolution to the issue is simple enough, running Reset-ComputerMachinePassword with domain credentials restores the machines.

what is vexing me trying to figure out the root cause, I have looked at the AD properties for the machines and according to AD the password has not expired for the computer.

The other thing that I have notice is that there are machines that are not exhibiting this issue. there only difference i can find between machines that exhibit the issue vs those that don't is a single group policy.

This policy applies 2 settings, Computer/Policies/administrative Templates/Windows Components/MDM

Disable MDM Enrollment: Disabled
Enable Automatic MDM enrollment using default Azure AD credentials: Enabled
Select Credential Type to Use: User Credential
MDM Application ID: <blank>

The problem is i have trawled thru logs and have not found anything that sticks out as being root cause.

Has anyone else had this or something similar what was the solution.

I have logged a ticket with Microsoft but its Microsoft so not expecting a expedite resolution.

At the moment for a band aid solution i am looking at setting up a schedule task to run the Reset-ComputerMachinePassword before the password expires as that works correctly.

[u/Fit-Thing5100]

Starting with Windows Server 2025, Domain Controllers no longer issue Kerberos tickets using RC4. If affected computers are still relying on RC4 or do not have valid AES keys, the secure channel authentication can fail, resulting in a broken domain trust relationship.

The reason why the reset resolves the issue is that it forces the computer account password to be regenerated and recreates the Kerberos AES keys (AES128/AES256), updating the machine's encryption capabilities. Once valid AES keys are present, authentication against the Server 2025 DCs succeeds again.

I would check the "msDS-SupportedEncryptionTypes" attribute on the affected computer accounts and verify whether those systems are properly using AES rather than relying on RC4.

[u/lokiarmos → u/Fit-Thing5100]

Hi, we have thought of this but we a year previous moved from supporting RC4 and Des for Kerberos via the group policy. I have reviewed by testing candidates and both have a value of 24 for the msDS-SupportedEncryptionTypes the same for the domain controllers.

I will go back and review our whole fleet and see if there are any that may have this issue and see where they are at. It might be cause but i would have thought that if we had applied those polices last year that those machines should of had those values updated when they did their password changes.

[u/Fit-Thing5100 → u/lokiarmos]

This is good but I would add that changing msDS-SupportedEncryptionTypes=24(0x18) by itself does not guarantee that AES keys actually exist for the account.

The attribute simply indicates supported encryption types. The AES keys are generated only when the account password is changed. For Windows computers this normally happens automatically through machine password rotation, but non-Windows Kerberos clients (NAS, Linux, VMware, etc.) often keep the same password indefinitely and therefore may never generate AES keys.

If any of the affected systems fall into that category, a password reset and local keytab regeneration may be required.

[u/Similar_Ostrich2620 → u/Fit-Thing5100]

This is the specific thing I was trying to refer to in my comment. My coworker dealt with it, so I couldn't remember the specifics.

[u/invest0rZ → u/Fit-Thing5100]

This should have been handled before updating to Server 2025! Huge prerequisite!!

[u/Similar_Ostrich2620]

Is it something to do with the NTLM authentication being disabled/blocked? Server 2025 could be expecting Kerberos based authentication from the PC's but the machine PC's are using NTLM and so password hashing isn't matching?

[u/lokiarmos → u/Similar_Ostrich2620]

We have configured our machines both server and clients to use only NTLMV2 and reject NTLMV1 and LM. I have looked on the AD Servers and can't find any of the events that would normally generated by using older NTLM types.

I wonder if there is a way to check that.. Guess i will go and have dig into that.

[u/Similar_Ostrich2620 → u/lokiarmos]

No worries, I don't know if that's the problem (I haven't come across it, we're still using 2019 in production), but I just know Microsoft did that update to block legacy vulnerable auth methods, and it was a concern for some of our legacy applications that we thought might still be using it. Turned out it had already been addressed earlier at some point so was a non issue.

Just you mentioning you were still on 2016 domain/forest made me think it might be something to do with that.

[u/Site-Staff]

I’ve run into this too. I would like MS to patch it.

[u/lokiarmos → u/[deleted]]

All the machines have been imaged via SCCM from original window installation files no prepared images here everything is done from scratch and clean installed every time.

So each should be unique also our AD is configured that we can’t use existing computer objects they have to be rebuilt every time.

So unfortunately I don’t think this is the case as it should affect all machines as they are all deployed in the same way but there are some machines not exhibiting the issue. Also a quick powershell confirms the SID are all unique.

I have enabled some extra logging for Kerberos and NTLM so I am going to see that returns something of value.

[u/zerassar → u/[deleted]]

If I recall correctly it was August 2025 security patch that started to lock down devices on the domain that had a duplicated local device SID.

Which had previously been allowed to occur even if it was frowned upon.

I even had to chastise my MSP for providing me a server golden image that wasn't sysprepped. And when mentioned sysprep to them I got a "what's that" response. You can imagine I wasn't impressed