Changing the default location for new workstations, and why you should
TL;DR how to change the default location for new computer accounts & deal with issues that may result.
The issue:
There a couple defaults in a Windows domain that system administrators should keep in mind, and a couple of things about human nature.
· If a user puts a system on the domain without ‘pre-staging’ the account in AD it will go in the Computers Container.
· Any Domain User is allowed to add 10 computers to the domain.
· You cannot put GPOs on a Container in AD.
· However the workstation will login and function while in this default Container.
Therefore the end user will probably not know that their workstation is not in the right OU, and if they do complain it will be because their share drive failed to auto map or they will have a similar issue caused by a GPO not applying. This means that if the helpdesk adds a system to the domain and forgets to pre-stage the account in AD first then it is highly likely that you will have issues later on.
Additionally, you end up with an administrative nightmare if a sizeable chunk of the workstations are in the default Container. The organization might have thousands of users and workstations. You want these accounts in the right OU in the hierarchy of AD for a reason, both for security, administration, and tracking.
Sidenote:
If you want to confirm the ability of Domain Users to add systems to the domain:
If you want to change this, just set the ms-DS-MachineAccountQuota attribute accordingly.
The fix:
So how do we easily fix this via a centrally managed solution? Sure, the helpdesk should always create the account first in AD, but we are all human and we all get forgetful sometimes. The answer is
· Change the default computer location to an OU
· Put a GPO on that OU that prevents local login and shows a message letting the helpdesk know why
This both reminds the helpdesk what they forgot and forces them to fix it.
Step by Step:
First, create the OU and change the default location for computer accounts to it.
Create the GPO and link it to the OU ‘Computer Staging’. We discussed these GPOs in previous articles regarding mitigating Mimikatz and displaying warning banners on workstations, but to recap:
Computer Configuration\Policies\Windows Settings\Local Policies\User Rights Assignment\Deny log on locally — set to Domain Users.
Computer Configuration\Policies\Windows Settings\Local Policies\Security Options\Interactive logon:Message — set a message that will let helpdesk staff know that they forgot a step.
Now if a helpdesk staffer adds a new workstation to the domain without creating the account first in AD in the right OU the following will happen upon restart.
Potential follow on issue:
This method works great, but it causes a subsequent issue if the sysadmin neglects to follow all the way through. The helpdesk staff cannot move a computer account out of the Computer Staging OU and into the correct OU. This is because they are not [and should not] be Domain Admins. They are simply Domain Users who have been delegated rights to the OU that the computer accounts are supposed to be placed in.
The particulars of how the helpdesk staff’s privileges are setup and why is covered here: https://happycamper84.medium.com/laps-for-preventing-credential-theft-in-a-windows-domain-e6c040a1eac3
Important step, do not skip this:
Hence the sysadmin needs to delegate rights to the helpdesk for the Computer Staging OU.
Now if the helpdesk staff forget a step while setting up a new computer then they can fix it themselves. They are forced to fix the skipped step via this method.
Last note:
Suppose the sysadmin forgot to delegate privileges for the helpdesk to the Computer Staging OU? Two things will probably happen.
· The OU will start to fill up with computer accounts
· The helpdesk will start to work around the issue
They will probably do this by pre-staging an altered computer name in AD. They cannot move the original computer name, and the customer wants their system up in a timely manner. So if your standard naming convention is <org name><service tag>, such as ‘TestBW1PLH2’, the helpdesk will likely add an ‘A’ or a ‘1’ to the end of that, create the account in the right OU, change the workstation’s name, add it to the domain, and get it back to the user. The system will function, but now you have a system out there on the network with a nonstandard name.
If you want to confirm this, run a query on AD for computer names that are 1 character longer than the standard naming convention.
If you want to confirm who created a given computer account:
If a sysadmin needs to clean up the Computer Staging OU then a simple PowerShell script combined with Task Scheduler on a DC does the trick nicely. Accounts should not be staying in the Staging OU anyway. The only point of that OU is to force the helpdesk to put the computer in the right OU.
I set Task Scheduler to run the cleanup script every 10 minutes. That should give the helpdesk just long enough to realize they forgot a step. They can then simply pre-stage in the right OU.
I created a *.cmd file simply to run the *.ps1 as I only wanted to bypass the Execution Policy for this one script.
References:
https://www.interfacett.com/videos/using-powershell-discover-added-client-domain/
https://riptutorial.com/powershell/example/20107/bypassing-execution-policy-for-a-single-script
