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.