Windows Server 2025 DCs causing trust relationship problems on client devices

[Daradon]

Ok thats strange. Maybe server update from today bring us something?

[ErDT]

The same behaviour continues on our environment where on my 2 test machines 23H2 breaks every 24/48 hours but 24H2 continues to work. My colleagues Test environment also behaves in the same way where 23H2 breaks but 24H2 (upgraded from 23H2) and 24H2 direct builds work correctly. Also obviously within our production environment i have seen Windows 10 and iMacs embedded into windows continue to work as expected so I'm fairly confident its a 23H2 bug. I cant be 100% sure that there aren't other bugs that then also effect other operating systems but to me 23H2 is the most affected.

 

Unfortunately the sites where I moved our DC's onto 2025 were primarily 23H2 because i had been delaying 24H2 due to all the bugs that Microsoft were fixing which is ironic (though from what i have read of the bugs i don't think they will effect us greatly). I am moving all of our 23H2 clients up to 24H2 now as i think this is likely to help at the very least as 24H2 and 2025 are based upon the same underlying operating system build.

 

I dont believe Microsoft are likely to have fixed the issue in the January cumulative update as whilst i saw some CVE fixes that could relate i don't personally think they are the fix. The Microsoft forum thread i created, the Microsoft employee once they confirmed it was an issue then asked us to report it via "Feedback Hub", which is beyond ridiculous considering all the legwork had been done in the thread that she wasn't going to escalate it considering the severity of the issue. Thread is below if interested.

 

https://answers.microsoft.com/en-us/windowserver/forum/all/server-2025-domain-controllers-trust-relationship/4ef17f8e-8677-4ecd-a675-e5df1f4b48cf?page=1

Edited January 15, 2025 by ErDT

[miljw002]

Hi All,

 

