I normally put references for my posts at the end of the post, but because I have shamelessly cut an paste a large chunk of this respectable blogger's page, due to its absolute gold value, I felt I needed to acknowledge them at the beginning.
All thanks for this post must go to Dan Peterson who posted the original info (and background if you wish to read it) at:
http://implbits.com/About/Blog/tabid/78/post/don-t-rejoin-to-fix-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/Default.aspx
Dan, thank you for the great and valuable post.
Dan's Post (including original font and background colours). I did say shameless...
Just change your computer password using netdom.exe!
netdom.exe resetpwd /s:<server> /ud:<user> /pd:*
<server> = a domain controller in the joined domain
<user> = DOMAIN\User format with rights to change the computer password
netdom.exe resetpwd /s:<server> /ud:<user> /pd:*
<server> = a domain controller in the joined domain
<user> = DOMAIN\User format with rights to change the computer password
Here are the full steps:
- You need to be able to get onto the machine. I normally just log in with the local Administrator account by typing, ".\Administrator" in the logon window. I hope you remember the password. If you’re creative and resourceful you can hack your way in without the password. Another option is to unplug the machine from the network and log in with domain user. You will be able to do disconnected authentication, but in the case of a reset machine, remember that you may have to use an old password. Your domain user’s cached credential has the same problem as the machine’s private secret.
- You need to make sure you have netdom.exe. Where you get netdom.exe depends on what version of Windows you’re running. Windows Server 2008 and Windows Server 2008 R2 ship with netdom.exe you just have to enable the Active Directory Domain Services role. On Windows Vista and Windows 7 you can get it from the Remote Server Administration Tools (RSAT). Google can help you get them. For other platforms see this link: http://technet.microsoft.com/en-us/library/ee649281(WS.10).aspx"
- Extra steps if the machine is a domain controller. If the broken machine is a domain controller it is a little bit more complicated, but still possible to fix the problem. I haven’t done this for a while, but I think this works:
- Turn off the Kerberos Key Distribution Center service. You can do this in the Services MMC snap-in. Set the startup type to Manual. Reboot.
- Remove the Kerberos ticket cache. A reboot will do this for you, or you can remove them using KerbTray.exe. You can get that tool here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=17657
- Post change steps. Do these in conjunction with 5 below. Turn the Kerberos Key Distribution Center Service back on before rebooting. You should reboot the domain controller and then force replication in the Active Directory Sites and Services MMC snap-in.
- Run netdom.exe to change the password.
- Open an administrative command prompt. On Windows platforms with UAC enabled, you will need to right-click on cmd.exe and select "run as Administrator".
- Type the following command: netdom.exe resetpwd /s:<server> /ud:<user> /pd:*
- Reboot the machine.
References:
http://implbits.com/About/Blog/tabid/78/post/don-t-rejoin-to-fix-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/Default.aspx
I learnt of Dan's post at http://community.spiceworks.com/topic/285129-my-virtual-nightmare-or-it-would-have-been-if-i-slept?utm_campaign=spotlight&utm_medium=email&utm_source=swemail
