The computer cannot connect to a network because it is offline, or it has lost its membership in the Active Directory (AD) domain, according to the error message “trust relationship between this workstation and the primary domain failed.” This tutorial will walk you through various ways to troubleshoot this problem and will explain what’s happening in the background when this error occurs.
The “trust relationship between this workstation and the primary domain failed” error has a number of potential fixes, as you will see. The typical “disjoin from the domain, reboot, rejoin to domain, reboot” is notable for being speedier. fun. Let’s get going!
Understanding the “trust relationship between this workstation and the primary domain failed” error
One of the most irritating error messages that IT professionals go into while working with Active Directory-joined devices is “trust relationship between this workstation and the primary domain failed.” It seems to appear out of nowhere solely to obstruct your daily efforts to complete activities.
How can you encounter this error?
A computer account is generated in Active Directory (AD) when you add a workstation to a domain. This computer account also has a password, which is valid for 30 days before being renewed, much like a user account.
Note: You can update the “maximum machine account password age” characteristic by making registry changes. Open Regedit.exe and change the following key, if desired:
A machine checks its computer account password with the closest domain controller (DC) each time it “logs in” to Active Directory (after a reboot and before a user signs in):
- If they are synchronous, the PC successfully logs in to AD, and everything continues as normal.
- A grace period of up to 30 days is permitted in the event that the device is not connected to AD’s network.
When a domain user tries to access the workstation, you will get the error “trust relationship between this workstation and the primary domain failed” (and the domain). The user will be able to log in during that grace period if their AD password is cached on the device and they have previously logged in. This specific problem, however, will appear if a user who has never logged on the device before tries to do so and the trust between the device and AD is absent.
Why does this error occur?
When the machine is no longer trusted in the domain, an error message stating “trust relationship between this workstation and the primary domain failed” appears. Between the workstation and Active Directory, there is no secure link. The password for the local computer is different from the password for the computer in your Active Directory.
This error can arise in a few typical situations, as shown by the following examples:
- Windows will reinstall itself.
- Should you reset Windows.
- If a virtual machine’s state is restored.
- If you replace a device’s more visible hardware components, etc.
- If a device is copied without using Syspro first.
There are numerous additional underlying factors that could cause this issue. difficulties with your device’s network cable, your AD or DNS infrastructure, or even the network connection! The key is to move slowly, avoid making ANY assumptions, and use this manual to work your way through this troubleshooting flowchart until you find the solution to your problem.
How to fix the “trust relationship between this workstation and the primary domain failed” error
The “trust relationship between this workstation and the primary domain failed” problem can be fixed using a few different techniques. The trust connection between your device and Active Directory needs to be resolved in this case. Let’s start with some fundamentals that you could occasionally neglect because of time restrictions.
utilizing the command Test-Computer Secure Channel to examine the trust connection
Look at this, though! a helpful PowerShell gem that help you restore the trust relationship between your device and Active Directory. In my Windows Server 2022 Active Directory Hyper-V lab setup, I have a Windows 11 virtual machine. Let’s test our connection to AD using the Test-Computer Secure Channel cmdlet.
Checking DHCP settings
Make sure your workstation’s IP address is either in the same subnet as your domain controller’s (DC) or has a route to those subnets by running the command ipconfig at a command prompt. Pinging one of your DCs by name or fully qualified domain name is another option (FQDN).
If that doesn’t work or doesn’t fix the problem, your network connectivity problem is more fundamental. You should conduct necessary troubleshooting in this area first before moving forward.
You can also release the DHCP IP address that was assigned to you and either renew it or receive a new one by using the ipconfig /release and ipconfig /renew commands. These procedures can sometimes fix strange network connectivity problems. Try it now, please.
Resetting a machine account password
Let’s go right to the strategies that will solve our problem in a shorter amount of time and with greater efficiency. Resetting a computer account password is the objective here. Later on, I’ll demonstrate how to reboot, disjoin, and use other Windows GUI features.
Don’t you think it would be wonderful to stop all those reboots? Yes, I’m certain that it would. especially if your machine is older and slower.
Using the command line tool netdom resetpwd
Netdom is the name of the first command-line utility we’ll employ. By installing the Remote Server Administration Tools (RSAT), specifically the ‘Active Directory Domain Services and Lightweight Directory Services Tools’ option, you can set it up on a workstation.
Use the NetCom resetpwd command by opening an administrative command.
Success! You don’t even need to reboot because the machine account password for the local machine has been correctly changed. You should be fine if you simply log off and then log on again using a domain user account.
Using the Reset-Computer Machine Password cmdlet
You should also have the Reset-ComputerMachinePassword cmdlet in your arsenal of PowerShell tools. This programme will update the computer account password in Active Directory, similar to netdom.
Launch a PowerShell console now. The fundamental command hierarchy is as follows:
Password-Reset-Computer -Server DomainController -Credential DomainAdmin
So I’ll execute the following command in our instance:
Administrator – Server WS16-DC1 – Reset-Computer Machine Password
Here, no news is good news.
By means of the Active Directory User and Computers tool
To carry out the same task as the two earlier command-line techniques, you can take a very simple step using Active Directory Users and Computers (ADUC). Just find the workstation machine in your directory, right-click on it, and select “Reset account.”
And there you go, the computer account has now been reset.
Rejoin your machine to the Active Directory domain
Alright, I’m saving the traditional, somewhat ‘unrobust’ method for last to fix the “trust relationship between this workstation and the primary domain failed” error – my recommendation is to use the command-line tools as they are more efficient, faster, and simply get the job done more reliably. You don’t need to worry about potential issues with local profiles, network connection problems on the workstation side, and other issues in Windows in general.
Anyway, for completeness’ sake, let’s show you this other method to rejoin your machine to the Active Directory domain.
Using the Remove-Computer and Add-Computer Cmdlets
It appears that I am delaying adopting the more traditional GUI approach for a reason. We have the tactical edge by emerging from a warp at the last moment. Once more, PowerShell will help us achieve our objective. The Remove-Computer and Add-Computer cmdlets are available.
Note: Confirm that you are familiar with the login information for the device’s local admin account. Following the workstation’s disconnection and reboot, you’ll need those to log in.
You can restart the machine after removing it from the domain by using the Remove-Computer cmdlet.
Ok. It took only a little while for the reboot to occur. I may now rejoin the domain by using the ‘Add-Computer’ cmdlet after logging in as a local administrator.
A reboot and another another EXTREMELY quick process! And now we can resume our work.
utilizing a Domain Administrator account and the GUI
I suppose I can demonstrate to you the conventional but successful way to fix this mistake. Using the Windows GUI on the workstation, we will follow the steps to disconnect our device from the Active Directory domain and enter workgroup mode, reboot, then reconnect our device to AD, reboot one more, and our task should be completed.
Start -> Settings -> Accounts -> first. access to work or education Disconnect by selecting it by clicking the dropdown arrow next to the AD DNS domain name on the right. Select Yes.
In the pop-up box that follows, click the Disconnect button.
Verify the login information for a local account you’ll be able to use when your workstation is taken out of the domain.
This step is crucial because you will need to reinstall Windows or re-image your device if you don’t have access to a local account and password.
When finished, click Restart now to restart your computer.
I then signed in using my local “Michael” account. I continued on to the same place: Access work or school by going to Start -> Settings -> Accounts.
To add a work or school account, here click the Connect button next to that option.
Choosing the bottom-most link: Join the local Active Directory domain with this device.
Click Next after entering your Active Directory domain’s Fully Qualified Domain Name (FQDN).
You will be asked for a domain account with Domain Admins or comparable rights, assuming it can successfully contact your domain (if it can’t, read this post for help troubleshooting).
Here, I’m taking the uncommon action of adding my AD account with the username “meanders” to the local Administrator group. This is not in accordance with security best practices; it is only for my lab’s needs.
Select “Restart” We’re there after you log in to the domain using your user account!
Conclusion
The core reason of the dreaded “trust relationship between this workstation and the primary domain failed” error message should now be easier to identify thanks to this post, I hope. As I mentioned, this always seems to happen at the worst possible time. That’s it, though. Problems in Windows and Systems Engineering in general can be solved in a variety of methods. Fortunately, you have a good amount here to resume your work!