If your Active Directory (AD) has some years on it, there’s a good chance the domain-join model was never revisited after it “just worked.” That’s risky—especially in multi-site environments that span both OT and IT.

Microsoft just updated their guidance on domain-join permissions—a clear signal that Redmond still invests in hardening on-prem Active Directory, not only Entra ID. The update tightens how computer accounts are created and re-used, reducing long-standing risks from legacy join models. This post turns that guidance into concrete steps you can apply today.

What’s the risk—and how did we used to do it?

Two legacy practices create unnecessary attack surface:

1. MachineAccountQuota (MAQ): By default, any authenticated user can create up to 10 computer accounts in a domain (Microsoft Learn). Across hundreds or thousands of users, that easily becomes thousands of machines created without central oversight.
2. “Add workstations to domain” (SeMachineAccountPrivilege): An old user right that lets assigned users add devices to the domain. It’s overly permissive and not recommended today (Microsoft Learn (legacy)).

Microsoft’s current guidance moves away from “let users join machines” and toward narrow, OU-scoped delegation plus a hardened re-join process (Active Directory domain join permissions).

Important change: Hardened re-join (NetJoin)

Since October 11, 2022, Windows updates added checks that block re-using an existing computer account unless it’s owned by the joiner (or explicitly allow-listed). As of August 13, 2024, the old NetJoinLegacyAccountReuse registry workaround was removed; use the new DC policy instead: Domain controller: Allow computer account re-use during domain join (KB5020276).

What “good” looks like in 2025

1) Turn off “anyone can add 10 computers”

Set MachineAccountQuota = 0 at the domain level so regular users cannot create machine accounts at all (attribute reference).

# Run in elevated PowerShell on a domain-joined admin workstation
Import-Module ActiveDirectory
Set-ADDomain -Identity (Get-ADDomain).DNSRoot -Replace @{ 'ms-DS-MachineAccountQuota' = 0 }

2) Stop using “Add workstations to domain”

Do not grant SeMachineAccountPrivilege to broad groups. Instead, delegate Create Computer objects on the target OU to a small, vetted “joiners” group per site/zone (Microsoft guidance).

3) Control re-join with the DC allow-list

Enable on domain controllers only:

• Policy: Domain controller: Allow computer account re-use during domain join
• Path: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options

Add only trusted owners (prefer groups) who are allowed to reuse staged/pre-created accounts. Ensure all DCs and member clients have the required updates (KB5020276).

4) Use a Staging OU with guardrails

New/unknown computers should never land directly in production OUs. Redirect the built-in Computers container to a Staging OU where you can apply a quarantine GPO (redirect guidance, redircmp reference):

redircmp "OU=Staging-Computers,OU=Tier2-Workstations,DC=example,DC=com"

Quarantine GPO ideas: deny interactive logon, strict firewall, require Windows LAPS, force EDR install, no local admin. Promote/move the object into its final OU only after checks pass.

5) Prefer Offline Domain Join (ODJ) for OT / segmented networks

djoin.exe lets you join without contacting a DC during the join—ideal for plants or isolated build networks (ODJ overview, command reference).

# On an admin host (provision in the Staging OU)
djoin /provision /domain example.com /machine NEWPC01 /machineou "OU=Staging-Computers,DC=example,DC=com" /savefile C:\odjblob.txt

# On the target device (can be offline)
djoin /requestodj /loadfile C:\odjblob.txt /windowspath C:\Windows /localos

Step-by-step rollout

1. Inventory & backup: Record current MAQ, any use of SeMachineAccountPrivilege, existing OU delegations, and join workflows. Backup GPOs and export OU ACLs.
2. Set MAQ=0: Communicate the change; schedule a quiet window. Monitor for failed joins to discover undocumented processes.
3. Create site-scoped Joiner groups: e.g., IT-Joiners-SiteA, OT-Joiners-Plant7; least privilege, named users only.
4. Delegate per OU: Grant Create/Delete Computer objects only on the OUs that will host computers. Avoid container- or domain-wide permissions (how Microsoft recommends delegating).
5. Enable the DC allow-list: Set Domain controller: Allow computer account re-use during domain join and add the Joiner groups (KB5020276).
6. Create and activate the Staging OU: Redirect Computers via redircmp; apply a quarantine GPO and a documented approval/move workflow (guidance).
7. Adopt ODJ IF needed: Especially in OT or isolated VLANs; integrate djoin into your build process (ODJ overview).
8. Audit & alert: Monitor who creates/owns new computer accounts; alert on creation outside approved OUs and on join/re-join failures.

Why this matters

• OT: ODJ + Staging OU enable predictable, auditable joins in segmented networks with minimal privilege on the wire.
• IT: OU-scoped delegation and MAQ=0 reduce standing rights and keep inventory clean.
• Everywhere: MAQ=0 + OU delegation + DC allow-list drastically reduces attack surface—without slowing admins down.

People often say, well people can join a computer SO WHAT…. then i guess you did not think i through, let me outline a common scenario:

Example attack: “Adopt-a-Computer” via legacy join + account re-use

Environment weaknesses – meaning BEFORE you saw this article 🙂

• MachineAccountQuota (MAQ) still 10 (default).
• Some users/groups still have Add workstations to domain.
• No DC allow-list for computer account re-use.
• New machines land in the default Computers container (no quarantine GPO).

Attack story (high level)

1. Low-priv foothold: An attacker obtains credentials for a normal domain user (phish/reuse).
2. Silent enrollment: Because MAQ>0 or “Add workstations to domain” is enabled, the attacker adds a rogue device to the domain under an innocuous name.
3. Identity hijack (re-use): The attacker notices an old or decommissioned computer account (e.g., PLANT-ENG-01) that still has useful ACLs/GPO-based rights. With legacy behavior (no DC allow-list), they re-join using that existing account, effectively taking over that machine identity.
4. Privilege by placement: That machine identity inherits group memberships, GPOs, file share ACLs, and certificates (e.g., auto-enrolled machine certs, Wi-Fi/VPN access). The attacker now moves laterally as a “trusted computer,” blending in with normal management traffic.
5. Persistence: Because new objects land in Computers, there’s no quarantine GPO to block logon, force EDR, or require LAPS. The rogue machine stays functional until someone notices an extra hostname.

Impact

Access to sensitive shares and services granted to that machine’s identity.

Possible use of machine certs for Wi-Fi/VPN authentication.

Lateral movement under the cover of legitimate GPOs and management tools.

References

• Active Directory domain join permissions (Microsoft Learn)
• KB5020276 — NetJoin domain-join hardening (Microsoft Support)
• Default limit: users can join 10 computers (Microsoft Learn)
• “Add workstations to domain” (legacy user right) (Microsoft Learn)
• Redirect Users/Computers containers (Microsoft Learn)
• Redircmp command reference (Microsoft Learn)
• Offline Domain Join overview (Microsoft Learn)