Everywhere I have worked, we had the same cultural problem where people leave AD computer objects in the default Computers container. Everyone from desktop support to server engineers to storage engineers. This is because when you join a computer (or service – i.e. NAS) to the domain, unless the object is staged, the object will be created in the default location – the Computers container (which is NOT an OU!).
In cases where it is a Linux server or NAS file share, there is likely to be no impact by moving it to an appropriate OU. If you’re using some fancy Centrify configuration options then it may make a difference, but out-of-the-box SMB/Winbind domain joins for *nix machines don’t care what OU they’re in.
But a desktop or a server – that can be problematic. Domain Controllers will actually move themselves upon promotion, but that is the only case where AD intelligently and automatically moves computer objects for you. But every other machine? That can be a pain!
When it comes to group policy deployments and installed software that looks at OU location (like SCCM), the OU location matters! Objects left in the Computers container only receive whatever policies are linked to the root of your domain (which hopefully contains the most important security hardening policies), which means that other settings such as printer mappings, installed software, user experience, network optimization, security permissions and other such configurations won’t be applied! And if you do not perform your security hardening at the domain root level, then anything in the Computers container is going to be vastly unsecured.
To make matters worse, since the Computers container is NOT an Organizational Unit, this means that you cannot just start applying policies to it. Computers MUST be moved to an appropriate OU based on their type (desktop vs. server; workstation vs. laptop) or some other criteria (OS, job/role, application, support team, etc).
We will discuss some creative ideas to promote cultural and operational incentive for relocating these machines in the Computers container, but before we do that we should talk about what will happen should a computer object get moved.
The more policies and software installs tied to OU location, the more painful a move might be for a user’s desktop or an application server. If your user settings are linked to user objects and loopback mode is set to merge, then users likely have all their mapped drives, Outlook profile settings and other policies; but because their PC is in the default Computers container, security lockdowns that are applied on a computer level will not take effect. And if your environment links the majority of user settings to machines rather than users with loopback mode replace, then your users will be missing out on key environment settings. Regardless, moving the computer may frustrate end users because they may have gotten used to the level of freedom that they had previously and may be reluctant to give them up; not that it is their choice, ultimately, but they can still make your life hell by complaining to the right people at your organization…
For servers the impact could be even worse, especially when it comes to certain settings/policies like setting local administrators, Schannel/SMB/RPC/WinRM settings, web proxy configs, etc. You could potentially cripple an application and bring it to its knees without approaching the situation delicately. Something else to consider is that the impact of moving a computer object from one OU to another may not manifest until after a reboot, because some services (or the server itself) must be restarted in order for changes to take effect (like Schannel ones for instance). So you may think that moving the location did not cause any issues and you are safe — until someone reboots the server due to maintenance or some other reason… and now the app broke and the sky is falling and no one knows where to start looking because “this was working up until now!” Also, the longer the delay in when the object was moved and when the associated service or server was restarted, the less likely you or a colleague are going to remember that you moved the object, when you did it and why you did it.
I could continue to ramble on about the consequences of moving OUs – like explaining how it could cause the wrong SCCM agent/config to be installed on a machine, leading to much headache to remove or repair it OR what happens if GP Preferences aren’t configured intelligently to account for incorrect OU moves so things like RegKey preferences stick around, causing lingering problems – but I hope that my audience gets the picture by now.
So while you cannot just snap your fingers and make the problem of people leaving computer objects in the Computers container go away, you can certainly get creative by deploying processes to hold people accountable for their laziness or lack of follow-through, as well making life slightly painful enough for end users and/or admins so that they will voluntarily work with the AD/Windows admins to move the objects to the correct location.
Here are some things I have used in the past:
- Create a scheduled task either on your domain controller(s) or mgmt/reporting server(s) that runs a simple powershell query with the ActiveDirectory module:
$list = get-adcomputer -filter * -searchbase “cn=computers,dc=yourdomain,dc=yoursuffix” | select name, created | sort name
Then email out the results in an HTML table (or alternatively, a CSV):
send-mailmessage -to admins@yourcompany.com -from computers_container_alerts@yourcompany.com -subject “Computers left in the default Container require Cleanup!” -body ($list | convertto-html) -smtp your_smtp_server -port your_smtp_port -usessl {$true | false}
The above (with some customization) will send out a list of the computer objects in that container along with creation date, sorted by name.
You could schedule this to run every X days, Y weeks, Z months, whatever. You could also have this email a ticket system which would generate an actionable ticket that can be assigned to a person or group.
- Create a Group Policy Object and link it to the root of the domain and do something slightly obnoxious but not anything that would break a user’s experience or any application running on the machine.
Examples of this could be:
- turn the background color to red, orange, yellow or some other color bound to get the user’s attention that something might be wrong – could even create and deploy a BMP file with text in the image instructing the user or admin to contact the correct support team to ensure that the computer has the correct policies
- use a Logon Text policy to explain the same
- run a Logon Script upon user logon that opens a notification window to explain the same
- set the browser homepage to a HTML page explaining the same
- change the background color or image of the logon screen itself
Those are just some ideas to get started.
- Require that all administrators (whether server admins, desktop admins, storage admins, etc) stage objects before joining them to the domain — and then set up an alert in whatever SIEM log system you’re using to capture domain controller logs (you ARE doing this…. right?! 😉
I hope this post has been informative for you. While you may never solve the problem of lazy or clueless admins leaving objects in the Computers container, you can at least take steps to mitigate the situation. In my experience, it is better to be proactive about this because once a user or server gets used to having a minimal/subset of all the required GPO’s they tend to get spoiled and not only refuse to cooperate when it comes to biting the bullet and moving the object to the correct location, they are also occasionally inspired to treat it as a special exemption and then they proceed to seek such “exemption” from whatever policy or policies they find intrusive by referring to their “grandfathered server” which “was never required to have those policies/settings”.
Stay sharp out there! You can either get on top of these situations or eventually they will catch up to you and make 10x more work in the end.
Never A Null Moment 