You attempt to logon to a server that is a member of an Active Directory (AD) domain and receive the error message “The security database on the server does not have a computer account for this workstation trust relationship.” Despite removing the computer from the domain and re-adding it back to the domain the error message continues.
Cause:
A computer can lose its trust relationship with the domain for various reasons. The most common reasons are related to DNS and networking. A computer that is a member of a domain, needs to be able to resolve DNS using its local AD servers. Also, it needs to be able to communicate to the AD servers over the various network ports used by AD.
Resolution:
If a server is repeatedly losing its trust relationship with the domain or if you want to check to be sure the server is healthy with respect to Active Directory run the below checks:
- Logon to the server, open an elevated PowerShell command prompt and run the below commands. Check for and resolve any errors.
- gpupdate /force #Updates the computer group policy. Be sure there are no errors.
- $env:logonserver #This should return the local AD server. confirm it is the correct AD server: You may need to logoff and log back onto get the correct AD server.
- Nslookup google.com#Check for and resolve any errors.
- Nslookup $env:computername #Check for and resolve any errors.
- Get-WinEvent -LogName “System” | Where-Object { $_.id -eq 1030 } | Select-Object -First 1 #Indicates the last time the server could not process group policy.
- Check to be sure all AD ports are opened to the AD server:
- Open a powershell command prompt and run telnet queries to the local AD server for every AD port:
- telnet <AD server > <AD port>
-
- Check the system logs to be sure there are no group policy/ AD errors.
- Disable IPv6 if it is not being used.
- If possible, do not use hosts files.
- Configure TCP/ IP settings with default DNS and Netbios settings. Examples are below: