What breaks when Machine Account Quota and ADCS templates are left loose?

Why This Matters for Security Teams

When machine account quota and ADCS templates are left loose, the directory stops behaving like a controlled trust system and starts behaving like a certificate factory. A low-privilege user can create machine account, then abuse weak certificate enrollment paths to obtain identities that can authenticate as more privileged principals. That is not a minor misconfiguration; it is a direct path from ordinary user access to domain-level impersonation. The underlying problem is that identity issuance becomes cheap, fast, and poorly accountable. This failure maps cleanly to the broader non-human identity problem NHI Mgmt Group tracks across enterprise environments. In its Ultimate Guide to NHIs, NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which is exactly the kind of condition that turns one weak control into a lateral-movement event. Similar patterns show up in incidents like the Schneider Electric credentials breach, where identity sprawl becomes an attack surface rather than a control point. In practice, many security teams encounter this only after forged trust paths have already been used to move from a low-value account into privileged administration.

How It Works in Practice

The abuse chain is straightforward. First, Machine Account Quota allows an unprivileged domain user to create machine accounts, which are themselves trusted directory objects. Second, weak or misconfigured ADCS templates allow enrollment for certificates that can be mapped to other identities, often with authentication capabilities far beyond the original user’s role. Once the certificate is issued, the attacker can present it as cryptographic proof of identity and use it to access services, request further privileges, or pivot into administrator-level operations. The practical defense is to treat machine-account creation and certificate issuance as privileged actions, not routine self-service. Current guidance suggests combining several controls rather than relying on one hardening change:

• Set Machine Account Quota to zero unless there is a documented business reason to allow self-service creation.
• Restrict ADCS template permissions so only approved principals can enroll, autoenroll, or modify template settings.
• Review whether templates permit client authentication, subject alternative name supply, or other attributes that expand impersonation risk.
• Apply separate approval and monitoring for certificate templates that can be used for authentication, not just encryption.
• Correlate directory changes with certificate issuance events so trust-path creation is visible in audit logs.

This is consistent with the control mindset in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access control, least privilege, and auditability. The same logic also fits the way NHI Mgmt Group frames lifecycle risk in its Ultimate Guide to NHIs, where short-lived trust and clear ownership matter more than convenience. These controls tend to break down in legacy Active Directory environments where certificate services, delegated administration, and inherited permissions are tightly intertwined because permission boundaries are already too broad.

Common Variations and Edge Cases

Tighter machine-account and certificate controls often increase operational overhead, requiring organisations to balance administrative convenience against identity assurance. That tradeoff becomes sharper in environments with automated provisioning, mergers, or legacy applications that still depend on ADCS-backed authentication. There is no universal standard for this yet, but current guidance suggests treating the riskiest templates as high-value authentication assets rather than generic infrastructure. Some environments can tolerate self-service machine creation with strong monitoring, while others need a hard deny because delegated admin models make abuse too easy. The same is true for certificate templates: a template that is harmless for internal encryption may be dangerous if it can mint logon-capable credentials. Security teams should also account for chained abuse. A weak template may not be the end goal; it may simply be the easiest way to obtain a trusted identity that later enables privilege escalation, persistence, or cross-system movement. That is why incidents involving identity misuse often resemble the GitHub Personal Account Breach pattern more than a traditional malware event: once identity trust is broken, the attacker’s access can look legitimate. The right question is not whether the setting is convenient, but whether it allows identity material to be minted without the accountability applied to other privileged actions.

Related resources from NHI Mgmt Group

• How should teams respond when a service account token is exposed?
• What breaks when orphaned machine identities are left in place?
• What breaks when machine identities are left outside IGA?
• What breaks when machine identity sprawl is left unmanaged?