Why You Should Deny the Creation of Computer Objects in the Default Container

In my post that covers my standard directory structure, I recommend using a third-level OU as the effective root of all non-domain controller members.

"But," I can hear you saying, "what about all the computer objects that get created in the default Computers container?"

To that, I say: block 'em.

Do you have build procedures for new servers and workstations? Do you have agents or other utilities that need to be installed on all members? Do you have custom security or group policy settings that need to apply to certain computers? Do all devices need to undergo a security review before being joined to the domain? If so, this is the best first step to ensure all new computers are compliant before being put into production.

Once you've established that there will be no creation in the default container, that logically means a few things:

• New objects must be intentionally created by either support personnel or approved automated systems.
• Elevated directory permissions must be granted to the appropriate directory locations for those personnel/systems to manually create those objects (see this post for details on how to do that).
• Workflows for the joining of a server or workstation to the domain must be formalized, standardized, and communicated before this deny is put into place.

As with most things in IT, this might cost you a fair amount of time and effort to set up, but your domain will be better long-term for it.

Put bluntly, I'm not aware of a technical need for any object to be created in the default Computers container. I'll list a few that used to be problems and why they're no longer so (or shouldn't be).

Non-Prepped Domain Joins

This is the most common objection/question I get from other admins. Each domain has a default container it uses when someone joins a computer the domain without creating the object beforehand. Denying computer creation rights in the root Computers container effectively breaks this process. That's a good thing, and here's why:

• Users shouldn't be allowed to join a computer to the domain without at least some kind of support assist (if you're BYOD, the device likely isn't actually joined to the domain). If a user tries to join and receives an error, they will contact support and get into a proper workflow.
• For a while, I used RedirCmp to make the new OU the default creation location, but I found it was more beneficial overall to "encourage" users to work with support personnel.
• This forces everyone to create a computer object before joining a machine to the domain. If this is the case, you are far more likely to get those objects created in the correct location. This is very important if you have custom permissions or group policy settings in place for different types of workstations or servers.

SQL Clusters

In previous version of Microsoft SQL (2008 and previous?), the required cluster computer objects were always created in the default container with no ability to alter the target location. In modern versions, it's a relatively simple matter of feeding the configuration process the OU where the node and cluster computer objects will reside. Since this capability was introduced, I've been a part of the building of dozens of clusters and AlwaysOn Availability Groups, and none of them has ever touched the root Computers container.

A note: the cluster computer object does need the ability to create, modify, and delete computer objects in the OU where the nodes live. See this post for what ACL entries are required in the Advanced Security section of the parent OU to grant that.

Automated Deployment

Several years ago, many automated build/deployment systems would perform what were effectively non-prepped domain joins for all members. However, there has been a recognition by most vendors that it is not only useful to be able to define an alternate default location, but even different locations for different types of servers.

If you're still using an automated deployment tool that doesn't support custom computer object locations, either ask for your money back or request the internal development team for the tool join the rest of us in the now.

How Do I Do It?

This is actually a very easy task. Direction here are for Server 2012+ versions.

1. Open Active Directory User and Computers with a Domain Admin account.
    
2. Right-click on the domain root Computers container and select Properties.
    
3. Go to the Security tab.
    
4. Click Advanced.
    
5. On the Permissions tab, click Add.
    
6. Click Select a principal.
    
7. Type Everyone and select OK.
    
8. For the Type dropdown, choose Deny.
    
9. For the Applies to dropdown, select This object and all descendant objects.
    
10. Scroll all the way to the bottom and click the Clear all button.
     
11. Scroll all the way back up to the top and mark the checkbox next to Create all child objects.
     
12. Click OK to get back to the Advanced Security Settings dialog box.
     
13. Click OK again to get back to the properties of the Computers container.
     
14. Click OK again.

Step 11 should look something like this:

ACL Entry to Deny Object Creation

In case it's not clear, this denies the creation of any object in this container. But since this is only intended to house computer objects and you don't want any computer objects in it, it should be safe to block everything.