It's always fun to get a sense of what a company is going through by listening to the recordings of teams meetings.

I found a juicy one today where a Domain Admin is worried that the next compromise won't be survivable because they don't have a physical Domain Controller. He believes the fact that all the Domain Controllers are virtualized means if the virtual infrastructure goes down, they're fully down.

First, he's not entirely wrong. If they don't have a cold start plan to bring things back up, then sure, not having a physical DC could be an issue.

But his take was: "We only survived the last compromise because one server didn't go down."

Isn't that like saying your house didn't really burn down because the garage is still standing?

Let me listen to more meetings.

Here's what I'm learning about this organization:

They have 40+ Domain Admins. Each one manages "their pair" of Domain Controllers. More DCs for redundancy instead of making sure redundant WAN links are in place. Everyone believes the work they do on "their" DCs doesn't affect the rest of the organization.

The Domain Admin who's worried about the virtual infrastructure failure? He's actually expressing a real fear: that the entire organization's identity infrastructure is consolidated on a hypervisor platform they can't control. That's a legitimate concern.

But he's treating the symptom, not the problem.

The problem isn't "we need a physical DC." The problem is "we have 40+ people with Domain Admin rights, each one convinced their corner of the infrastructure is separate from everyone else's, and we have no unified redundancy strategy."

This is security theatre. This is silos masquerading as segmentation.

Here's what I see:

Forty-three Domain Admins. Not Tier 0, not monitored as a group. Each one has "their" DCs, "their" applications, "their" piece of the organization. They don't talk to each other. They don't coordinate. They definitely don't think their mistakes affect anyone else.

Some of them are sleeping. Not protecting their credentials. Not watching their DCs. Not monitoring for lateral movement.

I have credentials from the SCCM compromise (remember the tiering article?). That got me local admin on a bunch of servers, including a couple of "tier 1" application servers. One of those servers has a scheduled task that runs under a service account. That service account has rights to reset passwords on the "tier 1" admin accounts.

I escalate to tier 1. Now I have credentials for accounts that are in a security group that has delegate permissions on a couple of DCs. Not Domain Admin, but close.

I use those credentials to request a service principal name on one of the tier 1 DCs. The DC's ACL is permissive because the person who manages "that DC" decided it was easier to grant broad rights to the tier 1 admins.

Now I have a kerberoastable account. I crack the password in forty-five minutes. That account is a member of a group that has "administrative" rights on a different DC. Not the same DC, but the other admin managing that DC granted the group rights because he trusts "the team."

Now I'm on a different DC, managed by a different Domain Admin, in a different organizational unit, who thought he was independent.

I repeat this five times. Each time, I'm escalating through the silos. Each time, a different Domain Admin's misplaced trust in "the team" gives me the next step.

By the time I reach a DC that has unrestricted replication rights, I have a path through seven different DA accounts, each one convinced their corner is secure.

I forge a golden ticket. Domain Admin. Full access.

I check the backup system. They're backing up the entire forest to a NAS that's "managed by IT." I check the NAS. It has a web interface exposed to the network. I spend an hour finding backups from six months ago. I extract the NTDS.DIT file. I have every password hash in the environment.

I put everything back. I don't touch anything else. I just walk away with domain admin credentials and the password hashes for forty-three DAs.

The next time there's an incident, they'll find the breach happened six months ago. They'll be confused about the attack path. They'll blame the virtual infrastructure.

They'll probably decide they need a physical DC.

If you're a defender, here's what just happened.

The architecture mistake

This isn't a virtualization problem. This is a trust boundary problem.

The organization has 43 Domain Admins. Each one thinks their DC is separate. Each one has granted permissions to "the team" because they work in the same organization. But there is no clear trust boundary. There is no isolation between the DCs.

The mistake wasn't virtualizing the DCs. The mistake was thinking that having "multiple people manage multiple DCs" is the same as having defence in depth.

It's not.

What they should be doing

  1. Consolidate Domain Admin rights. You don't need 43 of them. You need maybe 5-7, shared across the entire forest, with MFA and auditing on every action. Not "my DC" and "your DC." One forest. One team. One audit trail.
  2. Implement a DC access strategy. If you're virtualizing, fine. But implement a cold-start procedure, versioned snapshots, and a recovery plan that doesn't depend on "one server not going down."
  3. Unified monitoring. Every DC, every credential, every permission change. Not "each admin watches their own DC." One monitoring solution. One alert system. One incident response plan.
  4. Trust boundary enforcement. If different admins manage different systems, that's fine. But make it explicit. Enforce separation. Don't grant "team" permissions that blur the lines.
  5. Credential tiering. Not "tier 1 admins have rights to tier 1 servers." Tier 0 is the forest. Tier 1 is everything below it. Admins should not have both tier 0 and tier 1 access. Ever.

The virtual infrastructure isn't the problem. The silos masquerading as independence are.

The closing principle

When you have 43 Domain Admins, each thinking their corner is independent, you don't have 43 isolated systems. You have one system with 43 different people poking at it, each convinced their pokes don't affect anyone else.

That's not redundancy. That's a failure waiting to happen.

Most organizations with this structure will eventually experience a compromise that touches the whole forest. When they do, they'll look for a single point of failure to blame.

They won't find one, because the problem is the 43 separate points of trust, each one assuming the others are keeping their corner secure.

Hiro out.