Windowmaker's blog

Preventing local administrators from renaming computers in AD

Imagine that you are an administrator in a large distributed AD based environment. You have invested a lot of thought and time in the design, written policies, created procedures and among other things you rely on some sort of naming convention for your servers for the purpose of provisioning and tracking. You rigorously follow the guidelines in order to keep your environment as stable and controlled as possible, but... 

But the problem is that in a large environment you do not control everything. It only makes sense that there are user accounts in your AD that are local administrators on a bunch of production servers so that those users will be able to run and maintain applications used in the company. The problem, though, is that those users have a nasty habit of renaming NetBIOS names of those production servers they are responsible for and tend to ignore the naming conventions and not updating the records when doing so.

So what can you do about it ? Actually the problem is two-fold:

1. By default any authenticated user has the right to join up to 10 computers to a domain
2. The account that created the computer object gets quite a lot of permissions over it in AD.

Preventing any authenticated user from creating computers in AD:

The default quota is managed by ms-DS-MachineAccountQuota attribute on the domain head object. In order to revoke this right, all you need is to set ms-DS-MachineAccountQuota attribute of your domain head (i.e.: dc=domain,dc=com) to 0. After that only accounts with explicit permissions to create child objects over OUs/containers will be able to join computers to the domain. The actual steps on how to do that can be found at the following KB: Default Limit to Number of Workstations a User Can Join to the Domain

Preventing computer object creators from renaming the computer's NetBIOS name:

Here we are facing the situation where we have a domain user account that has joined a computer to the domain and as a result of that action, has been granted a set of explicit permissions that give the user quite a lot of control over what he can do with the computer object. Among other things the user gets the right to update sAMAccountName attribute of the computer object - the very thing we want to prevent.

From here on I will be using user account GUTE\test which is a only a member of Domain Users group and has explicit permissions to create computer objects in "Computers" container in the domain. If I use this account to join computer named WKSTEST01 to the AD and look at the permissions assigned to GUTE\test account over the computer object using dsacls.exe, I will see the following:

See the line in bold ? This means that if GUTE\test has in addition administrative rights at WKSTEST01, he will also be able to rename the computer without disjoining/re-joining the computer to the domain.

So where those permissions come from ? Well, those are controlled by defaultSecurityDescriptor attribute of the Computer object of type classSchema in the Schema partition. The attribute controls what permissions are assigned to newly created objects of Computer object class. So how can we change it ?

1. Register the Active Directory Schema snap-in. At the command prompt type:
   C:\>regsvr32 schmmgmt.dll
2. Start -->Run--> mmc, File --> Add/Remove snap-in, click the Add button and select "Active Directory Schema" from the list
3. In the left pane select the Classes and locate the Computer entry:
   
4.  Double-click the "computer" entry and go to Default Security tab. As you can see, the CREATOR OWNER security principal has quite a lot of permissions:
   
5. Click the Advanced tab and scroll down till you see the ACEs for CREATOR OWNER with "Write Property" permissions (there are several):
6. If you have not changed anything before, you will see 4 subsequent entries for CREATOR OWNER with "Write Property" permission. Select the forth, click Edit and scroll down till you see the "Write Computer name (pre-windows 2000)".
   
     
7. Your environment might be different from mine and you will have to search for the ACE in question as it might not be at exactly the same position as in my case.
8. Un-tick the Allow checkbox and click your way through OK's...
9. Let the change replicate to all the DCs in your forest.

All set !

Let's test it...

1. Use an account that is only a member of Domain Users group and join a new computer to domain.
2. Make the account from above a member of computer's local Administrators group
3. Logon with your test account
4. Right-click "My Computer" and go to "Computer Name" tab
5. Click the "Change" button
6. In the "Computer Name" field fill in a new name (i.e.: WKSTEST02)
   
7. Click OK. You will be asked for user credentials. Type in the test account details (in my case "GUTE\test" and the account's password)
8. Click OK
9. Observe the Access Denied message  
   

Note: the steps above will not prevent a user, that has a right to remove a computer from domain, to join the computer to a workgroup, change the computer name and later join the domain with the new name, but will certainly make their life harder as removing a computer from a domain might have quite a few implications and the user will think twice before doing that. If you want to go another step further, you can use GPO to control "Add workstations to domain" user right and make sure that only a pre-defined security groups have those rights.