When we use a domain user account to log in a workstation, we might get the following error.
"The trust relationship between this workstation and the primary domain failed".
This issue can be found on Windows 2000 to Windows Server 2012 R2 environment. How to make this error? Basically, Active Directory and workstations store 2 password versions of domain computer accounts which are "current password" and "previous password". If 2 password versions of this domain computer account don't matched the password copy of this domain computer account in Domain Controller, Windows displayed "The trust relationship between the workstation and the primary domain failed".
By default, the machine account password changes every 30 days.
We can change this policy by Local Security Policy or Group Policy.
Some case will make this error.
1. The computer account was reset.
2. Administrators restore the backup or snapshot which is older than 60 days.
Quote from "Machine Account Password Process":
Now consider the scenario, when a machine is not connected to the network for a long period. Supposing on the client:
- Old password = null
- Current password = A
- New random password = B
And on the machine account in AD:
- unicodePWD = A
Remark: unicodePWD is a password copy of domain computer account
After 30 days when the Scavenger thread runs, the value would be:
- Old Password = A
- Current Password = B
At 60th day the same process happens again. So now the newly generated password is C and the values are"
- Old password = B
- Current Password = C
Now when the client connects to AD, it will try the current password to authenticate. When that fails with error. Otherwise machine should be able to reset its password once it boots even after say 90 days.
End quote from "Machine Account Password Process":
There are 3 methods to fix this issue.
1. Disjoin and rejoin the computer to the domain.
Using this method, some services or applications cannot be started.
2. Perform "netdom resetpwd" to reset the machine account password in a domain computer.
According to KB325860, this procedure is most frequently user on domain controllers, but also applies to any Windows machine account.
I will try to perform it in my lab.
Lab environment
- 1 domain controller named DC01 in contoso.com which is installed Windows Server 2012
- 1 member server named App01 is a member server of contoso.com which is installed Windows Server 2012
Goal
Perform "netdom resetpwd" to fix "The trust relationship between the workstation and the primary domain failed" issue.
1. On DC01, log in as Domain Administrator.
2. Launch "Active Directory Users and Computers".
3. Locate "App01" and then right-click it.
4. Select "Reset Account".
5. On a pop-up window, click "Yes".
6. Click "OK".
7. Go to App01, log in as Domain Administrator.
Because the computer account has been reset, I cannot log in as any user of this domain. To fix this, we have to log in as Local Administrator and then perform "netdom resetpwd".
8. Log in as Local Administrator.
9. Launch "Command Prompt" as an administrator.
10. Perform "netdom resetpwd /s:DC01 /ud:Contoso\Administrator /pd:*" to reset and upload the local machine password to DC01 which is the domain controller.
11. Type the password of the domain administrator and then press "Enter".
12. Perform "nltest /sc_verify:contoso.com" to verify the trust.
13. Log out Local Administrator and log in as Domain Administrator.
As a result, the user can log in the workstation by using a domain user account.
Remark: There is no "nltest" and "netdom" command in some Windows versions like Windows Server 2003. You need to download and install the support tools before using it.
Remark: If you would like to reset a local machine password of a domain controller, please follow KB325860 to perform the additional steps.
3. Joe Richards, the MVP of Directory Services, wrote a detail article and a tool, MachinePwd, to fix this issue. If you are interested, please read his blog and follow his steps to fix it.
References and more information:
This posting is provided “AS IS” with no warranties, and confers no rights!
No comments:
Post a Comment