Active Directory Computer Objects Attack Surface: The Machine Identity Risk Nobody Audits

Active Directory computer objects attack surface is the collective term for the delegation, replication-rights, and group-membership risks that machine accounts routinely carry — accounts Active Directory creates automatically for every domain-joined machine, and rarely audits the way it audits user accounts. Unlike user accounts, computer accounts rarely get individual attention: nobody reviews their delegation settings, their group memberships, or their patch level the way they'd review a privileged user. That gap is exactly what several well-established attack techniques rely on.

This article covers the computer-object attack surface specifically — as distinct from Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse, which explains the delegation mechanisms themselves, and ACL Abuse and DCSync: The Silent Paths to Domain Admin, which covers ACL-based escalation generally. Here the focus is narrower: which computer objects in your domain carry dangerous rights, and why that's so easy to miss.

What Is the Active Directory Computer Objects Attack Surface?

Every domain-joined Windows machine gets a computer account in Active Directory — a first-class security principal with its own SID, its own Kerberos credentials (rotated automatically, typically every 30 days), and the ability to hold group memberships and delegation rights just like a user account. That's the point: services running as SYSTEM on a domain-joined machine authenticate to the rest of the domain as that computer account.

The risk follows directly from that design. A computer account can be granted — deliberately or through drift — the same categories of dangerous rights a user account can: delegation that lets it impersonate other users, replication rights that enable DCSync, or membership in a privileged group. The difference is visibility: security teams routinely review which users are Domain Admins, but rarely ask which computers can act like one.

Why Computer Objects Fall Through the Cracks

Provisioning workflows create computer objects automatically, often through imaging, autopilot enrollment, or SCCM/Intune deployment — with no human review of the resulting object's rights at creation time. Attack paths like the ones covered in Active Directory Attack Paths to Domain Admin chain exactly this kind of unreviewed grant with other misconfigurations to reach Domain Admin; computer objects are a disproportionately common link in that chain precisely because they're rarely the subject of a dedicated review cycle the way privileged user accounts are.

Unconstrained Delegation on a Computer Object

When a computer account is configured for unconstrained delegation (the TRUSTED_FOR_DELEGATION UserAccountControl flag), any user who authenticates to a service on that machine has their full Ticket Granting Ticket (TGT) — not just a service ticket — cached in that machine's memory. According to security researcher Sean Metcalf's widely cited analysis of this risk, that means a single compromised unconstrained-delegation host can accumulate the TGTs of every user who authenticates to it, including domain controllers themselves when they're induced to connect.

Why It's Still Around

Unconstrained delegation was the original delegation model in Windows 2000 and has been superseded by constrained delegation and RBCD for legitimate use cases; Microsoft's own guidance recommends against using it. Its main risk today is legacy: servers configured for it years ago — often for print servers, early web application deployments, or ad hoc administrative tooling — and never revisited once the original justification was forgotten.

Resource-Based Constrained Delegation (RBCD) Abuse

Resource-based constrained delegation (RBCD) works differently from the older delegation models: instead of being configured on the account that needs to delegate, it's configured on the target resource itself, via the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. Whoever is listed in that attribute can impersonate arbitrary users to that specific resource.

The security implication was detailed in Elad Shamir's 2019 research, "Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory." The key finding: any principal with write access to a computer object's msDS-AllowedToActOnBehalfOfOtherIdentity attribute can configure RBCD for it — without needing the domain-admin-level privileges that older delegation models required. That includes a principal with only GenericAll, GenericWrite, or WriteDacl/WriteProperty rights on the target computer object. Shamir's research also showed that S4U2Self works on any account with an SPN regardless of its TrustedToAuthForDelegation setting, and that Microsoft's response at the time was that this was "not an issue which will be addressed via a security update" — RBCD's abuse potential is a consequence of its design, not a patchable bug.

Why RBCD Is an ACL Problem, Not a Delegation Problem

This makes RBCD abuse fundamentally an ACL problem on computer objects, not a delegation-configuration problem. A computer account with a seemingly low-risk ACL grant from a past project or default installer behavior can become a full impersonation primitive. Reviewing only the msDS-AllowedToActOnBehalfOfOtherIdentity value itself misses the exposure — the actual control point is who is permitted to write to it.

DCSync Rights Held by a Machine Account

DCSync abuses the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All extended rights, normally reserved for domain controllers, to pull password hashes for any account via the directory replication protocol. Domain controller computer accounts legitimately hold these rights. The risk covered here is different: a non-DC computer account that has been granted DCSync-capable rights, deliberately or by accident (for example, through an overly broad ACL template applied at the domain root, or replication rights granted to a backup/monitoring service account that happens to be machine-bound).

SpecterOps' BloodHound documentation describes the DCSync edge as the combination of these two rights on any principal — user, group, or computer — and notes it can also arise indirectly through constrained delegation misconfigurations, without the object ever holding the replication rights explicitly.

Computers in Privileged Groups

A computer account added to a privileged group (Domain Admins, Enterprise Admins, or a custom Tier 0 group) grants Domain Admin–equivalent rights to anything running as SYSTEM on that machine — which, in practice, means anyone who can get code execution on it. This is a different exposure profile from a privileged user account: a workstation or application server is generally easier to compromise than a hardened administrative endpoint, and its SYSTEM context is available to far more code paths (scheduled tasks, services, local admin accounts) than a single interactive user session.

This is the same structural problem covered in Dangerous Group Nesting: Hidden Paths to Domain Admin — a group membership that looks unremarkable in isolation becomes dangerous once you trace what actually has effective control of the machine holding it.

Obsolete Operating Systems Still in the Domain

Computer objects running Windows versions past their support lifecycle — Windows XP, Windows Server 2003, or earlier — no longer receive security updates from Microsoft, including for actively exploited vulnerabilities. A domain controller or member server on an obsolete OS is a standing, unpatchable weak point, and because these systems are often kept online for a specific legacy application, they tend to be excluded from routine patch and vulnerability management processes rather than flagged as the highest-priority exposure they represent.

These systems frequently overlap with the pattern described in Stale Privileged Accounts: Hidden Risk in Active Directory: both are exposures that persist specifically because nobody owns the decision to remove them.

Detection

Remediation

1. Mark Sensitive Accounts Non-Delegable

Set the Account is sensitive and cannot be delegated flag on high-value accounts so they can't be captured even by a compromised unconstrained-delegation host.

2. Remove Unconstrained Delegation Wherever Possible

Migrate legitimate use cases to constrained delegation or RBCD, which limit impersonation to specific target services.

3. Audit Every RBCD Configuration — and the ACLs That Allow Setting It

Review msDS-AllowedToActOnBehalfOfOtherIdentity on all computer objects, and — more importantly — review who holds GenericAll/GenericWrite/WriteDacl rights that would let them configure it in the first place.

4. Remove DCSync-Capable Rights from Non-DC Principals

Audit DS-Replication-Get-Changes / DS-Replication-Get-Changes-All grants at the domain root and any delegated OU.

5. Remove Computer Accounts from Privileged Groups

Unless there is a specific, documented, and reviewed reason for the membership, treat any hit as a finding to remediate, not a configuration to grandfather in.

6. Decommission or Isolate Obsolete-OS Systems

Where decommissioning isn't immediately possible, isolate the system on the network and remove any privileged rights or group memberships it holds.

# List computer objects configured for unconstrained delegation
Get-ADComputer -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation, OperatingSystem

# List computer objects with an RBCD configuration set
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
  Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' }

How EtcSec Detects This

EtcSec's Computers category covers this attack surface directly: COMPUTER_UNCONSTRAINED_DELEGATION, COMPUTER_RBCD, COMPUTER_DCSYNC_RIGHTS, and COMPUTER_IN_ADMIN_GROUP flag the delegation, replication-rights, and group-membership risks described above, while COMPUTER_OS_OBSOLETE_XP and COMPUTER_OS_OBSOLETE_2003 flag end-of-support operating systems still present in the domain.

Primary References

• Elad Shamir: Wagging the Dog — Abusing Resource-Based Constrained Delegation to Attack Active Directory
• ADSecurity.org (Sean Metcalf): Active Directory Security Risk #101 — Kerberos Unconstrained Delegation
• SpecterOps BloodHound Documentation: DCSync edge
• SpecterOps BloodHound Documentation: CoerceToTGT edge
• hackndo: Resource-Based Constrained Delegation — Risks
• Microsoft Learn: Making the second hop in PowerShell Remoting (delegation background)