Security database trust relationship revisited

A little over a year ago, I showed you how to fix a broken trust relationship between the client computer and Active Directory. That post has since received a number of comments, and I will address some of them below:

@Uncle Reggie: Yeah right, and lose your entire profile and everything you have ever installed. Oh, sure, there are ways to get it back (most of it), but it isn’t pleasant. If you follow this advice, don’t be surprised when you log in to find a brand-spanking new desktop and all of your programs and documents and favorites gone.

As I said in my response to the original comment, I have literally never seen it happen, and can find no sources on the web discussing it either. I am still calling bullshit on the claim; Uncle Reggie does not know of that which he speaks.

@Doug: This solution will resolve the issue but it will NOT prevent the issue from happening again. We need to determine WHY the issue is happening so we can resolve the root cause and not get use a ban-daid and just remove and add it to the domain.

I agree that a proper fix would be great. The cause should be researched if time allows, however, I have found that the fix usually also means that the problem does not reappear. There are two well-known exceptions to this rule. The first is when the trust relationship breaks because the computer has been out of contact with Active Directory for so long that the account expires – this we can do little or nothing to prevent, and we should simply fix if whenever we see it.

The second is when the computer account in Active Directory becomes corrupted. This one can be resolved by deleting the computer account. If that does not help, the computer should be removed from the domain, given a new computer name, and rejoined to the domain.

@Stanley Sikondwama: This can work just fine if you can log in! If you cannot (because the administratot account has been disabled) then you have had it! What is the solution in a situation like that?

It is true that many SysAdmins set up computers, disabling the built-in administrator account. When doing so, it is best practice to create a new, local, account, with full local administrative privileges, which has another name. If you have not done so, and no local accounts are set up, you are in trouble. A solution has, however, been provided for us by @Rocketman:

@StanTheMan, download Ntpass at http://pogostick.net/~pnh/ntpasswd/and create a bootable CD from the ISO. Boot from the CD which will allow you to change passwords and also enable disabled account.