Active Directory Machine Account Quota (ms-DS-MachineAccountQuota): The Default That Lets Any User Add a Computer

Active Directory Machine Account Quota (ms-DS-MachineAccountQuota): The Basics

Active Directory machine account quota — the ms-DS-MachineAccountQuota attribute stored on the domain object itself — defaults to 10 on every domain. That means any authenticated domain user, with zero delegated administrative rights, can join up to ten new computer accounts to the domain right out of the box. This has been true since the attribute was introduced with Windows 2000 Server, and it is still the out-of-the-box value on domains created today unless an administrator has explicitly hardened it.

A Microsoft engineer documented the default plainly on the company's own TechNet blog back in 2005: "Most of you know the limit of 10 times authenticated users can join machines to a domain," describing ms-DS-MachineAccountQuota as the domain-object property that controls it, editable through ADSI Edit. Microsoft's current security-policy reference for the related Add workstations to domain user right (SeMachineAccountPrivilege) confirms the same number from the privilege side: "A user who is assigned this user right can add up to 10 workstations to the domain," and that on domain controllers this right is granted to the Authenticated Users group by default.

Why the Default Alone Doesn't Tell the Whole Story

There is a second, quota-independent path worth knowing before you "fix" this: Microsoft's own documentation notes that "users can also join a computer to a domain if they have the Create Computer Objects permission for an organizational unit (OU) or for the Computers container," and that users with that delegated permission "can add an unlimited number of devices to the domain regardless of whether they have the Add workstations to domain user right." Zeroing the quota does nothing to an account that already holds delegated Create Computer objects rights on an OU — the two mechanisms have to be reviewed together, which is exactly why this setting keeps showing up in common Active Directory security misconfiguration reviews years after it was first documented.

Why a Self-Service Computer Account Is a Foothold

A computer account is not a toy object. It is a full security principal with its own SID and a password the creator chooses (or a tool generates) — by default landing in the CN=Computers container, owned by the creator rather than by Domain Admins. On its own it carries no special privilege. What it does provide is a domain-joined identity the attacker fully controls, which is the missing prerequisite for several delegation-abuse techniques already covered elsewhere in this catalogue, most notably resource-based constrained delegation (RBCD) abuse and the wider computer object attack surface.

Creating that account requires nothing beyond a standard domain user and a quota above zero. Public tooling makes it a one-liner, all documented in community references such as The Hacker Recipes' MachineAccountQuota page:

# Impacket — SAMR-based computer account creation
addcomputer.py -computer-name 'PWN01$' -computer-pass 'P@ssw0rd123!' \
  -dc-host dc01.corp.local corp.local/lowpriv:'Password1'

# Powermad — same result via LDAP from a domain-joined Windows host
New-MachineAccount -MachineAccount PWN01 -Password (ConvertTo-SecureString 'P@ssw0rd123!' -AsPlainText -Force)

bloodyAD and Certipy account create expose the same primitive over LDAP for operators who prefer a single cross-platform tool. None of these require elevated rights — only the default ms-DS-MachineAccountQuota of 10.

The Attack Chain: From a Free Computer Account to Delegation Abuse

Step 1 — Confirm the Quota Is Exploitable

A quick anonymous or authenticated LDAP query against the domain object reveals the live value:

ldapsearch -x -H ldap://dc01.corp.local -D 'corp\lowpriv' -w 'Password1' \
  -b 'DC=corp,DC=local' -s base '(objectClass=domain)' ms-DS-MachineAccountQuota

If the returned value is greater than zero, and the account running the query has no other restriction on it, self-service computer creation is available.

Step 2 — Create a Computer Account the Attacker Controls

Using any of the tools shown above, the attacker spends one unit of their own quota to create a machine account. That single action produces a machine SID with a known password — an identity that did not exist a moment earlier and that Domain Admins did not provision, review, or approve.

Step 3 — Chain Into Delegation Abuse

