Skip to main content

Prevent Authenticated Users from adding Computers to the domain.

I never really understood the logic behind this one. By default, members of the Authenticated Users group can add up to 10 clients to your domain. I’ve tested this and it is true. I created a new user in my domain without given the user any special privileges and added a client to the domain without any issues. This is why it is so important to make sure you have redirected your default computer container to an OU that is heavily locked down.

Another avenue to think about is if you are deploying software by user account. The user will be able to steal company software. Also, any malware on this rogue client will now be on your network.
To change the default computer container that new computer objects will be placed, log into your Domain Controller and type this:

Redircmp container-dn contain-dc

For example
redircmp OU=MyComputers,DC=Contoso,DC=com

The burning question here is how to stop this from happening. On your Windows Server 2008 Domain controller, click Start.

Type ADSI Edit and press enter.

Right click ADSI Edit and the click Connect to.

In the Connection Settings window, click OK

Expand Default naming context.

Expand the Distinguished Name of your domain.

Right click the Distinguished Name of your domain and click Properties.
image

Select the property named ms-DS-MachineAccountQuota and then click Edit.
image

Set the value to 0 and then click OK
image

Your Authenticate Users can no longer attach a client to your domain.

Comments

Anonymous said…
Thanks for this information, I tought that just removing the "authenticated user" from the GPO was enough but apparently not in windows 2008.
Unknown said…
Thanks for posting this. We were quite curious how some of our users were adding machines when not members of the delegated join machine group.

Adam,
Glad you found this useful. I use this issue when delivering the Microsoft Active Directory class (6425) to demonstrate how to find those who did this with PowerShell. This issue is also present on Windows Server 2012.

Popular posts from this blog

Sticky Key problem between Windows Server 2012 and LogMeIn

This week I instructed my first class using Windows Server 2012 accessed via LogMeIn and discovered a Sticky Key problem every time you press the Shift key. Here is my solution to resolve this.  First off, in the Preferences of LogMeIn for the connection to the Windows Server, click General . Change the Keyboard and mouse priority to Host side user and click Apply at the bottom. On the Windows 2012 server, open the Control Panel – Ease of Access – Change how your keyboard works . Uncheck Turn on Sticky Keys . Click Set up Sticky Keys . Uncheck Turn on Sticky Keys when SHIFT is pressed five times . Click OK twice. If you are using Windows Server 2012 as a Hyper-V host, you will need to redo the Easy of Use settings on each guest operating system in order to avoid the Sticky Key Problem. Updated Information: March 20, 2013 If you continue to have problems, Uncheck Turn on Filter Keys .

Where did a User’s Account Get Locked Out?

Updated: May 15, 2015 When this article was originally published, two extra carriage returns were add causing the code to malfunction.  The code below is correct.   My client for this week’s PowerShell class had a really interesting question. They needed to know where an account is being locked out at. OK, interesting. Apparently users hop around clients and forget to log off, leading to eventual lock out of their accounts. The accounts can be unlocked, but are then relocked after Active Directory replication. This problem is solved in two parts. The first one is to modify the event auditing on the network. The second part is resolved with PowerShell. The first part involves creating a group policy that will encompass your Domain Controllers. In this GPO, make these changes. Expand Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Advanced Audit Policy Configuration \ Audit Policies \ Account Management Double click User Account Management C...

How to run GPResult on a remote client with PowerShell

In the past, to run the GPResult command, you would need to either physically visit this client, have the user do it, or use and RDP connection.  In all cases, this will disrupt the user.  First, you need PowerShell remoting enabled on the target machine.  You can do this via Group Policy . Open PowerShell and type this command. Invoke-Command –ScriptBlock {GPResult /r} –ComputerName <ComputerName> Replace <ComputerName> with the name of the target.  Remember, the target needs to be online and accessible to you.