What Are Shadow Admins in AD?
A common problem we encounter within many customer Active Directory environments are accounts that, at first glance, may appear innocuous, but that actually have hidden administrative privileges or unrolled privileges equivalent to those of a domain administrator account. We call these accounts shadow domain admins.
These accounts don’t show up when you run the net group domain admins command. They won’t appear in your PAM solution’s audit reports. But an attacker who finds one has effectively won the domain. Over the past several years, the problem has gotten significantly worse as organizations undergo digital transformation. Workloads are migrating to AWS and Azure, identity is being federated to the cloud via ADFS, and domain controllers are running as virtual machines on ESXi. The blast radius of a single compromised account now extends well beyond the traditional Active Directory boundary. A shadow admin path in 2016 might have been a service account with an overly permissive ACL. In 2026, it’s an ADFS server running on a hypervisor managed by a VMware admin who doesn’t even know they’re one hop from domain admin, and two hops from your entire AWS environment.
In this post, we’ll walk through several real-world examples we routinely discover during engagements and show how Praetorian Guard’s continuous attack path mapping surfaces them before an adversary does.
ADFS Servers and the Federation Layer
If your organization federates identity to cloud providers using Active Directory Federation Services (ADFS), you’ve almost certainly heard of the Golden SAML technique that was exploited in the SolarWinds (Solorigate) attack. The ADFS server holds the token-signing certificate, the private key used to generate SAML assertions that cloud providers accept as proof of identity. If an attacker compromises that server, they can forge tokens for any federated user, including cloud administrators.
You may be wondering: why does this matter for a discussion about Active Directory shadow admins? The answer is that it creates shadow admins in both directions. On-prem compromise of the ADFS server gives an attacker access to your entire AWS Organization, Azure subscriptions, and GCP projects. Conversely, if that ADFS server itself runs as an EC2 instance or Azure VM, or is managed through a cloud-hosted configuration pipeline, then a cloud-level compromise gives an attacker a path back into on-prem AD.
The practical result is that anyone with administrative access to the ADFS server, or to the infrastructure it runs on, is effectively a shadow domain admin for your cloud environment and potentially for your on-premises domain as well. This often includes the server admin team, the backup operators, and (as we’ll see in the next section) the virtualization team.
Remediation: Treat ADFS servers as Tier 0 assets equivalent to domain controllers. Where possible, migrate to cloud-native authentication (Seamless SSO or Pass-through Authentication) to eliminate the on-premises token-signing key entirely.
Hypervisor Admins: Shadow Admin Privilege Paths Through VMware
Most organizations virtualize their domain controllers. This makes operational sense, but if you’ve ever thought about it from an attacker’s perspective, the implications are significant: if your domain controllers run as VMs on ESXi, then anyone with administrative access to the hypervisor has implicit access to the DC guest. A VMware admin can snapshot a DC and extract the NTDS.dit offline, access the virtual console, attach a boot disk, or clone the entire VM for offline credential extraction.
A natural question is: what if you don’t have full VM admin access, but you do have ESXi console access (VMRC)? In practice, this is often enough. An operator with VMRC access can interact with the Windows login screen directly, authenticate as any domain user, and then attempt local privilege escalation..
This same logic applies to every Tier 0 asset that has been virtualized: ADFS servers, PKI certificate authorities, Azure AD Connect servers. If your ADFS server from the previous section is running on ESXi, the hypervisor admin can compromise it, extract the token-signing certificate, and forge SAML tokens into your cloud environment, all without ever authenticating to Active Directory. That’s a shadow admin chain spanning three distinct administrative domains (VMware, AD, AWS), and none of the three teams involved would typically have visibility into the full path.
Remediation: If a hypervisor hosts a Tier 0 VM, the hypervisor is Tier 0. Dedicate specific ESXi hosts exclusively to Tier 0 workloads. Restrict VMRC access to Tier 0 administrators only.
Helpdesk Permission Abuse and ACLs
In a typical delegation model, helpdesk administrators are granted write access to computer account objects in Active Directory. This seems completely benign. Helpdesk staff need to reset machine passwords, update descriptions, and manage attributes during reimaging.
The problem is that write access to a computer account object includes the ability to modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, which controls Resource-Based Constrained Delegation (RBCD). An attacker who compromises a helpdesk account can configure any writable computer object to trust an attacker-controlled account for delegation, then use S4U2Self and S4U2Proxy to impersonate a domain admin on that machine. If the writable computer object is a domain controller, the domain is compromised.
We frequently see this pattern amplified by ACL drift. On a recent engagement, Guard’s ACL Ownership Drift analysis revealed delegation groups with GenericAll on service accounts that had AddMember on admin groups, alongside other groups with WriteAccountRestrictions on privileged accounts. Each hop looked reasonable in isolation. Chained together, they created a path from a low-privilege delegation group to full domain compromise.
Remediation: Remove write access to DC computer objects from all non-Tier 0 groups. Restrict helpdesk delegation to OUs that don’t contain Tier 0 or Tier 1 machine accounts.
Azure AD Connect: Shadow Admin Accounts in Microsoft Active Directory
If you’ve set up Azure AD Connect for directory synchronization, you’ve almost certainly seen the MSOL_ prefixed service accounts that it provides. These accounts require DCSync rights by design, the exact permissions needed to replicate every password hash in the domain.
On a recent engagement, Guard’s DCSync rights audit flagged [email protected] with its password set to never expire, ACL-protected via AdminSDHolder, and with GenericWrite and GenericAll on multiple delegation groups. It had been sitting untouched for years.
What makes this especially concerning is that the Azure AD Connect server is often treated as a mid-tier application server rather than a Tier 0 asset. It frequently runs on a shared hypervisor (see the previous section on hypervisor admins), is managed by a team that also manages general-purpose infrastructure, and is backed up by the same solution that handles everything else. Any of those adjacent systems provides an indirect path to DCSync and full domain compromise.
Remediation: Treat the Azure AD Connect server as Tier 0. Consider migrating to Azure AD Cloud Sync, which avoids provisioning a domain-level DCSync account.
Understanding Shadow Admin Levels and Detection
What makes this especially concerning is that the Azure AD Connect server is often treated as a mid-tier application server rather than a Tier 0 asset. It frequently runs on a shared hypervisor (see the previous section on hypervisor admins), is managed by a team that also manages general-purpose infrastructure, and is backed up by the same solution that handles everything else. Any of those adjacent systems provides an indirect path to DCSync and full domain compromise.
Remediation: Treat the Azure AD Connect server as Tier 0. Consider migrating to Azure AD Cloud Sync, which avoids provisioning a domain-level DCSync account.
Conclusions
The common thread across these examples is that shadow admin paths increasingly cross the boundaries between administrative domains. Your VMware team, your helpdesk, your cloud operations team, and your identity team are all managing separate slices of an interconnected system, and none of them has full visibility into how their permissions compose with everyone else’s.
These are just a subset of examples from recent engagements. This issue extends beyond Active Directory as well. In a previous post, we showed how vulnerability scanner accounts configured with root privileges and password-based SSH authentication can be intercepted on a compromised host, turning your own security tooling into a lateral movement vector.
In the real world, it is very difficult to cleanly segment privileges between different tiers of users: developers, helpdesk staff, mid-level admins, VMware operators, cloud engineers. There is always a balance between security and usability. Additional security controls add friction to development and engineering processes. But the risk posed by each control, or the absence of one, must be carefully understood.
The takeaway is clear:
- Treat any identity with a transitive path to domain admin as a shadow domain admin, regardless of what team manages it.
- Audit built-in groups, not just Domain Admins and Enterprise Admins.
- Any system hosting or managing a Tier 0 asset is itself Tier 0: hypervisors, ADFS servers, AD Connect servers.
- Federation infrastructure is the bridge between your on-prem domain and your cloud. Secure it accordingly.
- ACL drift is continuous. Point-in-time reviews aren’t enough.
Praetorian Guard’s continuous attack path mapping helps surface these paths as they emerge rather than six months later during your next pentest. If you’re running Active Directory, you have shadow domain admins. The question is whether you find them first, or an attacker does.
Want to see what shadow admin paths exist in your environment? Request a Guard demo and we’ll show you.