The newly created computer account is not, by itself, privileged — but it becomes the controlled identity that RBCD and NTLM-relay chains pivot through. In relay scenarios, coercion techniques (e.g., PetitPotam-style forced authentication) are used to relay a victim's NTLM authentication to LDAP/LDAPS on a domain controller; Impacket's ntlmrelayx.py can then use its --delegate-access option to create a computer account over that relayed session and, in the same step, configure msDS-AllowedToActOnBehalfOfOtherIdentity on the relayed target so the new computer account can impersonate arbitrary users to it via S4U2Self/S4U2Proxy — turning one relayed authentication into standing RBCD access. The full mechanics of RBCD itself, and the broader set of ways a computer object's attributes and ACLs get abused, are covered in the two linked articles above; the machine account quota is the setting that supplies the attacker-controlled computer object those chains need in the first place.

Detection

# Current quota value
Get-ADObject (Get-ADDomain).DistinguishedName -Properties ms-DS-MachineAccountQuota

# Computer objects created via the self-service quota path (mS-DS-CreatorSID populated)
Get-ADComputer -Filter * -Properties ms-DS-CreatorSID |
    Where-Object { $_.'ms-DS-CreatorSID' } |
    Select-Object Name, DistinguishedName, ms-DS-CreatorSID

Baselining Legitimate Provisioning

Legitimate provisioning tools generally run under dedicated service accounts joining machines into a known OU on a predictable schedule. Any 4741 event where the SubjectUserName is a standard end-user account, or where the resulting computer object lands outside that OU, deserves a look regardless of volume.

Remediation

1. Set the domain-wide quota to zero. This is the single highest-leverage change:

   Set-ADDomain -Identity corp.local -Replace @{'ms-DS-MachineAccountQuota'='0'}
   

   Verify with the Get-ADObject query above.

2. Reassign the "Add workstations to domain" user right. Per Microsoft's own security-policy guidance, remove it from Authenticated Users in the Default Domain Controllers Policy and grant SeMachineAccountPrivilege only to a dedicated provisioning group. The quota alone does not close this door — the user right is the second gate, and Microsoft's own guidance flags leaving it on Authenticated Users as a "moderate vulnerability."

3. Delegate Create Computer objects narrowly. Grant it only on a dedicated computers OU, only to the account or group that actually provisions machines (imaging service account, SCCM, Intune Hybrid Join) — never to Authenticated Users or Domain Users. Remember this delegated permission bypasses the quota entirely, so scope matters more than the number.

4. Alert on Event ID 4741 combined with a populated mS-DS-CreatorSID, especially for computer objects landing outside your expected provisioning OU.

5. Re-check after domain migrations or new domain stand-ups. ms-DS-MachineAccountQuota is set per domain object; a newly promoted or migrated domain reintroduces the default of 10 unless it is explicitly hardened again.

Verifying the Fix

After setting the quota to zero and reassigning the user right, confirm the change actually holds by attempting a domain join from a standard, non-delegated test account — it should fail with an access-denied error. Re-run the Get-ADObject query from the Detection section to confirm the stored value, since GPO propagation delay can otherwise make a change look applied before it has reached every domain controller.

🚨 Danger: Domain Admins, and any account separately delegated Create Computer objects, are never limited by the quota. Setting it to 0 is necessary but not sufficient — pair it with the user-right and delegation changes above.

This setting is exactly the kind of single-attribute check that belongs in a recurring Active Directory security audit rather than a one-time fix, since it silently reverts to its default on any newly created or migrated domain.

How EtcSec Detects This

EtcSec's Active Directory audit flags a ms-DS-MachineAccountQuota left above zero as Machine Account Quota Elevated Above Default and separately tracks exploitation conditions as Machine Account Quota Abuse, correlating the live quota value with delegation and computer-object findings such as Computer RBCD and RBCD Abuse so the chain from "any user can add a computer" to "any user can impersonate a privileged principal on a target host" is surfaced as one attack path rather than four unrelated findings.