On some occasions we have encountered the novelty that we cannot log in to the domain from the final computers or clients, this could be due to several reasons:
- The client computer that joins the domain has changed its GUID (globally unique identifier)
- The client has been removed from the domain.
- Domain verification information has been lost/modified.
- The object was deleted from the Active Directory LDAP database.
- The client has been disconnected from the domain controller for a long time.
Mostly the most common reason for this novelty to occur is when the client has no connection to the domain for a long time.
To re-establish the relationship of trust, we have some options available, one of them and the fastest depending on your level of expertise with domain controllers is to remove the computer from the domain, delete the object, and re-entering it again to the domain.
The other options require knowledge of active directory-level execution commands or scripts so they will require an intermediate level of knowledge.
Before applying any solution of the options by which you decide to run, you must carefully review the Event Viewer of the client as well as that of the domain controller, in case it gives us any specific error and thus be able to handle it.
This time we will use PowerShell commands to solve the novelty presented, starting with administrator privileges
On the client computer:
- Test-ComputerSecureChannel -Repair -Credential domain\manager_of_domain
From the domain controller:
- Netdom reset NAMEOFTHEEQUIPMENT /Domain:mydomain.com /Server:NAMEOFTHESERVER /UserO:manager_of_domain
This will fix the problem. We will log in with a domain user and verify that we no longer have the error message.
We can also validate with the following command that the trust relationship has been reset:
- nltest /sc_verify:MI_DOMAIN.COM
It will show us the following output:
