Windows – Broken trust relationship not corrected even after leaving and joining domain with new computer name

I saw this a couple times recently - my solution, which hasn't failed yet, was to unplug the network cable and log on to the machine as an admin and then plug the network back in once I got to the desktop. Hooray for cached credentials. At that point I believe I went through the motions of rejoining the domain which found the computer's domain account and asked if I wanted to use it, which I accepted.

It was a Windows 7 client on a SBS 2003 domain, I had previously logged in as an admin to setup some software.

It sounds like your "Desktop Support" group has excessive rights, which allow members to overwrite attributes on existing computer accounts.

There's no specific functionality to prevent joining computers with existing names. By not delegating the "Desktop Support" group rights to modify existing computer objects you remove the ability for group members to modify existing computer objects.

If I were you I'd do the following:

• Create an OU in your Active Directory for newly-created computer accounts to "land" in (when created with the default GUI domain join functionality in the client OS). I'm going to call this the "New Computers" OU.

• Redirect the default "Computers" container to the "New Computers" OU using the redircmp utility (Microsoft has specific usage details)

• Delegate the "Desktop Support" group rights to "Create Computer Objects" to the "New Computers" OU.

Members of the "Desktop Support" group will be able to join computers to the domain and the newly-created computer objects will end up in the "New Computers" OU. They will not, assuming you've removed the users' memberships in any higher-privileged groups, be able to modify existing computer objects and, thus, will not be able to join computers to the domain with names that are used by computers joined to the domain already.

Edit:

I am not able to reproduce the behavior you're seeing re: "...an error about not being able to change the Primary Domain DNS Name".

Be aware that the default permissions set on computer objects when you're testing the behavior of the product. The account you use to create the computer object is set as the owner and granted permission (as CREATOR OWNER) to the newly-created object. If you're using the same account to add the "conflicting" computer these permissions are going to allow you to "break" the original computer account. I'm not aware of any way to override this behavior. Your best bet to prevent this behavior from causing problems would be to programmatically reset the owner on newly-created computer objects to "Administrators" and re-apply the default ACL (to remove the ACEs that refer to the original CREATOR OWNER).

I joined a machine named "TEST-SVR01" to my test domain using a member of my "Desktop Support" group. After I did that I reset the ownership on the TEST-SVR01 computer object to "Administrators" and re-applied the default permissions (using the "Default" button on the "Advanced" security dialog).

I attempted to join another machine named TEST-SVR01 to the domain using the same "Desktop Support"-member user and got the error message "Access is denied" during the attempt. The original TEST-SVR01 still had an intact trust relationship with the domain.

There is no simple (or, in my opinion, advisable) way to make "Domain Admins" group members unable to alter existing computer accounts. You could probably do something sickening with "Deny" permissions but you're going to make the product behave in a manner very different from its default. I'd argue that you shouldn't be using "Domain Admins"-member accounts to join computers to the domain. The principle of least privilege dictates that you should only be using "Domain Admins"-member accounts to perform functions for which their excessive rights are necessary, and joining computers to the domain doesn't needthose excessive rights.