MachineAccountQuota: why any user can join machines to your domain, and how to stop it

A legacy default

The ms-DS-MachineAccountQuota attribute lives on the domain root object. Its default value is 10: every user can create up to ten computer accounts. This behaviour relies on the "Add workstations to domain" user right, granted by default to Authenticated Users in the domain controllers policy.

The historical goal was to let users join their own workstation. In an organisation where devices are prepared by IT or through a deployment tool, that need no longer exists. The creating account is recorded in the ms-DS-CreatorSID attribute of the new object, which lets you find accounts created by ordinary users.

Why a computer account matters to an attacker

A computer account created by an attacker gives them a domain identity whose password they know and which has a service principal name. Several techniques rely on exactly that:

• Resource-based constrained delegation (RBCD). If the attacker can write a server's msDS-AllowedToActOnBehalfOfOtherIdentity attribute, they add their computer account to it and can then obtain Kerberos tickets on behalf of other users for that server.
• NTLM relay to LDAP. An authentication relayed to a domain controller without signing or channel binding can be used to create a computer account or modify delegation attributes.
• Account name spoofing. Vulnerabilities patched in 2021 combined creating a computer account with manipulating its name to obtain an administrator ticket. Fixes exist, but the default quota widened the attack surface considerably.

In each case, removing the ability to freely create computer accounts cuts one step from the attack path.

Setting the quota to zero

The fix is to set ms-DS-MachineAccountQuota to 0 on the domain object. This does not affect domain administrators, nor accounts with an explicit delegation to create computer objects on an OU: the quota only applies to creations relying on the "Add workstations to domain" right.

Before changing the value, identify processes that depend on it without knowing: technicians joining devices with their personal account, deployment tools using a non-delegated service account, appliances or third-party products that register in the domain. Reviewing ms-DS-CreatorSID on existing computer accounts gives a good picture of these uses.

Delegating domain join properly

With the quota at zero, domain join should rely on controlled delegation:

1. create a dedicated group, for example for the workstation deployment team;
2. delegate to that group the creation and deletion of computer objects only on the target workstation OU;
3. for servers, prefer pre-staging computer accounts by administrators of the relevant tier;
4. give the deployment tool its own service account with the same limited delegation.

Domain join hardening changes released by Microsoft since 2022 restrict reuse of an existing computer account by anyone other than its creator. Check the current Microsoft documentation to adapt your reimaging procedures.

What an audit checks

• the value of ms-DS-MachineAccountQuota on every domain in the forest;
• holders of the "Add workstations to domain" right;
• computer accounts created by ordinary users;
• delegations to create computer objects, their scope and beneficiaries;
• LDAP signing and channel binding configuration on domain controllers.