MachineAccountQuota: why any user can still add ten computers to your domain

A setting from another era

The ms-DS-MachineAccountQuota attribute, held on the domain's root object, sets the number of computer accounts a user with no particular rights can create. Its default value is 10. It works together with the "Add workstations to domain" user right, granted by default to authenticated users in the domain controllers policy.

The mechanism was aimed at small organisations where everyone joined their own machine. Today, joining is done by the service desk, by a deployment tool or through an enrolment process. The quota now serves only one purpose: letting any domain account, including a compromised one, obtain a computer account whose password it knows.

Why a computer account interests an attacker

A computer account is not just an inventory entry. It is a full security principal, with a password, service principal names (SPNs) and the ability to obtain Kerberos tickets. For an attacker who only has a standard user account, creating one opens several possibilities:

• Resource-based constrained delegation: if the attacker manages to write the delegation attribute of a target machine, for example by relaying an authentication to LDAP, they need an account with an SPN and a known secret to exploit it. The quota provides one;
• Relay chains: several techniques that combine authentication coercion and relaying end with the creation of a computer account to maintain access;
• Certificates: the Domain Computers group can often enrol in certificate templates intended for machines, sometimes with overly permissive settings;
• Past vulnerabilities: some account name spoofing flaws, since fixed, relied precisely on the ability to create and rename a computer account.

None of these attacks depends solely on the quota, but the quota removes a step. Setting it to zero makes several scenarios significantly harder for an attacker starting from a plain user account.

Setting the quota to zero without breaking processes

The change itself is simple: set ms-DS-MachineAccountQuota to 0. The preparation is less so, because you need to know who currently joins machines with a non-delegated account. Our approach:

1. Inventory creations: computer accounts carrying a ms-DS-CreatorSID, and computer account creation events on domain controllers.
2. Identify the processes: service desk technicians, deployment task sequences, hybrid enrolment solutions, device management tools. Each must use an identified account or group.
3. Delegate on specific organisational units: grant the join group the right to create computer objects, and the necessary rights on those objects, only in the target OUs.
4. Remove the "Add workstations to domain" right from authenticated users, or restrict it to the join group.
5. Set the quota to 0, then monitor join failures for a few weeks.

Designing the join delegation properly

The join account becomes sensitive in its own right: it can create computer accounts in certain OUs. It should therefore have no other rights, its password must be managed, and if a deployment task sequence uses it, it must not be stored in plain text on a share readable by everyone. Pre-staging computer accounts, created in advance by an authorised person, is an alternative that reduces the required rights even further.

Note that Windows security updates have tightened the rules for reusing an existing computer account during a join: an account created by another user can no longer be reused freely. If your processes relied on that behaviour, explicit delegation is the right answer anyway.

What an audit checks

• The value of ms-DS-MachineAccountQuota on every domain in the forest.
• Who holds the "Add workstations to domain" right.
• Computer accounts created by non-delegated users, through ms-DS-CreatorSID.
• Delegations to create computer objects on OUs and their scope.
• Protection of the accounts used by join and deployment processes.