It's Rafal Sosnowski from Microsoft Dubai Security PFE Team. During my numerous Security Audits and Assessments I deliver to customers, I usually discover too wide permissions and user rights configured in Active Directory. One of them is “Add Workstation to the Domain”. There are 3 items that might influence who can add computer to the domain:
It is an attribute on Domain Naming Context object. This attribute specifies how many computers can be added by single user to the domain. Default value is 10. This value can be modified using different tools including ADSIEdit.msc
Add workstation to the Domain
This User Right configured via Default Domain Controller Policy or via local policies on Domain Controllers specifies who can join computer to the domain. Default value is Authenticated Users.
So taking into consideration above 2 items, by default any authenticated user can join up to 10 machines to the domain. This is because “Authenticated Users” are added to the “Add workstation to the Domain” User Right and ms-DS-MachineAccountQuota is 10.
Now if you replace Authenticated Users with your domain, custom HelpDesk group and leave ms-DS-MachineAccountQuota untouched don’t be surprised if helpdesk users join only up 10 computers. After exceeding this number, they will get following error:
Here comes the right method of granting permissions to your domain: AD Delegation. You can granularly control who can do what in your domain including domain join. Designing proper delegation model is quite time consuming because you need to define administrative roles, develop proper OU structure, create security groups and finally configure permissions and auditing.
Delegation can be configured using Delegation Wizard (right click on OU > Delegate Control…) or by applying ACLs directly on the OU or domain level. ACLs on Active Directory containers define what objects can be created and how those objects are managed. Delegation of rights involves basic operations on objects, such as the ability to view an object, create a child object of a specified class, or even deleting an object.
Adding computer to the domain requires only singe, delegated permission:
Create computer object
Active Directory however allows you to delegate permissions to other computer related tasks:
Delete computer object
Reset Password (of computer object)
Read and write Account Restrictions (used to enable / disable computer object)
Validated write to DNS host name
Validated write to service principal name (used to set SPN) and many, many more...
To check if permissions are ok, just right click on the OU or Domain name and investigate “Special” permissions for your Group/User by clicking Advanced.
At least "Create computer object" should be there.
Remember to redirect your default Computer container to the specific OU using redircmp command, otherwise you will need to configure delegation on default “Computers” container.
Delegation will completely ignore threshold in the ms-DS-MachineAccountQuota meaning user can add unlimited number of computers to the domain. On other hand "Add workstation to the Domain" user right will bypass any ACLs on the OU.
Now if you have in place: Delegation for Group1 and “Add workstation to the domain” for Group 2– both will be able to add computers to the domain.
So you might ask: although I configure delegation only on specific OU, and “Add workstation to the domain” is empty why Domain Admins can still add machines to the domain?
This is because “Administrators” group (containing Domain Admins) has direct and explicit ACL permissions to create Computer objects. This permission is assigned on the domain level with propagation enabled.
As a side note there is also Active directory group called “Account Operators” – however I don’t recommend using it as it has too wide permissions over AD: it can create/delete users, computers and other AD objects.
It is important to control who can add new machines to our AD environment. Although we can enforce various security settings via GPO on newly added machines, user could join machine which is not configured according to our security standards and at the same time having ownership of various objects in the system (local admin account, ACLs on file system etc.).
I do recommend using delegation and remove all users from “Add workstation to the Domain” from Default Domain Controller Policy except Administrators (as contingency plan). Also you can reduce ms-DS-MachineAccountQuota value to 0.
Moreover, I am not big fan of allowing standard users to join their workstations to the domain, as they become Owner of the computer object in AD (from ACL perspective) and additionally have ACCESS_CONTROLL flag which means they can read confidential attributes for that object (for example LAPS passwords). This is another argument for using delegation.
You can find more info here: https://support.microsoft.com/en-us/kb/251335