Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

At work we have a Domain Controller running Server 2008 R2. Our desktop support group has the ability to join computers to the domain using their network credentials. We are now running into a problem where if the name of the computer that is being joined is the same as an existing computer on the domain, the existing computer will get a "The trust relationship has failed..." error and will not authenticate at all unless someone logs in as a local admin, changes the computer name and rejoins it to the domain.

I want to make it so that Desktop Support can only join computers with unique names to the domain. If the name already exists on the domain the operation should fail. Looking through TechNet it looks like this functionality exists but I can't seem to find out how to enable it. Any ideas?

share|improve this question

2 Answers 2

You're not creating a new account when the second computer joins the domain, it's merely connecting to the existing account.

it's no different than if you're re-imaging an existing machine and want to use the same name again.

the reason you're getting the trust relationship error is because the existing relationship has been broken due to the new one being created with the machine you just joined.

As far as I know there is no way to stop a computer from joining the domain if the name already exists.

share|improve this answer

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.

share|improve this answer
    
I just made the changes you suggested on a test environment and it didn't seem to make a difference. The Computer Objects are showing up in the new OU i created and I confirmed that my test account only has the "Create Computer Objects" right but if I join a fresh Windows 7 VM to the domain under an existing name the operation succeeds and the other computer cannot authenticate. To be clear I don't want anyone (even Domain Admins) to be able to overwrite existing accounts. Is there something I can do in ADSI Edit to disable this globally? –  Justin Jan 29 '12 at 1:37
    
Since making the changes I notice that after getting the "Welcome to <DOMAIN>" message I get an error about not being able to change the Primary Domain DNS Name. The existing machine still gets booted off the domain though. –  Justin Jan 29 '12 at 1:59
    
I just manually set the security descriptor on the computer object to default like you said and it looks like you are right. Is there any way I can script this so all computer objects that are like this will be set back to default? Thanks for your help. –  Justin Jan 30 '12 at 5:19
    
Also: I was referring to disabling the ability to overwrite an existing computer object during the join process only. My ideal setup would be if someone tries to join a machine to the domain under an existing name they would get an error message like "The join operation failed because <COMPUTER_NAME> already exists on <DOMAIN>. Either set a different name or delete the existing object manually in ADUC" –  Justin Jan 30 '12 at 5:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.