Preventing Users from Adding Computers to a Domain
Some time ago, we’ve come to the conclusion that the computer accounts in the domain are disorganized. After doing the tedious job of sorting existing accounts, we saw that new computer accounts are still being added to the “Computers” container, and we had no idea which computer was behind them (server/workstation, test/production etc.). After doing some research, we managed to block everyone from joining computers to the domain without pre-creating a computer account (inside organized OUs).
The domain join process
To join a domain, Windows needs a computer account. Windows tries to get its own computer account using these methods, in that order:
- Searches for an existing account with an identical name to its own.
If a matching account is found (and is disabled), Windows attempts to make it its own (write FQDN, reset password etc.) - Tries to create a new account using the user’s permissions in the default computers container
- Tries to use the “Add workstations to domain” privilege to create a new account in the default computers container
A little about “Add workstations to domain”:
Microsoft intends for users to join their own workstations to the
domain, probably to reduce load on helpdesks. For this to work, DCs have
a User Right Assignment called
“Add workstations to domain”.
By default, Authenticated users are members of this group, meaning that
all domain users can use this privilege.
Users with this privilege can create up to 10 (by default) computer
accounts in the default computers container.
The limit of accounts every user can create is defined in the domain
object, under the property ms-DS-MachineAccountQuota
. To view it,
execute
get-addomain | select -exp DistinguishedName | get-adobject -prop 'ms-DS-MachineAccountQuota' | select -exp ms-DS-MachineAccountQuota
The amount of computers a user has already joined is determined by
counting the machines with ms-DS-CreatorSID
identical to the user’s
SID. To find all computers added to the domain using this privilege, you
can try
Get-ADComputer -fi {ms-DS-CreatorSID -like '*'}
To find computers added to the domain using this privilege by a specific user, execute:
$sid = (get-aduser OneBoredAdmin).SID
Get-ADComputer -fi {ms-DS-CreatorSID -eq $sid}
To get a summary of all privilege-added computers and the users that added them, try:
get-adcomputer -fi {ms-DS-CreatorSID -like '*'} -prop ms-DS-CreatorSID | group ms-DS-CreatorSID | %{
$ret = $_ | select Count,@{name='UserName';Expression={$_.Name}},@{name='ComputerNames';Expression={$_.Group | select -exp Name}}
# Try to resolve the SID into an account
try{
$_.Name = $_.Name.Translate([System.Security.Principal.NTAccount])
}catch{}
$ret
}
By the way, when using this privilege to create an account, the account
is created with “Domain Admins” as its owner (and not the creating
user), and the user’s SID in the ms-DS-CreatorSID
property.
Action Plan
Note: While these actions should work as planned and prevent users from adding computers without having a computer account ready, step 1 will break DC demotion. You can either redirect your default computer directory to another OU for the process (see KB324949) or restore the original permissions. Since demoting isn’t a daily action, I still think this procedure is worth doing.
In order to prevent users from joining computers to the domain without pre-creating a computer account, you have to perform these actions:
-
Remove permissions to create computer accounts on the default computers container. To check what is the current default computers container in your domain, you can try:
(Get-ADDomain).ComputersContainer
-
Prevent users from using the “Add workstations to domain” privilege. This can be done either by modifying the
ms-DS-MachineAccountQuota
property on the domain to zero, or removing “Authenticated users” from the URA on the DCs (use Group Policy to make sure it’ll apply to future DCs as well).
As long as you don’t perform those two steps, users will still be able to add computers to the domain.