How to Set ms-DS-MachineAccountQuota to 0 (Users Allowed to Join Computers to the Domain)

ms-DS-MachineAccountQuota is the domain attribute that caps how many computer accounts a non-administrator can create. Its default of 10, plus the “Add workstations to domain” right that Authenticated Users hold on domain controllers, triggers the “Users Allowed to Join Computers to the Domain” finding. Fix it by setting the quota to 0 and delegating joins to a dedicated group.

What the scanner is actually detecting

This is a domain configuration finding, not a host vulnerability. The ms-DS-MachineAccountQuota attribute on the domain root sets how many computer accounts a user may create, and the Add workstations to domain user right (SeMachineAccountPrivilege) decides who may use that quota. Microsoft documents the effective default of that right on domain controllers as Authenticated Users.

PingCastle’s rule source clears the finding when the quota is 0. Otherwise it fires when no GPO defines SeMachineAccountPrivilege or when a GPO grants it to Everyone, Authenticated Users, Users or Anonymous, and it treats an unset attribute as unlimited. Restricting the user right alone can therefore satisfy PingCastle while Tenable still flags the quota.

Real-world risk

Exploitation needs a valid domain account, so this is not an entry point on its own. What it gives an attacker with one ordinary account is a computer account whose password they chose. Microsoft’s KrbRelayUp guidance describes attackers creating exactly this kind of fake computer account as part of a local privilege escalation chain, and recommends considering a quota of 0 alongside LDAP signing and channel binding. Tenable adds that the default can facilitate exploitation of CVE-2021-42278 and CVE-2021-42287, the sAMAccountName spoofing pair patched in November 2021.

There is also a governance problem: Microsoft’s example is a user who installs Windows, joins it to the domain and keeps the local administrator password. Setting the quota to 0 does not fix those attack chains by itself (patching and LDAP hardening do), but it removes a cheap building block. Treat it as a medium-priority tier 0 item alongside the rest of your Windows Server hardening checklist.

How to confirm it

From a machine with the ActiveDirectory PowerShell module (RSAT), read the current quota:

Import-Module ActiveDirectory
$domainDN = (Get-ADDomain).DistinguishedName
(Get-ADObject -Identity $domainDN -Properties 'ms-DS-MachineAccountQuota').'ms-DS-MachineAccountQuota'

A value of 10 (or anything above 0) confirms the Tenable finding. An empty result means the attribute is not set, which PingCastle reports as unlimited.

Next, check who holds the user right on a domain controller. Run this in an elevated prompt on a DC:

secedit /export /cfg C:Tempdc-rights.inf /areas USER_RIGHTS
Select-String -Path C:Tempdc-rights.inf -Pattern 'SeMachineAccountPrivilege'

A line such as SeMachineAccountPrivilege = *S-1-5-11 means Authenticated Users (well-known SID S-1-5-11) holds the right.

Finally, list computer accounts that ordinary users created. Microsoft points to the ms-DS-CreatorSID attribute of machine accounts as the way to count how many workstations each user has created:

Get-ADComputer -LDAPFilter '(ms-DS-CreatorSID=*)' -Properties 'ms-DS-CreatorSID', whenCreated, operatingSystem |
  ForEach-Object {
    $sid = [System.Security.Principal.SecurityIdentifier]"$($_.'ms-DS-CreatorSID')"
    $creator = try { $sid.Translate([System.Security.Principal.NTAccount]).Value } catch { $sid.Value }
    [pscustomobject]@{ Computer = $_.Name; Created = $_.whenCreated; OS = $_.operatingSystem; Creator = $creator }
  } | Sort-Object Created

How to fix it

Step 1: Give legitimate joiners delegated rights first

Microsoft notes that users with the Create Computer objects permission on an OU or container are not limited by the quota. Create a group (for example CONTOSOWorkstation-Join), add your deployment technicians and service accounts, and delegate on each target OU. In Active Directory Users and Computers, with View > Advanced Features enabled, open the OU’s Properties, go to Security > Advanced > Add, select the group as the principal, set Applies to to This object and all descendant objects, and tick Create Computer objects and Delete Computer objects. The command-line equivalent with dsacls is:

dsacls "OU=Workstations,DC=contoso,DC=com" /G "CONTOSOWorkstation-Join:CCDC;computer"

Joins that do not name an OU create the account in the default Computers container, where your group has no rights. Either have technicians target the OU explicitly, or redirect the default container:

# Join into a specific OU
Add-Computer -DomainName contoso.com -OUPath "OU=Workstations,DC=contoso,DC=com" -Credential (Get-Credential) -Restart

# Or make that OU the default location for new computer accounts
redircmp "OU=Workstations,DC=contoso,DC=com"

Step 2: Set ms-DS-MachineAccountQuota to 0

As a Domain Admin, in PowerShell:

$domainDN = (Get-ADDomain).DistinguishedName
Set-ADDomain -Identity $domainDN -Replace @{'ms-DS-MachineAccountQuota' = 0}

Or follow Microsoft’s ADSI Edit procedure: open adsiedit.msc, connect to the default naming context, right-click the DC= object for your domain, choose Properties, select ms-DS-MachineAccountQuota, click Edit, enter 0, then OK. The attribute is per domain, so repeat this in every domain of the forest.

