Skip to main content

Technical The Overlooked Danger: How MS-DS-Machine-Account-Quota Fuels AD Attacks

Would you like to learn more?

Download our Guide to Penetration Testing to learn everything you need to know to successfully plan, scope and execute your penetration testing projects

By Kyle Burns, Lead of Offensive Security at Packetlabs.

The MS-DS-Machine-Account-Quota attribute is an Active Directory (AD) setting that defines how many computer accounts a non-administrative user can create in a domain. By default, this value is set to 10, meaning any authenticated domain user can create up to 10 machine accounts without requiring elevated privileges.

Despite appearing harmless, the MS-DS-Machine-Account-Quota setting enables several well-known Active Directory (AD) attacks by allowing any authenticated user to create machine accounts—an action that, in some cases, is a prerequisite for exploiting a number of AD related abuses.

Four Examples of Attacks that Require the Ability to Create Machine Accounts

Active Directory Certificate Services (ADCS) - Misconfigured Templates

At a high level, Active Directory Certificate Services (ADCS) is a Windows Server role that provides customizable services for issuing and managing public key infrastructure (PKI) certificates used in secure communication, authentication, and encryption within an Active Directory environment.

In 2021, SpecterOps security researchers published their research detailing various techniques to abuse this, highlighting how attackers could exploit misconfigurations and inherent design flaws to escalate privileges which they collectively referred to as "ADCS Attack Paths" or "Certified Pre-Owned".

In our daily engagements, even in 2025, it is common to come across ADCS servers in our clients' networks. In some cases, there are abusable templates (typically ESC1 and ESC4) where only members of the Domain Computers group can perform certain actions, such as enrolling in or modifying certificate templates. However, having a domain computer account is typically not a requirement we ask the client when performing a penetration test. So what is the way to get one? You guessed it.

Since the danger of the MS-DS-Machine-Account-Quota attribute is overlooked for too long, clients with Active Directory typically set it as the default, allowing all users to create up to 10 computer accounts.

Kerberos Resource-based Constrained Delegation Abuse

If an attacker compromises an account with GenericWrite or GenericAll privileges over a target machine object, they can modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute and configure it for Resource-Based Constrained Delegation (RBCD) abuse.

The common way to conduct these attacks is to create a computer account and populate its msDS-AllowedToActOnBehalfOfOtherIdentity attribute with a computer account they control. Thanks to the MS-DS-Machine-Account-Quota attribute, this is usually possible.

SCCM Attack - Extracting Network Access Account (NAA) Credentials

SCCM (System Center Configuration Manager), now rebranded as MECM (Microsoft Endpoint Configuration Manager), is a Microsoft tool used for managing, deploying, and securing devices and applications across an enterprise network. It provides features like software deployment, patch management, operating system deployment, endpoint protection, and inventory tracking, helping organizations maintain compliance and streamline IT operations. It is part of the Microsoft Endpoint Manager suite.

The MS-DS-Machine-Account-Quota attribute is a crucial requirement when abusing the Network Access Account (NAA) in SCCM specifically. Network Access Account (NAA) credentials are a set of domain user credentials configured in Microsoft Endpoint Configuration Manager (MECM/ConfigMgr) that allow client devices without direct access to the Configuration Manager's distribution points (e.g., during OS deployment) to authenticate and download content like operating system images, packages, or updates.

MS-DS-Machine-Account-Quota is crucial in this step because it determines whether an attacker can create new computer accounts in the domain without administrative privileges, which can then be used to register as SCCM clients and request policies, including the NAAConfig policy containing obfuscated credentials. This enables attackers to bypass the need for compromising an existing device.

noPac

noPac is a privilege escalation vulnerability that can be achieved by combining two CVEs (CVE-2021-42278 and CVE-2021-42287). Let’s break down the steps to exploit this vulnerability to escalate privilege as domain administrator:

  • Enumerate Active Directory to identify the Domain Administrator account name and confirm that the domain allows machine account creation (check MS-DS-Machine-Account-Quota).

  • Create a new machine account and ensure the servicePrincipalName (SPN) is empty.

  • Exploit CVE-2021-42278 to modify the sAMAccountName of the newly created machine account to match the Domain Admin account name (this tricks Kerberos into confusing the machine account with a privileged account).

  • Obtain a Ticket-Granting Ticket (TGT) for the spoofed machine account, which now has the name of the Domain Admin account.

  • Restore the original machine account name to prevent detection when the Key Distribution Center (KDC) checks for it.

  • Exploit CVE-2021-42287 using the TGT by requesting a service ticket via S4U2Self, causing the KDC to issue a service ticket as if it were for the Domain Admin account.

As expected, a prerequisite is to create a machine account.

Conclusion

While there are other ways to gain access to machine accounts, such as compromising an existing device, the default MS-DS-Machine-Account-Quota setting significantly lowers the barrier for performing common Active Directory (AD) attacks that require access to a machine account. By reducing or eliminating the MS-DS-Machine-Account-Quota, organizations can make it significantly harder for attackers to perform these types of attacks, forcing them to rely on more complex and detectable methods, such as compromising existing devices or escalating privileges through other means. This simple configuration change is a critical step in hardening AD environments against common attack vectors.

Bonus: Remediation

Check your domain’s MS-DS-Machine-Account-Quota value by using the PowerShell AD Module:

Check your domain’s MS-DS-Machine-Account-Quota value by using the PowerShell AD Module:

or using netexec’s MAQ module:

or using netexec’s MAQ module:

Changing the ms-DS-MachineAccountQuota’s value to 0:

  • Open adsiedit.msc, select Action, and connect to the default naming context.

  • Right-click on the node that contains the distinguished name of your domain and click properties.

Find the ms-DS-MachineAccountQuota and change its value to 0.

Changing the ms-DS-MachineAccountQuota’s value to 0:
Open adsiedit.msc, select Action, and connect to the default naming context.
Right-click on the node that contains the distinguished name of your domain and click properties.
Find the ms-DS-MachineAccountQuota and change its value to 0.

This can also be done in “Active Directory Users and Computers”, but make sure that Advanced Features are checked in the View tab.

  • Right-click the domain and click properties

In the Attribute Editor tab, find the ms-DS-MachineAccountQuota and change its value to 0.

In the Attribute Editor tab, find the ms-DS-MachineAccountQuota and change its value to 0.

Create a dedicated account with the sole purpose and permission of joining computers to the domain, or just allow Domain Administrators from doing so via GPO as shown below.

Create a dedicated account with the sole purpose and permission of joining computers to the domain, or just allow Domain Administrators from doing so via GPO as shown below.

After these changes, only members of Domain Administrators can add or join computers to the domain.

After these changes, only members of Domain Administrators can add or join computers to the domain.

Let's Connect

Share your details, and a member of our team will be in touch soon.

Application Penetration Testing Beyond The Checkbox

Application Penetration Testing Sample Report

Take a look at our sample Application Penetration Testing report to get a better understanding of what information will be delivered in the final report.

Download Sample Report
Application Security Methodology Cover
Application Penetration Testing Methodology

Our Application Penetration Testing Methodology is derived from the OWASP Top 10:2021 and has been enhanced with current threats and our overall experience in the industry.

Download Methodology
Penetration Testing Buyer's Guide

Download our buyer’s guide to learn everything you need to know to successfully plan, scope and execute your penetration testing projects.

Download Guide
Packetlabs Company Logo
    • Toronto | HQ
    • 401 Bay Street, Suite 1600
    • Toronto, Ontario, Canada
    • M5H 2Y4
    • San Francisco | HQ
    • 580 California Street, 12th floor
    • San Francisco, CA, USA
    • 94104