Windows Server 2025 DCs causing trust relationship problems on client devices

PotNoodleTech · April 9, 2025

40 minutes ago, psydii said:

14 years after I first noticed it, and exacerbated by the demise of the technet blogs and RSS feeds, I am still puzzled how Arthur manages to remain so on the bleeding edge of update news.

To quote my good friend Spock:

"If you eliminate the impossible; whatever remains, however improbable, must be the truth."

Therefore, Arthur must work for Microsoft

Edited April 9, 2025 by PotNoodleTech

psydii · April 9, 2025

5 hours ago, PotNoodleTech said:

Therefore, Arthur must work for Microsoft

That thought had occurred to me.

5nowman · April 17, 2025

On 09/04/2025 at 09:34, psydii said:

14 years after I first noticed it, and exacerbated by the demise of the technet blogs and RSS feeds, I am still puzzled how Arthur manages to remain so on the bleeding edge of update news.

To comment on this particular update though, Microsoft seem to have "fixed it" with a work-around, excluding certain things from protection by 'Credential Gurad.'

The patch notes I think being the first place Microsoft announced the disablement of this feature, and its new, quirky spelling:

April 8, 2025—KB5055523 (OS Build 26100.3775) - Microsoft Support

[Authentication] This update addresses an issue affecting machine password rotation in the Identity Update Manager certificate/Public Key Cryptography for Initial Authentication (PKNIT) path. This issue occurred particularly when Kerberos was used and Credential Guard was enabled, potentially causing user authentication problems. The feature Machine Accounts in Credential Gurad, which is dependent on password rotation via Kerberos, has also been disabled, until a permanent fix is made available.

Is this the fix for the problem this thread was created for?

psydii · April 18, 2025

Yes, this is supposed to eliminate the 2025/win11 machine account password problem.

However the information released suggest this is update contains a hard-coded work-around for some the modern behaviours and capabilities that caused the problem, and further work to get these underlying codependencies properly interacting is expected to be undertaken.

For most Domain Admins, all we need to know is “computer account password problem” is now fixed. Those who genuinely need to know more (because they needed the new behaviours) likely have tickets open and their own account managers at Microsoft to liaise with.

Of course since the problem can take 30 days to manifest, it will be a while yet before we can be sure that this does actually fix the problem.

5nowman · April 19, 2025

17 hours ago, psydii said:

Yes, this is supposed to eliminate the 2025/win11 machine account password problem.

However the information released suggest this is update contains a hard-coded work-around for some the modern behaviours and capabilities that caused the problem, and further work to get these underlying codependencies properly interacting is expected to be undertaken.

For most Domain Admins, all we need to know is “computer account password problem” is now fixed. Those who genuinely need to know more (because they needed the new behaviours) likely have tickets open and their own account managers at Microsoft to liaise with.

Of course since the problem can take 30 days to manifest, it will be a while yet before we can be sure that this does actually fix the problem.

Also.. Why do people say Windows Server 2025 is beta? IS that not wrong?

DrCheese · April 19, 2025

3 hours ago, 5nowman said:

Also.. Why do people say Windows Server 2025 is beta? IS that not wrong?

The theory is, no Windows release survives contact with the real world. No amount of actual beta testing can account for every set of settings or every environment.

You generally don't deploy a release within X months of release. What that X is, is entirely down to your appetite for any issues that occur.

Those who wait a year to deploy 2025 will get to skip all these bugs that have been discovered.

5nowman · April 19, 2025

1 hour ago, DrCheese said:

The theory is, no Windows release survives contact with the real world. No amount of actual beta testing can account for every set of settings or every environment.

You generally don't deploy a release within X months of release. What that X is, is entirely down to your appetite for any issues that occur.

Those who wait a year to deploy 2025 will get to skip all these bugs that have been discovered.

I love this reply! It is totally true..

By the book, Microsoft have officially released Windows Server 2025 Retail. I didn't check as I went by replies in this forum, but the final released October 2024.

