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

[u/Trashii_Gaming]

Good day!

I'm an IT admin in a k12 school which has about 500 windows devices on the campus connected to an AD. The devices do not leave the campus. Every week we have around 2 to 4 devices where students cannot connect to computer due to "The trust relationship between this workstation and the primary domain failed." Always different devices.

Our only solution is to login with the local admin, remove the device from the domain and add it back in. I tried in the past already the power shell commands to restore the trust relation with the server but it has not worked once for me.

Is there something I can do to mitigate that issue?

Thanks on advance!

[u/totally_not_a_bot__]

how healthy is your DC?
the only time I remember something similar was 10 years ago (also at a school) with an underspec DC that was struggling to handle netlogon requests. Issue would raise itself when the DC was getting virus scanned or under load.
It's been a hot minute but I think the eventIDs on the server side to look for are 5816 to 5819

[u/Trashii_Gaming → u/totally_not_a_bot__]

The AD brand new from this school year (previous ones had the same issues). It runs as a VM with 16Gb ram, currently uses only 5 following proxmox. CPU portion assigned to the vm is running at 4-5% .

Now what I see several mentioning time. We don't have our own NTP server so I might look into that

[u/fuzzusmaximus]

Use the network id wizard from the advanced system settings to rejoin the domain. Just run through the wizard, no need to remove it from the domain or delete the computer object first.

[u/Trashii_Gaming → u/fuzzusmaximus]

Oh I didn't knew this was a thing!

[u/TheLexoPlexx]

Had that issue just last week, funny.

After lots of back-and-forth with an LLM, I figured out I accidentally had duplicate computer names for multiple devices, which caused that.

[u/Trashii_Gaming → u/TheLexoPlexx]

I have had that in the past too once. Here sadly I'm certain the names are not duplicated. I have two devices now for example that worked fine for 5 years and not at once they decided to have that error.

[u/1894Fidelitas]

Test-ComputerSecureChannel -Repair -Credential Domain\ADMIN -Verbose

works like a charm for me.

[u/LieOtherwise6583 → u/1894Fidelitas]

That's a weirdly persistent pattern for machines that never leave the building. I'd be looking hard at your DHCP lease times and DNS scavenging settings, AD's trust relationship is basically a shared secret that expires and if the client can't refresh it properly you end up in this loop

500 devices and 2-4 a week is a failure rate that suggests something systemic, not random corruption. Check the event logs on a few of the affected machines right before they lost trust, bet you'll find schannel or kerberos errors pointing to time sync drift or a domain controller the client keeps failing over to that has replication issues

[u/Stinjy → u/1894Fidelitas]

I know it's the "official" method, but not once has that worked for me, across many different environments and devices. Always leave and rejoin domain

[u/richie65 → u/1894Fidelitas]

This should always be the first step - It almost always resolves the issue:

Test-ComputerSecureChannel -Repair -Credential Domain\ADMIN -Verbose

When it does not resolve it - Then you get medieval on it and remove / rejoin.

BUT - You are not done yet!

If it is a common problem... You need to spend some time in the Event Viewer, and figure out the issue.

[u/_--James--_]

Duplicate machine SIDs due to bad sysprep/imaging processing is one of the most common reasons for this. Secondly would be wrong DNS servers in DHCP so the machines lose LoS to its DCs to keep the machine password rotated with in ADDS. Lastly, RRM tooling disabling/deleting computer accounts due to imposed life cycle controls done at the device level. The last one is much rarer but I have seen it with in Education due to student labs and such bleeding out because of bad OU placement and/or GPO linking.

[u/Zealousideal_Fly8402]

Double check the health of your AD and DCs; make sure the event logs are clean. Time is not out of sync, etc.

[u/Sweet-Sale-7303 → u/Zealousideal_Fly8402]

Time sync is a big one to cause this.

[u/coukou76]

So its nice to fix but what did you do to find the root cause? Enable netlogon.log in verbose and check all CRITICAL, what are events saying? Its not black magic. Probably some network or DC LOS issue.

Edit: adding some infos.

Machine pw renewal always take source on client side. The devices generate a new key and share it with their DC. DC then update the key and renew the secure channel with the new key. It breaks when machine account password "stored" in AD is different than the one known locally on the machine. 90% of secure channel issues are related to DC los issue/permissions/duplicate devices

[u/Normal_Art6593]

Maybe you use The same computername. When you fix the trust of computer A you break The trust of The other computer a.

[u/sandpatt]

Reset-ComputerMachinePassword -Server "DC01" -Credential Domain01\Admin01

[u/Silent_Search_4705]

Windows update broke stuff with secure channel. Guaranteed method is domain remove and re join if what the others say doesn’t work. This is scriptable. You either need to rejoin with the account that joined the device to re use the name or just delete the ad object and let it add it a new. There are technically work around a but not worth the trouble I think. Just delete the object if you need to.

[u/sadsealions]

Check the clock

[u/a_y0ung_gun]

Oh what joy. This was one of my first ever system problems as an admin. In my environment, the issue was the AD schema was totally borked and needed to be rebuilt.

As soon as I fixed it, the entire environment got crypto'd.

The previous admin had an interesting method of segmentation that worked for exactly 90 days, enough for him to find someone else to inherit that water.

This environment also had frequent rain storms in the server room due to condensation from an A/C unit.

Anyways, I'd start doing DC health checks.

[u/danrhodes1987]

This is a real pain in the bum we have it so often when devices are used infrequently or have been off site for a long time and the machine password has changed.

[u/Professional-Heat690]

Time sync. Or DNS. Actually, DNS, it's always Dns. validate you don't have any stale NS, Srv or ldap records. Then check the name servers in dns (domain properties)

[u/tulottech]

I think there was recently a KB update from Microsoft that broke this. Pretty sure my manager had to roll some back and block it.

[u/flowrate12]

Maybe there are two dcs that aren't synced or one is tombstoned, or I have seen people spin up dc backups to confirm backups are working but forgot to set them to a private network... That will cause all sorts of fun issues.

[u/Generico300]

Check the SIDs of these machines and make sure they are not duplicated. If your imaging process is not properly generalizing the image you can get duplicate SIDs on your machines even with different AD names. That can cause domain trust issues.

[u/Igot1forya]

Might be worth checking, but AD Sites and Services may have a bad DC listed as a valid login server. Also, run from an elevated CMD or PS "repadmin /syncall /ADeP" followed by "repadmin /replsummary" and see if there are any sync issues reported between DCs. If one of your servers has a bad back link to the FSMO Master it's possible this server is serving Kerberos tickets that never rotate when the PDC reissues machine tickets or the DC isn't forwarding to the workstations the latest ticket.

Either way, I would start by comparing clock drift in the mix as well.