Oxford Style Debate – Episode 3:Should Backups Trust AD?

I challenge ​@falkob , ​@Tommy O'Shea , ​@kciolek 😎

Definitely going to craft a response to this one as I am against the statement and will explain why. 😉😎

So let’s put this into the right perspective :) The Falko take is the following: joining backup infrastructure components to your production AD is a mistake. Joining it to an AD isn't necessarily one. Therefore I’m against it as long as it is not the production AD. The core problem isn’t Active Directoy as a technology, it is the shared fate :) We have all heard of bad threat actors trying to gain credentials to AD first by using credential dumping or Kerberoasting.

Veeam’s own security best practice says this for years now exactly for the reason I outlined above.

That being said, if you want to use AD, use a dedicate backup / non production forest with a 1-way trust, even though its some heavy-lifting in setting up and maintaining it. This gives you gMSA, auditing, centralized management and policies without inheriting production AD’s compromise. Essentially what I’m trying to say is adopt a “Tier 0” thinking to your backup environment.

So depending on if i understood the debate statement the mistake isn’t “AD”, it is trusting the same identity provider the attackers will (and really want to) own.

I’ve seen customers adopting this kind of deployment and they were very happy when they could simply lock down users in their backup forest with a Group Policy without losing time doing it on different machines manually, thats one thing that safes people ! I personally have done the “workgroup” to “separate forest” migrations for a couple of times and what stood out is customers loving the fact to not maintain “local credential hygiene” but rather use LAPS for example. 

In addition, and that is an important one out of experience, a workgroup with a shared local admin password on a VBR, a proxy and repo servers is worse than aa well tiered-domain join in production haha :D

At the end of the day it's simple: shared identity means shared fate. And shared fate is the one thing a last line of defense can never afford.

Cheers !

You just nailed some of the points I was working on, well done.  

Let me chum the water a little more.

Still FOR. Falko and I would probably build the same thing. We part company on what the separate forest solves. It breaks the dependency on production AD, but the backup servers remain domain-joined.

Between March and October 2025, three Veeam KB articles documented CVE-2025-23120, CVE-2025-23121, CVE-2025-48983, and CVE-2025-48984. Each is CVSS 9.9 and permits remote code execution on a domain-joined backup server or backup infrastructure host. The required privilege is an authenticated domain user, not Domain Admin.

The patch cycle is not all that interesting IMO. Workgroup systems sat outside the scope. A backup server joined to a domain in a separate forest did not, because the code path is still there. What the forest changes is who can authenticate to it, provided production identities cannot traverse the trust into the backup forest. The exposure is smaller, not gone, which is why I still call the join itself the mistake.

Most of my work is DR, so I already assume production AD is offline or compromised when recovery begins. Joining the VBR and the repositories to it puts them inside the boundary I am trying to recover from so..

Falko is right that a workgroup carrying one shared local admin password across VBR, a proxy and the repositories is worse than a properly tiered domain join. A workgroup run badly is not an argument for anything. It leaves you managing local accounts and using NTLM. gMSA also requires a domain-joined guest interaction prox. 

So where AD is required, same answer as his. I'd rather avoid the join entirely, but sometimes it is what it is. Dedicated forest, a one-way trust with selective authentication, and a documented local Veeam account for break glass. The one thing I would add is that its domain controllers cannot all sit on production virtualization and storage, or the forest will not be there when you need it.

Someone will mention v13. KB4696 states the Software Appliance and v13 for Windows are architecturally not impacted by these types of vulnerabilities, which is a real fix. It still took four CVEs to get there, and workgroup shops were never in scope for any of them if we are honest. 

AD can be well run and still fail or become untrusted. I will take the extra administration to keep Veeam working when that happens.

Here is my take around whether your Veeam backup infrastructure should be joined to Active Directory. Some people argue that backup servers should never be domain joined because Active Directory is often the first thing attackers target during a ransomware attack.

I understand the concern, but I don't completely agree.

From my perspective, joining your Veeam infrastructure to Active Directory isn't the problem. How you secure it is what really matters.

In the lab, we build and test environments the same way many of our customers do. In most enterprise deployments, Veeam Backup & Replication, Enterprise Manager, backup proxies, and even Windows repositories are joined to the domain. That's not because it's the easiest option—it's because it simplifies administration, integrates with existing security policies, and allows organizations to manage their infrastructure consistently.

Being domain joined doesn't automatically make your backup environment insecure.

What makes it insecure is giving backup servers the same level of exposure and privileges as the rest of your production environment.

If you're going to join Veeam to Active Directory, there are several best practices you should follow.

Use dedicated service accounts instead of Domain Admin accounts. Implement role-based access control so administrators only have the permissions they need. Enable multifactor authentication where supported, especially for Enterprise Manager and remote access. Protect your repositories with immutability, whether that's a Hardened Repository, Object First OOTBI, Dell Data Domain, ExaGrid, or immutable object storage. Most importantly, monitor and audit privileged access just like you would any other critical system.

One mistake I still see is organizations using Domain Admin credentials to install or manage Veeam. There's simply no reason for that. Veeam can operate with far fewer privileges, and reducing administrative rights significantly limits the impact if an account is compromised.

Another consideration is recovery planning. If Active Directory is unavailable, do you have a documented process to access your backup environment? Local emergency administrator accounts, protected break-glass credentials, and tested recovery procedures should all be part of your design.

Cyber resilience isn't about avoiding Active Directory entirely. It's about designing your environment so that no single compromise takes everything down with it.

For most organizations, joining Veeam to Active Directory is the right choice because of the operational benefits. The key is combining that with proper privilege management, immutability, MFA, network segmentation, monitoring, and regular recovery testing.

At the end of the day, backup security isn't determined by whether your servers are domain joined. It's determined by the architecture and security controls you put around them.

As with most things in IT, there isn't a one-size-fits-all answer. Every environment has different security requirements and operational needs. The important thing is understanding the risks, following best practices, and building a backup environment that you can trust when it matters most.

Being late to the debate, my initial take closely resembles the others in being a conditional statement. "Joining your Veeam backup infrastructure (VBR server, proxies, repositories, Enterprise Manager, etc.) to Active Directory is a security mistake." IF the Active Directory environment is one and the same with the production environment being protected.

For the sake of argument (or shall we say debate) however, I will craft my response as through the prompt implies adding Veeam to the production Active Directory.

So, the below will be a response FOR the debate statement;

We know that Veeam best practices recommend keeping Veeam off the domain, and since Madi is looking for first-hand experience instead of best practices this time around, I thought I'd share a story.

When I was just starting out at an MSP, we had just assumed responsibility of a new customer's IT infrastructure. This infrastructure was made up of a single rack with a 3-node VMware cluster with its storage centralized on a Nimble storage array. In the server room, there was a workstation with Veeam installed, along with some very convenient (for the threat actor) excel files with a list of passwords.

Early into our onboarding process with them, we received a call one morning that nothing was accessible. Phones, Exchange, project management software, nothing worked. When we went onsite, we found that each of their ESXi hosts and VMFS datastores had been encrypted. The aforementioned workstation was still around, but had been mostly been wiped clean with ransom instructions. The silver lining in this story however is that the Nimble array had been configured to take snapshots at regular intervals and the attacker didn't know about their existence. We were able to recover the LUNs, and rebuild the ESXi hosts.

We can only assume that a threat actor was able to use domain credentials that had appropriate permissions to get access to that workstation, and from there was able to use those credentials to attack the production environment. There were certainly multiple points of failure for this attack including poor password management, so saying that keeping the Veeam server off the domain would have prevented the attack isn't totally accurate, however it may have allowed backups to be the last line of defense instead of the SAN.

Based on this experience I would never and have never recommended that someone join their Veeam server to the production domain. The convenience that comes from having it joined is not worth the elevated risk of an attack.

Against: Domain-Joining Veeam Infrastructure Is a Security Mistake

I am against this statement and here is why since I have done both Workgroup and Domain Veeam implementations.

The proposition asks us to fear Active Directory — to treat the identity platform as an inherent liability.  Active Directory is not the vulnerability. Poor security posture is the vulnerability. And abandoning domain integration does not eliminate that posture — it simply trades one set of risks for an operationally painful set of new ones.

The Best Practice Argument

Veeam's own hardening documentation does not mandate workgroup isolation as a baseline requirement. What it mandates is layered security — and Active Directory, when configured correctly, enables that layering rather than undermining it.

Consider what domain membership actually gives you:

• Group Managed Service Accounts (gMSA) — Veeam fully supports gMSA for service accounts. These accounts carry automatically rotating, complex passwords that no human ever sees and no attacker can easily extract. A workgroup environment cannot offer this.
• Security Group-Based RBAC — Veeam's role-based access control integrates directly with AD security groups. You assign a group; you manage membership centrally. In a workgroup, every permission change is a manual, per-server operation. That is not tighter security — that is security theatre with extra steps.
• GPO-enforced hardening — TLS configurations, audit policies, Windows Firewall baselines, and credential guard settings can all be pushed consistently via Group Policy. A workgroup environment requires you to enforce these individually, manually, and without audit trail consistency.

From the Field: What Actually Happened

I will speak plainly from operational experience.

Our environment underwent a domain transition — not a compromise, but a deliberate migration to a new domain. Nothing broke. What changed was that user management became dramatically simpler. RBAC, which had been cumbersome, became clean and auditable. The overhead is mitigated by domain membership.

We implemented security controls on top of domain membership:

• DUO MFA enforced on all Windows servers for RDP access — This single control dramatically narrows the blast radius of any compromised domain credential. An attacker with a valid AD credential still cannot RDP to a backup server without passing a second factor they do not possess.

The strongest argument is that AD is the identity platform attackers target most. This is true. I do not dispute it.

By that reasoning, we should also isolate from DNS, from network switches, from every foundational infrastructure component that attackers target. The answer to a targeted platform is hardening and compensating controls, not abandonment.

A workgroup environment introduces its own critical failure modes:

• Local administrator accounts with static passwords — a credential hygiene nightmare at scale
• No centralized audit logging of authentication events
• Manual, inconsistent patching and policy enforcement
• Backup infrastructure that becomes operationally harder to manage — which, under incident response pressure, means slower recovery, not faster

Having workgroup isolation as a clean air gap, in practice, it is a maintenance burden that grows linearly with infrastructure size and degrades security consistency over time.

A domain-joined Veeam infrastructure, protected by gMSA service accounts, MFA on all administrative access, network segmentation, and properly scoped RBAC, is more secure than an equivalent workgroup environment — because it is consistently enforceable, centrally auditable, and operationally sustainable.

I migrated part of our Veeam infrastructure to the new domain we now use, and I am planning the remaining Veeam services as well in the near future.

I challenge ​@HangTen416