Good practice as you said is to normally x months... (I'd say 6-12 months) or riskers and go nuts.

Thank you for replying.. have a good weekend.

5nowman

Morshale · May 2, 2025

Created an account just so I could post this:

Hi Matthew,

Greetings from Microsoft!

Thank you for your detailed update and for sharing the timeline and observations regarding the issue following the upgrade of your Domain Controller to Windows Server 2025.

Based on your description and recent findings from both Microsoft and the broader IT community, the issue you're encountering is part of a known bug affecting Windows Server 2025 Domain Controllers, particularly in environments with Windows 11 23H2 clients.

Issue Summary

Error Message: “The Security Account Manager failed a KDC request in an unexpected way.”
Lookup Type: 0x108
Client Impact: A Windows 11 23H2 laptop lost its trust relationship with the domain shortly after the 2025 DC was introduced.

Root Cause (As Identified by Microsoft and Community Reports)

Kerberos Bug in Server 2025:
- A bug in the Kerberos implementation of Server 2025 causes failures when processing timestamps beyond the year 2038.
- This affects TGT issuance, Cisco RADIUS integrations, and client authentication.
- The issue is traced to the krb5int_gmt_mktime function in the Kerberos library
Machine Account Password Update Failure:
- Workstations authenticating against 2025 DCs are unable to update their pwdLastSet attribute.
- After 30 days, the machine password expires, resulting in trust relationship failures.
No Fix Available Yet:
- As of the latest updates, Microsoft has not released a patch to address this issue.
- The problem persists even after the February 2025 cumulative update.

️ Recommended Actions

Immediate Workarounds

Repair Trust on Affected Clients: Run the following on the affected machine:

   Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Temporarily Disable Machine Password Changes (if needed):

   reg add HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters /v DisablePasswordChange /t REG_DWORD /d 1 /f

⚠️ This is a temporary workaround and not recommended for long-term use due to security implications.

Reset Computer Account in AD:
- Reset the machine account in Active Directory.
- Rejoin the domain if necessary.

Optional: Isolate the 2025 DC

If the issue is widespread, consider:

Adjusting site link costs to prevent clients from authenticating against the 2025 DC.
Or temporarily demoting the 2025 DC until a fix is available.

References

Microsoft Q&A: Server 2025 Domain Controllers - Trust relationship issues [1]
Microsoft Learn: Broken trust relationship between domain-joined device and its domain [2]

Next Steps

We recommend implementing the above workarounds for affected clients and monitoring for further issues. We are also actively tracking updates from Microsoft and will notify you as soon as a fix is released.

Please let us know if you'd like assistance applying any of these steps or if you'd prefer to temporarily isolate the 2025 DC from authentication duties.

Edited May 2, 2025 by Morshale

Morshale · May 2, 2025

I should add that I got this reply from Support today (5/2/2025). He mentioned the Feb CU, but since then there has been both the March and April CU and neither of those has a fix. I'm demoting the DC today and spinning up a 2022 to replace it.

Tech9d5 · July 17, 2025

Win11 22H2 and 23H2 now have a patch that addresses this issue in KB5060826. I've yet to test if this fully resolves this issue

[Authentication] Fixed: This update fixes an issue where domain-joined machines running Windows 11 22H2 or 23H2 couldn’t update their account passwords on Windows Server 2025 domain controllers, which led to trust relationship issues.

https://support.microsoft.com/en-us/topic/june-26-2025-kb5060826-os-builds-22621-5549-and-22631-5549-preview-65d38dd2-e149-4462-9699-e2482f60b16b

interslice · August 21, 2025

Just to add our experience with this:

We used to run 2x Server 2019 DCs.

In July, I spun up a Server 2025 DC - promotion went fine and all looked good initially however, dcdiag wouldn't pass the DNS server tests at all (basic tests failing). Whilst replication was fine (repadmin tests) and even the DNS side of things looked fine (records etc. matched the others), dcdiag wouldn't pass these tests - this seems to be something to do with DNS cache and how the process runs on the different OSs (WIN32_OWN_PROCESS, expected value WIN32_SHARE_PROCESS was the repeated error) > something to do with how svchost works in Server 2025 to increase stability.

In the end, I demoted and removed the Server 2025 DC and we went to Server 2022 for both instead. We have very little need for a domain and are close to serverless (some finance/file share requirements still, but hopefully finance will move to a cloud-first solution soon!).

We'll maybe try again with Server 2025 next summer!

aac · August 21, 2025

Were still having strange issues here and have one 2019 and one 2025 DC. We are finding that sometimes you will boot up a PC and it states the username and password is correct even though we know it is 100% correct. Reboot again and it logs in fine, it is a bit random of an issue...

DrCheese · August 21, 2025

3 hours ago, aac said:

Were still having strange issues here and have one 2019 and one 2025 DC. We are finding that sometimes you will boot up a PC and it states the username and password is correct even though we know it is 100% correct. Reboot again and it logs in fine, it is a bit random of an issue...

Yes, that's exactly what we had until I removed our 2025 DC and went back to 2019. I did it before the Kerberos updates in April which in theory, fixed it but I'm still super wary about going back to 2025 on our DCs.

Same issue - Rebooting the PC would fix it.

aac · August 21, 2025

We were still seeing the same issue after July Cumulative update was installed on Win 11 24h2 machines and 2025 DC. Have just upgraded to August Cumulative update but not confident it is going to fix it.

ITGuyNW · August 21, 2025

5 hours ago, interslice said:

Just to add our experience with this:

We used to run 2x Server 2019 DCs.

In July, I spun up a Server 2025 DC - promotion went fine and all looked good initially however, dcdiag wouldn't pass the DNS server tests at all (basic tests failing). Whilst replication was fine (repadmin tests) and even the DNS side of things looked fine (records etc. matched the others), dcdiag wouldn't pass these tests - this seems to be something to do with DNS cache and how the process runs on the different OSs (WIN32_OWN_PROCESS, expected value WIN32_SHARE_PROCESS was the repeated error) > something to do with how svchost works in Server 2025 to increase stability.

In the end, I demoted and removed the Server 2025 DC and we went to Server 2022 for both instead. We have very little need for a domain and are close to serverless (some finance/file share requirements still, but hopefully finance will move to a cloud-first solution soon!).

We'll maybe try again with Server 2025 next summer!

Very much why I tend to stay one version behind. I will only update to 2022 at the moment for any servers.

aac · August 21, 2025

Its really frustrating they have not sorted this issue out yet, it really isn't a good look. I have a few servers running 2025 and every one of them has been fine apart from the DC.

aac · October 6, 2025

Still ongoing issues here, has anyone come across a fix or even a workaround other then to demote the 2025 DC?

ICT_GUY · October 13, 2025

I fixed the authentication issue. It would randonly work and fail.

I had a 2022 server as bdc and a 2025 PDC.

Server 2025 enforces stricter Kerberos encryption policies by default.
Older accounts (both users and computers) were still configured to allow RC4-HMAC or had no explicit encryption types set, so when authentication requests hit the 2025 DC, the tickets were rejected.
The 2022 DC was still accepting them, which made the issue appear intermittent depending on which DC answered the request.

Setting all accounts to AES for PCs and Users fixed the issues.

StephenPink · October 13, 2025

28 minutes ago, ICT_GUY said:

I fixed the authentication issue. It would randonly work and fail.

I had a 2022 server as bdc and a 2025 PDC.

Server 2025 enforces stricter Kerberos encryption policies by default.
Older accounts (both users and computers) were still configured to allow RC4-HMAC or had no explicit encryption types set, so when authentication requests hit the 2025 DC, the tickets were rejected.
The 2022 DC was still accepting them, which made the issue appear intermittent depending on which DC answered the request.

Setting all accounts to AES for PCs and Users fixed the issues.

Oooh interesting I think we might be having the same issue - did you set that via GPO? Any chance you can spill the deets of where exactly?

Cheers!

ICT_GUY · October 14, 2025

This is the paid for chat gpt generated summary.

With all such summarys it is not gospel but has all the info you need to trouble shoot it.

I also made the 2022 server the PDC. The issues were with old accounts using out dated security.

Root Cause

Server 2025 enforces stricter Kerberos encryption policies by default.
Older accounts (both users and computers) were still configured to allow RC4-HMAC or had no explicit encryption types set, so when authentication requests hit the 2025 DC, the tickets were rejected.
The 2022 DC was still accepting them, which made the issue appear intermittent depending on which DC answered the request.

🧠 Diagnosis

Using PowerShell, we listed accounts with missing or legacy encryption flags:

Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { $_.msDS-SupportedEncryptionTypes -eq $null -or $_.msDS-SupportedEncryptionTypes -eq 0 } | Select Name, SamAccountName

and similarly for computers:

Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { $_.msDS-SupportedEncryptionTypes -eq 28 } | Select Name, DNSHostName

Accounts showing null, 0, or 28 were allowing RC4 or falling back to defaults.

🔧 Fix

Set all accounts to AES-only:
```
 
```
# For users Get-ADUser -Filter * | ForEach-Object { Set-ADUser $_ -Replace @{msDS-SupportedEncryptionTypes = 24} } # For computers Get-ADComputer -Filter * | ForEach-Object { Set-ADComputer $_ -Replace @{msDS-SupportedEncryptionTypes = 24} }

(24 = AES128 + AES256 only)
Create a GPO to enforce AES encryption:
- Path: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options
- Setting: Network security: Configure encryption types allowed for Kerberos
- Tick only AES128_HMAC_SHA1 and AES256_HMAC_SHA1.
- Link at the domain root.
Run gpupdate /force and reboot test clients.

✅ Result

After aligning all accounts and the GPO, authentication succeeded cleanly on both 2022 and 2025 DCs.
Event ID 4769 (Kerberos Service Ticket) now shows encryption 0x11 (AES128) or 0x12 (AES256) — no more RC4 (0x17) tickets.

🧰 TL;DR

Server 2025 won’t tolerate legacy Kerberos encryption.
Clean up account encryption flags to AES only (24).
Apply the AES-only GPO domain-wide.
Verify via Event ID 4769 that all tickets use AES.

mavhc · October 14, 2025

12 minutes ago, ICT_GUY said:

Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { $_.msDS-SupportedEncryptionTypes -eq $null -or $_.msDS-SupportedEncryptionTypes -eq 0 } | Select Name, SamAccountName

Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { $_.msDS-SupportedEncryptionTypes -eq 28 } | Select Name, DNSHostName

You'll be wanting single quotes around msDS-SupportedEncryptionTypes

Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { $_.'msDS-SupportedEncryptionTypes' -eq $null -or $_.'msDS-SupportedEncryptionTypes' -eq 0 } | Select Name, SamAccountName

Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { $_.'msDS-SupportedEncryptionTypes' -eq 28 } | Select Name, DNSHostName

ICT_GUY · October 14, 2025

Like I said the A.I. isn't the best at getting things right first time.

I did just ask it for a brief summary of around 2 to 3 hours trouble shooting.

It messes up code like a champ.

Thanks for spotting it.

aac · October 14, 2025

I have made these changes and will monitor for a while. Fingers crossed...

ICT_GUY · October 15, 2025

Also check your ad replication.

My two servers at the moment are not agreeing on which protocol to use to talk to each other.

My server 2022 PDC and the server 2025 BDC are not syncing and it is causing a lot of issues.

Now If i fix that this morning I will post what I did to fix it.

At the mopment I am around 1 hours trouble shooting away from removing the ad role from 2025 completely.

Also the RM ADSYNC applications were casing server 2025 to spontaneously reboot constantly.

All in all remvoing the BDC role is probably where I will end up if I keep having issues.

aac · October 15, 2025

repadmin/showrepl shows mine seem to be replicating without issue. I have made a few changes in AD and these appear to be reflected on the replication partner. Is it possible you had issues with replication prior to making the above changes?

Edited October 15, 2025 by aac