Jump to content

Windows Server 2025 DCs causing trust relationship problems on client devices

tayyab12

By tayyab12
in Windows Server 2025

 Share

Recommended Posts

ICT_GUY

ICT_GUY

Posted
Posted (edited)

I have fixed mine now, secure channel was broken between the two domain controllers. 

Well that was fun 🙂

I think it was to do with applying the Gpo to the domain controllers. Something went wrong. Restting the machine pa

 

Though I had issues with time sync, differening encryption level defaults with 2025 and 2022. 

Fingers crossed they are now talking to each other as they should have been.

 

 

 

 

Edited by ICT_GUY
ICT_GUY

ICT_GUY

Posted
Posted

This is Generated as a summary from my trouble shooting. It is A.I. generated so use it as a guide.

I would reccomend checking everything, more over use chatgpt 5 to trouble shoot with you. My servers had trust issues and wouldn't talk to each other. Fixing the machine password is what eventually fixed the issue. It was a long and involved troule shooting process on a live but broken system. Now my servers are replicating. Rebooting clients is a must after the fix.

 

More over this is a sumary of what i did. Do not rely on it as a fix.

Fix the secure channel between PDC and BDC (Domain Controllers)

Who this is for: Any AD with at least two DCs (call them PDCNAME and BDCNAME) in domain CONTOSO.local.
Run all commands elevated. Replace placeholders with real names.

0) Quick verification (both DCs)

On each DC: 

 
 
nltest /sc_verify:CONTOSO.local

  • NERR_Success = secure channel OK

  • Anything else = repair that DC (start with the non-PDC DC)

1) Repair the non-PDC DC (BDCNAME)

Do this on BDCNAME using a Domain Admin account (CONTOSO\DAUSER).

  1. Make sure Netlogon is running: 

 
 
sc query netlogon | find "RUNNING" || powershell -command "Start-Service Netlogon"

  1. Reset BDC’s machine account password (local secure-channel secret): 

 
 
runas /netonly /user:CONTOSO\DAUSER cmd netdom resetpwd /server:BDCNAME /userD:CONTOSO\DAUSER /passwordD:* /SecurePasswordPrompt

  1. Bounce auth services & clear Kerberos tickets: 

 
 
powershell -command "Restart-Service kdc -Force; Restart-Service netlogon -Force" klist purge

  1. Verify: 

 
 
nltest /sc_verify:CONTOSO.local

You want: NERR_Success.

2) Cross-align from the PDC (recommended)

Do this on PDCNAME (PowerShell), still as CONTOSO\DAUSER. 

 
 
$cred = Get-Credential CONTOSO\DAUSER Reset-ComputerMachinePassword -Server BDCNAME.CONTOSO.local -Credential $cred Restart-Service kdc -Force Restart-Service netlogon -Force

3) Replication sanity

From either DC: 

 
 
repadmin /syncall /AdeP repadmin /replsummary repadmin /showrepl PDCNAME repadmin /showrepl BDCNAME

Good = 0 fails and recent “Last success” on all partitions.

4) If repair won’t stick (fast checks)

On the problem DC:

  • DNS client points to DCs (not public DNS):

    • Preferred DNS = the other DC’s IP

    • Alternate DNS = 127.0.0.1 (or its own IP)

  • Time in sync (skew < 5 minutes): 

     
     
    w32tm /resync /force

  • Ports reachable to partner DC: 88, 135, 389, 445, 464 (and 3268/3269 if GC). 

     
     
    Test-NetConnection PARTNERNAME -Port 135

  • Netlogon/KDC running: 

     
     
    sc query netlogon & sc query kdc

  • No duplicate SPNs: 

     
     
    setspn -X

5) One-liner summary for a teammate

On the BDC, start Netlogon →
netdom resetpwd /server:BDCNAME /userD:CONTOSO\DAUSER /passwordD:* /SecurePasswordPrompt →
restart KDC/Netlogon → nltest /sc_verify:CONTOSO.local.
(Optionally from the PDC, run Reset-ComputerMachinePassword -Server BDCNAME... and restart services.)
Finish with repadmin /syncall and confirm 0 fails.

That’s it. This fixes 99% of PDC↔BDC secure channel issues and gets replication moving again.

StephenPink

StephenPink

Posted
Posted

Do you think that the GPO alone would resolve the issue? Just thinking in case of issues, easier to undo... 

Seems like it should - and removing the older auth from users/devices is more belt and braces, but just want to check I've read up correctly. 

Cheers

ICT_GUY

ICT_GUY

Posted
Posted

This is where it gets tricky. I can only say what I did, and to be fair it was not a fun experience. 

I would use what I put as a place to start your research. I would say I think the issue was something along the lines of if the clients were talking to the 2022 server they worked if they authenticated to the 2025 server it just gave wrong passsword error. The group policy should fix it, it might take a couple of restarts. But again I am unsure why my two servers started not talking to each other. I was very close to removing the 2025 server as a BDC. 

StephenPink

StephenPink

Posted
Posted

So weirdly the GPO + the user/computer settings have actually made things WORSE for us in my testing so far... now getting the incorrect username/password message more often than not! So confused... and frustrated that I still haven't been able to make any progress on this :(

ICT_GUY

ICT_GUY

Posted
Posted

I did have to make sure time was syncing to a reliable source and the whole  network was pointed at the PDC for time. If a reboot on the client sometimes fixes the issue thats what confirmed to me that it was an authentication issue. basically if it talked to the right server it would authenticate, if it talked to the other one it would give the wrong password error. 

 

In short I had to make sure all accounts were set to use the correct authentication, that was by using a powershell script. It was something to do with acconts created on server 2022 or earlier would have the inncorrect settings. The script reset these older accounts. Computer and user.

 

If your group policies are  set up correctly you should be able to set up a new test pc and a test account and that should work every time. As long as the servers are set to use the correct authntication protocol.

 

It was a complete ball ache to be fair and I only fixed by leaning heavily into trouble shooting with chatgpt. 

 

In simple terms windows 11 and server 2025 default to the more secure authentication and throw a fit if either client or server uses a less secure method. Again it was one of those problems that was so far outside of anything I had ever trouble shooted before I still don't quite know exactly all of the process.

  • Like 1
  • 3 weeks later...
AUSDread

AUSDread

Posted
Posted (edited)
On 21/10/2025 at 00:43, ICT_GUY said:

I did have to make sure time was syncing to a reliable source and the whole  network was pointed at the PDC for time. If a reboot on the client sometimes fixes the issue thats what confirmed to me that it was an authentication issue. basically if it talked to the right server it would authenticate, if it talked to the other one it would give the wrong password error. 

 

In short I had to make sure all accounts were set to use the correct authentication, that was by using a powershell script. It was something to do with acconts created on server 2022 or earlier would have the inncorrect settings. The script reset these older accounts. Computer and user.

 

If your group policies are  set up correctly you should be able to set up a new test pc and a test account and that should work every time. As long as the servers are set to use the correct authntication protocol.

 

It was a complete ball ache to be fair and I only fixed by leaning heavily into trouble shooting with chatgpt. 

 

In simple terms windows 11 and server 2025 default to the more secure authentication and throw a fit if either client or server uses a less secure method. Again it was one of those problems that was so far outside of anything I had ever trouble shooted before I still don't quite know exactly all of the process.



Found this thread after going through VERY similar issues here ... I have a very old domain, it kicked off way back in 2003 and has been successively upgraded to each new Server as the years progressed. Like many of you - I ran some MS Patches a few weeks ago and have been absolutely smashed now with all kinds of issues on my once harmonious domain. 

I went down this same rabbithole with ChatGPT over the past week and discovered ALL of our User and Computer accounts were still using old RC4 authentication even though they all had the ability to use AES 128 and AES256 and it was falling back to that, successfully, for years - until MS released that patch a few weeks ago. I had ChatGPT walk me through and created a few scripts that updates ALL Users and PC's to be set at 28, meaning they are now using AES128 and AES256 and I thought well 'job done' ... but now my network is running like a proverbial Dog and I'm suspecting its a DNS issue, but intermittently, and its killing the network :(  

First users were reporting SSL errors going to HTTPS websites ... digging in, on the affected website, it was showing the proxy cert from our Sophos Firewall instead of the sites expected websites SSL cert. Then users were sending me screenshots of Security Alerts in Outlook with Outlook reporting SSL errors with autodiscover.outlook.com (we run Hybrid O365) and again its showing our Firewalls cert and not the expected outlook certs. I double checked the firewall - SSL Scanning is NOT enabled anywhere (as ChatGPT said it was doing). I re-added firewall exceptions (even though they were already in my master list of O354 exceptions that included SSL Scanning, Cert checks etc). I checked with users and a few refreshes of the web browser or waiting 10 minutes and trying again - and it worked fine. But then would come up with the exact same errors minutes later. Same thing was happening with my ADSyncCycles from the DC. I could run it manually from powershell and it would sync fine ... then two minutes later it would spit out a bunch of errors because the connection attempt timed out. Then just the internet was abysmally slow for everyone ... all the hallmarks of a DNS issue somewhere ... but all my DC's tested fine, DNS said it was working fine, every DCDIAG was coming up clean and successful.

I've created a new service account and given it FULL permissions to every single DNS forward and reverse zone, added it into DHCP (Advanced, DNS Dynamic update creds), and added the account to the DNSProxy group in AD. Both DC' point at each other in DNS, then 127.0.0.0 as secondary's ... I'm coming up with nada and still have a dirt slow network ... 

I am also <--> close to running up a 2022 server and dumping 2025 ...

Edited by AUSDread
ICT_GUY

ICT_GUY

Posted
Posted

So what seemed to work in simple terms.

Fixed time sync.

Fixed the AD sync issues between the two servers.

The GPO to force the right authentication across the domain.

Then run a script to update all old computer and user accounts.

So far it has worked.

Obviously there a lot more to it, but that is the simple break down of what worked for me.

 

ICT_GUY

ICT_GUY

Posted
Posted

And I have server not working properly again.

This time clients randomly it seems can't pull down group policies, it seems to have broken with a recent windows update.

Some times the clients do work, sometimes they don't.

Server 2025 isn't playing well with server 2022.

When the logon server is the 2025 it seems to work, if it is the server 2022 server it breaks.

Great fun all round TBH.

ICT_GUY

ICT_GUY

Posted
Posted

Secure channel between the two dcs broke again.

At the moment the choice is demote the 2025 machine, or keep fixing secure channel every few months.

Great.

ICT_GUY

ICT_GUY

Posted
Posted

I am thinking of removing AD from the BDC 2025 server and just use it as a file server for the moment.  I have an older Server  that I was using as a media server running server 2022 that I will promote back to a BDC. 

 

The specific error is that on some reboot clients can log in but not update group policy. Not all the time either, only some times. That error is that the domain controller is unavailiable. However dns works, permissions work for shares. 

 

Now server 2022 worked just fine before, the problems only started when I threw a new server 2025 into the mix. 

 

I will trouble shoot today again and then if I can't fix it I will be pulling the plug on having ad on server 2025.

ICT_GUY

ICT_GUY

Posted
Posted

Well that was a rabit hole.

The fix was to remove a group policy that set AES encyption on the domain controllers and Computers

Then on each DC run secpol.msc and did the following.

On the servers local security policy Network security configure encryption types for kereros and tick RC4_HMAC_MD5 and AES 128 and 256.

The replication and group policy started working again.

Clients are now happy no matter which DC they logon to or talk to.

So much Fun!

ICT_GUY

ICT_GUY

Posted
Posted

Digging even further, removing the gpo to enforce which encryption to use put me back in the random password is incorrect issues. This is due to clients not being able to talk to the login server.

So putting a GP onto the computer OU only to enforce the same settigns seems to have fixed that.

My best guess is that when an update breaks AD syncing, then the GP that enforces authentication breaks so isn't applied to one of the servers. It then defaults back to another encrption type. 

By setting the encrption types as a local policy on each DC that should make it permanent. 

Fingers crossed things are working at the moment, don't tell microsoft or they will patch that for sure.

  • 1 month later...
mulbzh

mulbzh

Posted
Posted

Hello and sorry for my english,

 

Same problem for me since i upgrade my DC from Win 2016 to win 2025 : trust relationship errors on some computers.

Finally, there is KB by Microsoft for that or not ?

mulbzh

mulbzh

Posted
Posted

I found this KB for 24H2 : https://support.microsoft.com/en-us/topic/april-8-2025-kb5055523-os-build-26100-3775-277a9d11-6ebf-410c-99f7-8c61957461eb
 

  • [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.

but i have somes computer with 23H2, i don't find KB for this version

  • Like 1
ICT_GUY

ICT_GUY

Posted
Posted

Another piece to the puzzel.

So my work machine even after all the other fixes started to play up again with random wrong password.

Removing it from the domain and now it works fine.


So my thoughts are that it is to do with machine keys on the server being wrong. Perhaps when the server were not syncing.

 

Who the hell knows. 😞

 

Also server 2025 will not let the rm ad sync to run, at least last time I tried to install it would randomly reboot every 5 minutes.

mulbzh

mulbzh

Posted
Posted

For me, i can't add new DC windows 2022 because i use new LAPS (legacy LAPS was uninstalled) and new LAPS is not available on windows 2022. I have to stay on windows 2025.

I don't undertsand because staff computers works very well, no problem trust relationship but others computers have troubles. But it is the same OS version. But i sure it is because kerberos, i can see logs

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing


×
×
  • Create New...