Relationships are built upon trust! As an AD administrator, there is no relationship more important than the one between Domain Controllers and workstations. We have all dealt with errors like “The trust relationship between this workstation and the primary domain failed.” But why does this occur? In short, the secure channel has been broken and we need to fix it. Here is how:
Prepare yourself for random relationship advice…
“Why can’t you look me in the eyes without crying?”*
As you probably know, computer accounts have passwords. When the computer account is first configured, it’s default password is COMPUTERNAME$. It will change the password and continue changing the password every 30 days. But what happens if a computer is offline for more than 30 days?
Machine account passwords as such do not expire in Active Directory. They are exempted from the domain’s password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.
If password expiration isn’t the issue, why would a trust relationship be broken? Here is a nice starter list for you:
- Duplicate Computer Names: If you have two physical computers with the same name, you are going to have problems. You can use this script to help find potential duplicates.
- Resetting the AD Account: For clarification purposes, this is not a fancy “Restart Computer button”. That fancy button can be found here.
- Duplicate SIDS: This last reason is still in question. If you are properly imaging your machines, you won’t have any issues here though.
- Infidelity: Some have reported that repeatedly joining/unjoining different domains can cause this issues – why they were even trying this, I do not know.
“How can I move on with my life?”*
Remote Desktop is your best friend on this problem! Connect to the computer as the local administrator. Because local users do not authenticate against the domain, you should not have any issues logging in. If you are unable to resolve the name of the computer, you can use DHCP to locate the IP address.
Using the local administrator account in RDP
Once connected, just open System Properties and proceed through the Network ID Wizard. If you are using PowerShell 3.0+, you can use the Test-ComputerSecureChannel cmdlet. Here is an example:
|
1 |
Test-ComputerSecureChannel -Repair -Credential (Get-Credential) -Verbose |
Hopefully, this post will give you some closure on why your trust relationships sometimes fail. If you have any questions (or tips on troubleshooting this problem), please let me know in the comments below! If you want to learn more and learn how to make your IT life easier, then subscribe to DeployHappiness. As a bonus, you will get a free guide on making your own Windows 8 administrative menu!
*All sub-headings are strictly fictional and are in no way taken from 2:00 AM fights that my neighbors regularly have.
Hi
I have tried to RDP into the machine using the local account but it wouldn’t let me.
Now am i right in thinking because the machine is not trusted by the domain you wouldn’t be able to remote in from the DC?
You can log in with local admin remotely but you need to log in to the host name or ip adress not the domain name. Eg with dameware i use ip address and local admin and password with machine name or ip address
We are running Windows 10 at many locations. Unfortunately when a computer loses the trust relationship it cannot be accessed remotely. Apparently when not on the domain the firewall by default increases it’s security settings so it will no longer respond to pings or remote desktop. In the past when Win7 lost trust to the domain it would still respond to pings and remote desktop and easily rejoined to the domain. Without remote access only physically visiting the computer will rejoining the domain be possible. If anyone has a solution or thoughts on this it would be greatly appreciated.
You can try including a local group policy setting to enable remote access. When you have this setup, you can reset the computer in AD to test out your connection.
Hey there! Thanks for the great info. Given your experince, my question for you is: Can this anomaly be somehow triggered due to network problems?
Thanks.
Regards: Ivan
I haven’t see that before Ivan – but I would assume it would be possible.
More information about:
You can prevent the error: “The trust relationship between this…” with a domain GPO.
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
Domain member: Disable machine account password changes
Domain member: Maximum machine account password age
Source:
http://www.sysadmit.com/2015/08/mware-y-ad-la-relacion-de-confianza-entre-esta-estacion-de-trabajo-y-el-dominio-principal-fallo.html
Thank you Adrian! Did you have this problem a lot before setting this? I haven’t been able to get a large enough environment that had this issue consistently to test this resolution.
Weve had to deal with this issue on a daily basis but I’ve narrowed it to a WIN2K3 DC that hadnt replicated to its GC a WIN2K8R2.
Ive used: netdom resetpwd /server:dc.test.com /userd:domain\user /passwordd:*
with quite a lot of success, just login with the local admin, run the command and reboot.
I’ve completely removed the 2K3 system and after reestablishing the trusts on the affected systems all seems well. I will followup if indeed it was the mixed environment causing the constant errors.
Thanks for the tips Case! Update us when you can!
A really quick way, logon as local admin user, goto control panel, then system, then advanced settings, then computer name then remove the .local part then input,the domain administrator and password and reboot that’s it fixed.
Hey Brett !
This was the first suggested solution I tried and it worked 100%.
I started having the problem after renaming my computer (Win10) that is joined to a Server 2012 R2 domain.
We have server 2008 DC’s, Windows 7 clients with DeepFreeze. We found this problem to happen due to the computer clocks being skewed to far out of domain policy spec. Correcting the clock and rejoining the domain seemed to correct this and and altering domain policy has seemed to work.
Hope this helps.
Thanks for the tip Everett! I haven’t heard of that as an issue before so it is good to know!
Server 2012, workstations are Windows 7. This has happened on about 5 workstations of 23. No Dupe Names. All pretty straight forward. The worst part, is if I take the workstation out of the domain, and into a workgroup, then the next log in creates the exact same user problem witth with .000 at the end of it. A whole new desktop. Have to copy all the files and favorites etc. from the original user to the new user. Comprendo? it example: User\mhahn.domain.000 what a mess! Any ideas? Thanks, Michael
Hey Michael – use the powershell cmdlet Reset-ComputerMachinePassword to see if that allows the profiles to stay connected to the user
The reason we are getting so many broken trust relationships is because we are running Server 2003 and Windows 7 clients registry does not play well with such an old operating server system.
We expect this issue to be resolved once we move to server 2012.
Let me know if that fixes your issue. I haven’t experienced that yet.
I use this once I have logged into the machine as a local admin (via Dameware)
test-ComputerSecureChannel -Credential mydomaincreds -Repair
It then asks for my domain creds. Some times I have to rerun the command 3 times before it kicks in.
Will changing the machingpasswordage default from 30 to say 90 help out this issue from happening? We are seeing this issue more and more on Windows 7. NO duplicates, No System Restores occurring.
One hunch we have is that we find in our environment that computers that have been in laptop bags for several months or not brought in to connect to the network get this error.
Or if staff lock laptop at home and come into the office without logging on so they don’t authenticate against the DC and use cache credentials possibly do not get policy correctly.
I have also been reading about scavenger threads.
According to Microsoft, no – it won’t make a difference. After making all of the changes described in this thread, the main computers having this issue were laptops (about 1 a month or so).
As a test, I have the max password age set to 120. So far, I haven’t had any machines with this issue. I will find out for sure in a couple of months though.
Hi,I am also facing this issue in our organization,i have few queries which i want to ask you.
1.What is the reason behind this problem.
2.How can we fix this issue without rejoining the domain,because i dont have rights to perform domain Rejoining task.
There can be many reasons for this issues – the common ones are listed in this article. If you don’t have permissions to reset the computer’s passwords, you can’t fix this.
In an environment where duplicate instances of machines are created, as by imaging or by copying vm, this is what will break the trust:
After duplicating a machine, only one of the two instances will be able to have a trust relationship with domain. If the copy is started first, then it will have the trust and the original will lose it. If the original is started up before the copy, then it will retain the trust relationship.
The simple fix is to disconnect a machine from network, change it’s name and change it to workgroup rather than domain, then re-connect it to network and join the domain.
You are absolutely right about that! Often, we will see the issue in labs and on laptop carts. When the machines are setup, someone will name two the same. We use this script to spot those issues: http://deployhappiness.com/list-computers-missing-in-active-directory/
I see this a lot at my job. Most of the time it is duplicate names. Is there a way you can stop that? If so please let me know. We even have it set up where computers autoname in imaging but some how they still seem to have duplicate names.
The best way to prevent this is to use pre-staged computer accounts only and to only allow approved devices to image. This adds more steps for an administrator but helps to ensure duplicate names won’t be created.
If you already have duplicate names, you can use this script to help find them:
http://deployhappiness.com/list-computers-missing-in-active-directory/