The old default

In many domains, authenticated users can create computer objects by default. That was convenient historically, but it rarely fits modern security models.

For AD security, the question is simple: who may introduce new identities into the domain, and who controls their rights, SPNs and lifecycle afterwards?

Clean target state

  • Set ms-DS-MachineAccountQuota to 0.
  • Handle domain join through delegated groups, processes or provisioning tools.
  • Create computer objects in controlled OUs.
  • Review join, delete, reset and move rights separately.
  • Monitor changes to the quota.

What I would check

MachineAccountQuota is only the visible entry point. The next items are OU delegations, old join accounts, broad helpdesk rights and unclear processes for re-imaging or hybrid join.

What gets better

  • Regular users can no longer create new computer identities uncontrolled.
  • Domain join becomes part of a traceable process with delegation, logging and ownership.
  • Attack paths through self-created computer objects are reduced.

Where it can hurt

  • Helpdesk and deployment processes break if legitimate join scenarios are not inventoried first.
  • Broad replacement delegations recreate the same problem elsewhere.
  • Hybrid join, Autopilot or re-imaging need clear exception paths.

Checks before rollout

  1. Who joined machines before and through which process?
  2. Which OUs allow join, move, reset or delete?
  3. Which join accounts are old, shared or too broadly privileged?
  4. How is a quota change monitored?

Bottom line

New computer objects are new identities. Creating them should be controlled like any other privileged operation.