Step 3: Restrict the “Add workstations to domain” right (recommended)

For defense in depth, and to satisfy PingCastle even if someone later raises the quota, define the right in the GPO that applies to your domain controllers, normally the Default Domain Controllers Policy:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Add workstations to domain

Define the setting with only your join group, removing Authenticated Users if it is listed, then run gpupdate /force on the domain controllers or wait for the next refresh. Microsoft states the setting must apply to at least one domain controller to take effect. If another GPO linked to the Domain Controllers OU also defines this right, only the winning GPO counts; see our notes on Group Policy precedence rules before assuming the change landed.

Step 4: Review computers users already created

Go through the ms-DS-CreatorSID list from the confirmation step. Tenable recommends identifying computers added through unauthorized means and, where needed, rebuilding them from your standard image with your normal hardening. Disable and investigate any account that has no matching physical or virtual machine.

How to verify the fix and rescan

1. Confirm every domain controller returns the new value:

   Get-ADDomainController -Filter * | ForEach-Object {
     [pscustomobject]@{
       DC    = $_.HostName
       Quota = (Get-ADObject -Identity (Get-ADDomain).DistinguishedName -Properties 'ms-DS-MachineAccountQuota' -Server $_.HostName).'ms-DS-MachineAccountQuota'
     }
   }

2. Test a join with an ordinary account that is not in the join group. It should fail with error 8557 (0x216D), whose message says the user has exceeded the maximum number of computer accounts they are allowed to create.
3. Test a join with a member of the join group into a delegated OU. It should succeed.
4. Rerun the healthcheck, for example PingCastle.exe –healthcheck –server contoso.com, and confirm S-ADRegistration is gone. Let Tenable Identity Exposure and Defender for Identity complete their next evaluation; Microsoft notes that Defender for Identity scores and statuses update every 24 hours.

What can break and how to roll back

• Self-service joins. Help desk staff, developers or field technicians who joined machines with their own accounts get error 8557 until they are in the join group.
• Automation using ordinary service accounts. Imaging, provisioning and build scripts that relied on the quota fail the same way. Give those accounts delegated rights on the correct OU.
• Failover clusters. Microsoft’s cluster prestaging guide notes that a cluster name object in the default Computers container can create up to 10 virtual computer objects without extra configuration. With a quota of 0, grant the cluster name object Create Computer objects on its container or OU, or prestage the objects.
• Rejoining with existing accounts. Separate from the quota, the October 2022 domain join hardening (KB5020276) blocks reuse of a computer account created by someone else, with error 0xaac. If your join group rejoins machines another technician created, use the Domain controller: Allow computer account re-use during domain join policy described in that article.

Existing domain members are not affected unless they are removed and added again. To roll back, restore the default:

Set-ADDomain -Identity (Get-ADDomain).DistinguishedName -Replace @{'ms-DS-MachineAccountQuota' = 10}

Revert the user right by restoring the GPO setting you had before (record it first), and remove the delegation with dsacls “OU=Workstations,DC=contoso,DC=com” /R “CONTOSOWorkstation-Join” if you no longer need it.

Common false positive reasons

• Replication lag. The scan queried a domain controller that had not yet received the change.
• Scanners disagree. A domain with the quota at 10 but the user right restricted to one group passes PingCastle and still fails Tenable and Defender for Identity. That is a different check, not an error.
• Wrong domain. Each domain in a forest has its own attribute. Fixing the forest root does not fix child domains.
• A false negative to watch for. A quota of 0 can make scanners report clean while Authenticated Users or Domain Users still hold Create Computer objects on the Computers container. Check that ACL with dsacls “CN=Computers,DC=contoso,DC=com”, because those users can create unlimited accounts.

FAQ

Does a quota of 0 stop administrators from joining computers?

No. Microsoft states that members of Administrators and Domain Admins, and anyone with delegated rights to create computer accounts, are not restricted by the quota.

Should I lower the quota instead of setting it to 0?

PingCastle and Defender for Identity both recommend 0, and Tenable recommends limiting joins to designated administrators. Any value above 0 still lets every holder of the user right create computer accounts.

Do already joined computers need to rejoin?

No. Microsoft notes existing computers are unaffected unless they are removed from the domain and added again.

Is removing Authenticated Users from the user right enough on its own?

It clears PingCastle, but Tenable and Defender for Identity check the attribute. Set the quota to 0 and restrict the right for defense in depth.

Tracking this finding across many hosts

Identity findings like this one often sit apart from host findings. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners into one queue and merges duplicates per scanner, not across scanners, so the same domain condition reported by two tools remains two records. Its AI triage suggests likely false positives with supporting evidence, and a human makes the final call.

Sources

• Tenable: Users Allowed to Join Computers to the Domain (C-USERS-CAN-JOIN-COMPUTERS)
• Microsoft Learn: Default workstation number a user can join to the domain
• Microsoft Learn: Add workstations to domain
• Microsoft Learn: Defender for Identity identity infrastructure assessments
• PingCastle: rule descriptions (S-ADRegistration)