Windows Server How-To
How To Fix Domain Trust Issues in Active Directory
Earlier this week I saw a situation in which someone with a small, single-domain controller network performed a restoration of their domain controller. This restoration effectively reverted the Active Directory to a previous version. In doing so, they accomplished basically the same thing that they would have if they had performed an authoritative restoration on a domain controller in a larger organization.
Although the restore operation succeeded, it had some unforeseen consequences. After the restoration, all of the other servers in the domain displayed an error message at log in. This error message stated that the trust relationship between the workstation and the primary domain failed. You can see the actual error message in Figure 1.
Figure 1. An authoritative domain controller restoration can trigger this error on workstations and member servers.
The reason why this problem happens is because of a "password mismatch." Passwords are typically thought of as something that is assigned to a user account. However, in Active Directory environments each computer account also has an internal password. If the copy of the computer account password that is stored within the member server gets out of sync with the password copy that is stored on the domain controller then the trust relationship will be broken as a result.
So how can you fix this error? Unfortunately, the simplest fix isn't always the best option. The easy fix is to blow away the computer account within the Active Directory Users and Computers console and then rejoin the computer to the domain. Doing so reestablishes the broken-trust relationship. This approach works really well for workstations, but it can do more harm than good if you try it on a member server.
The reason for this has to do with the way that some applications use the Active Directory. Take Exchange Server, for example. Exchange Server stores messages in a mailbox database residing on a mailbox server. However, this is the only significant data that is stored locally on Exchange Server. All of the Exchange Server configuration data is stored within the Active Directory. In fact, it is possible to completely rebuild a failed Exchange Server from scratch (aside from the mailbox database) simply by making use of the configuration data that is stored in the Active Directory.
The reason why I mention this particular example is that the Exchange Server configuration data is stored within the computer object for that server. So with that in mind, imagine that a trust relationship was accidentally broken and you decided to fix the problem by deleting the Exchange Server's computer account and rejoining the computer to the domain. By doing so, you would lose all of the configuration information for that server. Worse yet, there would still be orphaned references to the computer account scattered elsewhere in the Active Directory (you can see these references by using the ADSIEdit tool). In other words, getting rid of a computer account can cause some pretty serious problems for your applications.
A better approach is to simply reset the computer account. To do so, open the Active Directory Users and Computers console and select the Computers container. Right click on the computer that you are having trouble with. Select the Reset Account command from the shortcut menu, as shown in Figure 2. When you do, you will see a prompt asking you if you are sure that you want to reset the computer account. Click Yes and the computer account will be reset.
[Click on image for larger view.] Figure 2. You can reset the computer account through the Active Directory Users and Computers console.
In case you are wondering, computer accounts can also be reset through PowerShell (version 2 or higher). The cmdlet used for doing so is Reset-ComputerMachinePassword.
In my experience, broken trust relationships probably aren't something that you will have to worry about on a day-to-day basis, but they can happen as a result of using backup software or imaging software to revert a server to a previous state. When this happens, the best course of action is to reset the computer account.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.