“But…are you still master of your domain.” - Jerry Seinfeld

This is the introduction to a multi-part series on getting your Veeam servers out of your production (i.e. main user account) Active Directory domain.

Authn. Authentication. Who are you?

Authz. Authorization. What can you do?

An explanation of ADDS is beyond the scope of this series, but for context…Active Directory Domain Services (ADDS) provides a logical and physical structure for authn and authz within your network. Authn flows across a ‘Forest’ whilst domains are used primarily as replication partitions, being sub-units of a forest (namespace ‘trees’ being a way to organize domains). Another reason to use domains is as a logical security boundary for the seemingly all-powerful ‘Domain Admin’ account.

Generally, the best practice is that Veeam components, where appropriate, are "off the production domain". There are two primary reasons for this: first, a compromised production domain admin account can not only wreak havoc on prod AD objects and their resources (which makes it a juicy target), but can also (potentially) compromise Veeam (or any service). The reason for this is that Domain Admins are automatically added into Local Admins groups (or Domain Local Admins on domain controllers) on all Windows systems within the domain. There are some ways you can prevent this inheritance (like Restricted Groups, or GPO’s managing group memberships) but Microsoft generally seem to recommend you don’t. A separate boundary might be best and easiest.

Note that this only applies to Windows systems, not Linux systems that might be domain-joined (no real equivalency of local admin inheritance).

Secondly, a compromised domain admin has the potential to modify/create and apply GPO's (Group Policy Objects) to Windows servers in the domain that could introduce further vulnerabilities (think escalating group memberships, turning off firewalls, stopping services... that kind of thing). This could also disable any policies restricting group membership on specific systems.

Domain Admins only roam within the domain in which they belong without actively and specifically escalating permissions, typically through group memberships (to Enterprise Admins, for example, or specifically adding them to local admins on a system across a trust). So... if a domain admin in one domain is compromised, it is not a given that they can suddenly roam the entire forest and access stuff (making the distinction here between authn and authz). In essence the same is true of GPO's - most organizations do not or cannot apply GPO's at a forest level (again, that requires specifically elevated privileges) and the domain tends to be the logical outer-edge boundary (OU's being more common, of course. Rare to see Site-level GPO). A compromised GPO in production domain doesn't typically impact resources in other domains.

Workgroups are great and all, and definitely a supported option. But there are considerations here: they close off the option to use kerberos authn, GMSA and (often) other domain-bound services that any organizations might have implemented e.g. for password/authz management, auditing, monitoring etc. In addition, you lose the ability to (easily) apply GPO's for a whole range of services that might apply to parts of the Veeam infrastructure e.g. you want to tighten up an auditing policy across 30 Veeam proxies. There are benefits to having things run in a domain. That's why organizations run most things in a domain where they can, in addition to potential internal policy requirements.

The best practice is a separate active directory forest, with a one-way forest trust. It provides the highest level of authz and authn separation while maintaining AD advantages. It does add complexity to your AD management, but provides clear separation.

The next parts in this series will run through some simple ‘how-to-do’ for the different scenarios:

• Migrate the Veeam Infrastructure from a Production Domain to a Child Domain
• Migrate the Veeam Infrastructure from a Production Domain to a Backup Workgroup
• Migrate the Veeam Infrastructure from a Production Forest/Domain to a Backup Forest/Domain

Other links

• Veeam Best Practice Security section (https://bp.veeam.com/security/).
• Active Directory Domain Services Overview (https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview)