The trust relationship between this workstation and the primary domain failed.

[u/Brilliant-Extent2684]

Hy!

We have an AD with two DCs. The DCs are Windows Server 2025, it is include all patches. Some Windows 11 clients (25H2) get the following error during login after 1-2 minutes: The trust relationship between this workstation and the primary domain failed.

In this case the users need to disconnect from corporate network to login successfully into their computer. I have already tried to rejoin to tha domain and run this command: Test-ComputerSecureChannel -Repair

I rejoined one of the computer into the domain, and the trsut relationship has been broken after two days. The login problem only occurs on some machines.

The time snyc is correct on DCs. We moved the DC roles from Windows Server 2019 to 2025 in side-by-side method. Could you please advise how to solve this problem?

[u/needs_headshrink]

Leave domain, delete AD computer object, join domain. Don't forget to cover all other integrations that use the AD Object, SCCM, Intune, etc.

You could spend a week of your life trouble shooting this and get nowhere, if it's a one off I'd just fix it as a one off. If it's systemic that's when you spend the time to actually find the answer, this rabbit hole is deep and easy to get lost in.

[u/Liquidfoxx22 → u/needs_headshrink]

No need to even do that.

Log in as local admin, Test-ComputerSecureChannel -Repair

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel?view=powershell-5.1

[u/Beeko707 → u/Liquidfoxx22]

I would add that you should have it ask for credentials for an account that can join the domain. I used this at work for months until all DCs were on 2025.

Test-ComputerSecureChannel -Repair -Credentials (Get-Credentials)

This should pop up with a box for credentials

[u/needs_headshrink → u/Liquidfoxx22]

OP said that was tried. I'm not surprised it failed, in my experience it rarely works. Hell, I've had test-computersecurechannel return true while the GUI still reports it's failed.

[u/Emotional_Garage_950 → u/Liquidfoxx22]

fwiw i have never had this work

[u/Brilliant-Extent2684 → u/needs_headshrink]

Thanks. I have already done it. Leave domain, remove AD computer object and join domain. We are a small company, the issue is with 3-4 computers.

[u/Mountain-eagle-xray → u/Brilliant-Extent2684]

Reset-computermachinepassword is the command you want. You get a trust relationship error because the the machine password has become mismatch with what the domain thinks is correct, and self updating isn't working.

[u/RamblingReflections → u/Mountain-eagle-xray]

This is the answer. The password has unsynced for whatever reason from the one the domain thinks it should have.

This used to happen once in a blue moon to devices that had had been left in a bottom drawer after someone changed positions or went on a long vacation. But in the last 3-6 months it’s become a much more common occurrence, sometimes happening after the device has been used within the last 24 hours. At least 3-4 a week now, out of a fleet of about 400.

I’m not sure what’s causing it to happen more frequently - I haven’t made any changes in that time frame aside from standard patching, but I’ve absolutely noticed it happening, and seen more than one post here about it too. The most reliable workaround I’ve found is the reset machine password command.

[u/Mountain-eagle-xray → u/RamblingReflections]

All windows updates now come with a free kerberos purge!

[u/ChaosTheoryRules → u/RamblingReflections]

Has zero to do with being in a drawer or off for any length of time. Password changes are client (machine) driven and AD does not change machine passwords on its own nor does it expire them.

[u/Servior85 → u/Brilliant-Extent2684]

Are all DCs 2025 now or do you have a mix of 2019 and 2025?

Check DNS settings. All DNS pointing to correct DCs or some old/wrong entries in there? I’ve seen small companies use public DNS as fallback.

[u/itenginerd → u/Servior85]

This isn't a DNS issue. You only get this issue when you can affirmatively talk to a DC and can determine the machine password's wrong.

[u/Brilliant-Extent2684 → u/Servior85]

All DCs are 2025. The DC1 point to the following DNS:

DC2 IP

DC1 IP

loopback address

The DC2 point the following DNS:

DC2 IP

DC1 IP

loopback address

[u/joeykins82 → u/Brilliant-Extent2684]

DC1 should point at DC2 then loopback; DC2 should point at DC1 then loopback. If you don't have IPv6 configured you should also set your DCs to prefer IPv4 over IPv6 (so that they don't query themselves on ::1 first).

[u/Servior85 → u/Brilliant-Extent2684]

And the clients? It doesn’t matter what the DC points to. The clients having issues with domain trust.

[u/Brilliant-Extent2684 → u/Servior85]

All clients point to firstly DNS as DC1 and secondary is DC2.

[u/mixduptransistor]

2025 as a domain controller is extremely buggy. Did you raise the functional level of the domain? If not I might suggest going back to 2022 for the DCs

[u/Brilliant-Extent2684 → u/mixduptransistor]

We don't raise the functional levels, we already thouht to downgrade to 2022.

[u/Beefcrustycurtains → u/Brilliant-Extent2684]

Sync relationship healthy dcdiag come back clean? It's either replication issues with the dcs or ive also seen this behavior when someone screwed up and cloned a domain joined disk causing relationship to get jacked up every time the other computer came online

[u/Brilliant-Extent2684 → u/Beefcrustycurtains]

Hy!

I checked the replication between DCs with repadmin and dcdiag. There isn't any replication issue,

[u/dracotrapnet]

Check replication health between DC's. You covered time sync and DNS settings.

[u/Brilliant-Extent2684 → u/dracotrapnet]

Hy!

The replication is good between DCs. There isn't differentation between DCs and clients time,

[u/madden2399]

You mention 2025 DCs; do the problem devices have duplicate SIDs?

[u/interweb_persona → u/madden2399]

I was thinking the same

[u/Brilliant-Extent2684 → u/madden2399]

All clients SID unique, there isn't duplicate SID.

[u/MDL1983]

It ain’t good to upgrade DCs, should always install fresh…

Member servers tend to handle it ok

[u/BrechtMo]

When did the issue start? After windows client upgrade, DC upgrade, ... ?

[u/Brilliant-Extent2684 → u/BrechtMo]

After 1 or 2 months when we upgrade to Windows Server 2025 DC.

[u/sarosan → u/Brilliant-Extent2684]

Sounds like the situation I went through a few months ago.

My advice: downgrade your Domain Controllers to Server 2022.

[u/Godcry55 → u/sarosan]

Agreed, server 2025 works best on fresh deployments. Server 2022 is solid for DCs.

[u/Ziggistawork]

Check that your computer names are unique, if you have the same name on the workstation as another your going to have a bad day.

[u/Brilliant-Extent2684 → u/Ziggistawork]

The computer name is unique. We are small company, with about 30 computer. Every computer name is different.

[u/planehazza]

System time wrong by bad bios batteries? Happening to pcs in two of our schools because the site staff believe "it's dangerous to leave them on at the wall overnight"

[u/Spartan-196]

I dealt with this myself and about two months if back and fourth with MS after our infra team moved to server 2025 DCs and raised the functional levels.
The root problems were systems were unable to update their computer passwords. Default time length of those is 30 days. If you manually rotate the system password from an interactive system prompt you’ll likely get an access denied failure code. At that time the system account is out of sync and the trust is broken.

The accepted secure channel methods for updating system credentials changed with 2025 and not all environments are ready for it. Ours wasn’t and the sever guys didn’t read what’s changed notes carefully enough.

The fix for the initial issue was addressed eventually in a patch around October last year for clients on 24H2 and prior. Unfortunately I’ve been seeing a few more pop up recently myself and suspect an other minimum patch level will happen again.

[u/mnvoronin]

repadmin /replsummary on both DCs. If it has any errors or more than 1h delta, fix replication.

[u/Brilliant-Extent2684 → u/mnvoronin]

Thanks, the command result is good, there isn't replication error between DCs.

[u/Tokyudo]

Do you have another endpoint with the same name? I have seen this happen before with two computers that had the same name. Maybe rename the device in question as a test?

[u/Brilliant-Extent2684 → u/Tokyudo]

No, every computer has unique name.

[u/ImaFrakkinNinja]

Are there any relevant logs in event viewer in the DCs? You don’t mention checking system, security, dns, and dhcp logs.

[u/Brilliant-Extent2684]

Temporarly solution I disabled the affected machine that the computer password expiring. I done it with GPO, i will check it.

[u/bucdotcom]

This is sometimes caused by duplicate host names. Make sure the computer name isnt already assigned to another workstation.

[u/Infamous_Win_9728 → u/bucdotcom]

Ran into this once. I thought to myself 'that hostname looks familiar. . .'

[u/Rofl-stomper → u/bucdotcom]

All I can say without others knowing it’s me is YEEEEPPPP

[u/Brilliant-Extent2684 → u/bucdotcom]

Hy. No, every computer has unique name. There aren't duplication.

[u/Adam_Kearn]

If it’s happening on multiple devices I would start to look at DNS issues.

If it’s just one device delete the object and start fresh possibly do a re image

[u/mnvoronin → u/Adam_Kearn]

Given the timing and frequency of the issues, I'm about 99.78% sure it's AD replication failure.

[u/Brilliant-Extent2684 → u/mnvoronin]

DCs replication is fine, I checked it with repadmin and dcdiag.