I’ve just reviewed the thread over on Microsoft (https://answers.microsoft.com/en-us/windowserver/forum/all/server-2025-domain-controllers-trust-relationship/4ef17f8e-8677-4ecd-a675-e5df1f4b48cf?page=2) people were referring to.

 

Based on one post in there, I could see Server 2025 has now blocked by default old/legacy/less secure methods to remotely change passwords.

 

 

As of about 30 minutes I’ve changed this on my DC’s and ESXi has stopped the constant errors about can’t change passwords. I’ll need to monitor and test more, but enabling the old methods seems to have at least stopped the ESXi errors. Also, looking in AD at the ESXi computer objects I can see the password last updated value finally updated.

Edited January 17, 2025 by miljw002

[ErDT]

Hi

 

I'm actually the person who suggested that one in that thread, it would be pretty funny if that was the fix as it was the one thing i didn't actually make changes regarding to test but stood out to me as a possibility when reading through the 2025 change logs. Will have to test it and see if any effect on our side.

[miljw002]

Hi,

 

Your idea was the first good lead I’d seen of what’s different but it’s not the complete picture. Enabling the old methods allowed ESXi to update their passwords and those errors are gone. The bad news is Linux in general still isn’t working with SSSD (still password change errors), and I’m still seeing KDC errors.

 

Microsoft has certainly broken this well, and seems really slow to fix.

[miljw002]

Hi Again,

 

I did more testing on Linux (Redhat 9) trying to join with SSSD and it's still failing with the same errors after the CU update for Jan 2025. Did some more Googling and it looks like there is a regression in Windows Server 2025's Kerberos implementation.

 

https://gitlab.freedesktop.org/realmd/adcli/-/issues/40

 

The prediction in that thread is it may take until the March CU to fix this.

[psydii]

Ah, that issue opens with a comment from Ned "NTLMv2 must die" Pyle (until very recently part of the Windows Authentication team), has a (reposted) comment from Steve Syfuhs (still of the Microsoft Auth team) and ends with Ned "unofficially" advising of the timeline for a fix. I can't help but feel that this really would have got to the product team faster if one of the early adopters in this thread had opened a ticket with MS Support.

[iamwinauser]

Since upgrading my domain to 2025, I've been encountering trust relationship issues daily on 8-10 PCs. Today, I disabled the machine password policy in Group Policy. I will provide an update tomorrow/DAT to confirm if this resolves the issue temporarily.

[iamwinauser]

Since upgrading my domain to 2025, I've been encountering trust relationship issues daily on 8-10 PCs. Today, I disabled the machine password policy in Group Policy. I will provide an update tomorrow/DAT to confirm if this resolves the issue temporarily.

 

No trust Relationship error today

[Daradon]

I updatet all our Clients ( like 300 PCs) to WIN11 24H2 in the last days. Now i will see if it is fixing the bug like other guys said.

[psydii]

The Windows Authentication team have confirmed it as a bug in how AD on Server 2025 handles machine account password changes. Since the (server) bug also impacts linux (and probably macos) based kerberos integrations, it is unlikely a fix will come in the form of a client-side update.

 

Until the bug is fixed in Server 2025, all deployments of 2025 as DCs should be on hold.

[Daradon]

A lot of people here snd in the ms forum were writing that no problem with 24h2 exist

[psydii]

maybe, but since it is machine password related, then it will take up to 30 days after you have upgraded/re-imaged a machine to 24h2 to be sure that 24H2 is a fix. Most of the observations that it is fine with 24h2 are from people who have just tried it as a fix, and are still inside the 30 day lifetime of the initial machine password.

 

For those whose 23H2 and older devices were dropping off every few days, it seems likely that there is also some other setting/bug in play causing a more rapid machine password reset timeline, tripping them into the 2025 bug more swiftly than one would expect with the standard 30 day cadence.

[Daradon]

Thats not true. People were setting password reset to 1 day with gpo. I also. No Problem with 24h2.

Read the full ms thread

[ErDT]

Hi

 

So i am only testing with a couple of devices (1 on 23h2 and 1 on 24h2) at the moment as i roll out 24h2 to the machines at the effected sites because all the rest of the machines i have scripts auto running on them to run the manual process to keep them in trust for the moment. I have found that 24h2 doesn't appear to lock out the machine as of yet but it also doesnt change the password on the machine or AD at least not with the 1 test device I'm using. 24H2 appears to correctly interpret that the password hasn't been updated on AD via the 2025 DC and so doesn't finalize the machine password reset on itself.

 

I have recently added the setting below to my testing on DC's at my test site which appears to have allowed my 23h2 device to update its password yesterday (i need to see it do a few more times to be confident it is actually doing it). My 24H2 client still hasn't reset its password now for a week so it may not have any effect on 24h2 which i would assume is because it has increased security requirements that 23h2 does not. It could also have been related to updating the DC to the latest cumulative update but i doubt it based on the thread i saw with a couple of Microsoft developers suggesting the underlying issue wont be rectified until the Feb or March CU.

 

Edited January 23, 2025 by ErDT

[ErDT]

So putting the below setting on the DC appears to have allowed my 23H2 test device to update its password as expected again yesterday, 24h2 continues to not update but also not break itself.

 

 

Hi

 

So i am only testing with a couple of devices (1 on 23h2 and 1 on 24h2) at the moment as i roll out 24h2 to the machines at the effected sites because all the rest of the machines i have scripts auto running on them to run the manual process to keep them in trust for the moment. I have found that 24h2 doesn't appear to lock out the machine as of yet but it also doesnt change the password on the machine or AD at least not with the 1 test device I'm using. 24H2 appears to correctly interpret that the password hasn't been updated on AD via the 2025 DC and so doesn't finalize the machine password reset on itself.

 

I have recently added the setting below to my testing on DC's at my test site which appears to have allowed my 23h2 device to update its password yesterday (i need to see it do a few more times to be confident it is actually doing it). My 24H2 client still hasn't reset its password now for a week so it may not have any effect on 24h2 which i would assume is because it has increased security requirements that 23h2 does not. It could also have been related to updating the DC to the latest cumulative update but i doubt it based on the thread i saw with a couple of Microsoft developers suggesting the underlying issue wont be rectified until the Feb or March CU.

 

[ATTACH=CONFIG]72999[/ATTACH]

Edited January 24, 2025 by ErDT

[ErDT]

Having said what i said above, i realised i had a 24H2 client at another site which i built fresh and was testing as well which is updating its password correctly, so i think my 24h2 test machine at the first site may have a further separate issue.

[MartinDT]

Did anyone work out if the issue is resolved? It's gone a little quite here.

 

I still have "Disable machine account password changes" enabled, so was wondering if it's safe to enable them again.

[ErDT]

Hi Martin

 

If you still have windows 11 23H2 in your environment then no i wouldn't recommend you enable it again, you need to either upgrade all of them to 24H2 or wait out for the next cumulative update or possibly the one in March to hopefully have a real fix in. I am finalising all remaining 23H2 devices at one site up to 24H2 during the next break and re-enabling normal behaviour (disabling my script that runs the repair channel command each day). So will know a bit more after the break if 24H2 is a total fix or not in spite of the server side fix not being out yet.

[aac]

While we only updated one of our 2 DC's to 2025 and have not seen any of the issues discussed here I am keen to see if anyone has taken the plunge and tried the 2025-02 Cumulative update yet to see if that fixes anything? I'm not touching my other DC until were 100% Microsoft has sorted things out...

[k-strider]

looking at this i doubt its been fixed in the feb update

https://support.microsoft.com/en-gb/topic/february-11-2025-kb5051987-os-build-26100-3194-6cc1a435-9c1a-42b8-8c4d-b34253784452

[StephenPink]

Not directly related to this - but have got 1 2022 DC and 1 2025 DC and the 2025 definitely has some odd behaviours;

- Kerberos Local Key Distribution Center service is stuck "Start Pending"

- Defender Firewall sets itself to "Public"

- NETLOGON error on boot - This computer was not able to set up a secure session with a domain controller in domain XXXXX due to the following: An internal error occurred.

 

No issues on the 2022 DC; this is currently the Master still. the 2025 has had the 2025-02 Cumulative Update applied yesterday and no change. All very odd!

[IanT]

Not directly related to this - but have got 1 2022 DC and 1 2025 DC and the 2025 definitely has some odd behaviours;

- Kerberos Local Key Distribution Center service is stuck "Start Pending"

- Defender Firewall sets itself to "Public"

- NETLOGON error on boot - This computer was not able to set up a secure session with a domain controller in domain XXXXX due to the following: An internal error occurred.

 

No issues on the 2022 DC; this is currently the Master still. the 2025 has had the 2025-02 Cumulative Update applied yesterday and no change. All very odd!

 

https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

[ErDT]

Hi

 

1. The Kerberos local key distribution center service on "start pending" is expected behavior apparently at the moment. Saw a forum post where the person who apparently coded it says its not yet active and in use so it being in that state doesn't cause any issue.
   
2. Defender firewall setting itself to public is a bug with 2025 Domain Controllers they have not rectified yet, i have a script in place via task scheduler that on power up if the DC's ethernet port is set to anything other than domain it resets the network, this rectifies the issue and sets it to domain within a min or 2 of the DC power on after reboot. Only way i'm aware of to rectify it currently.
   

 

Your 3rd issue I'm not sure the underlying cause as ive not come across it.

 

 

Not directly related to this - but have got 1 2022 DC and 1 2025 DC and the 2025 definitely has some odd behaviours;

- Kerberos Local Key Distribution Center service is stuck "Start Pending"

- Defender Firewall sets itself to "Public"

- NETLOGON error on boot - This computer was not able to set up a secure session with a domain controller in domain XXXXX due to the following: An internal error occurred.

 

No issues on the 2022 DC; this is currently the Master still. the 2025 has had the 2025-02 Cumulative Update applied yesterday and no change. All very odd!

Edited February 19, 2025 by ErDT

[StephenPink]

Hi

 

1. The Kerberos local key distribution center service on "start pending" is expected behavior apparently at the moment. Saw a forum post where the person who apparently coded it says its not yet active and in use so it being in that state doesn't cause any issue.
   
2. Defender firewall setting itself to public is a bug with 2025 Domain Controllers they have not rectified yet, i have a script in place via task scheduler that on power up if the DC's ethernet port is set to anything other than domain it resets the network, this rectifies the issue and sets it to domain within a min or 2 of the DC power on after reboot. Only way i'm aware of to rectify it currently.
   

 

Your 3rd issue I'm not sure the underlying cause as ive not come across it.

Thank you for that - are you able to share that script at all? I've tried manually disconnecting/reconnecting, restarting various services, but just cannot get it to recognise as domain profile... which may be causing that 3rd issue anyway potentially!