Skip to main content
  • EN

Introduction

In the first of 4 blog posts of this sMigrate Veeam Infrastructure Off Production Domain series], we described the fundamental security reasons behind moving the Veeam infrastructure components OFF Production domain.

 

In this blog post, we will provide step by step guidance for moving a Veeam Backup and Replication™️ (VBR) infrastructure off the Production Domain onto a Backup Workgroup.

 

Disclaimer: This is not intended to be a complete Security Best practice reference, nor does it address every possible scenario. A Veeam Solutions Architect can be engaged as needed to assist with VBR Security Best Practices, especially with complex deployments.

Setup

 

 

The scenario is comprised of the following servers:

  • A Production Domain Controller / DNS server
  • 2 ESX hosts and 1 vCenter
  • Veeam Backup and Replication server (VBR) with local PostgreSQL database
  • Veeam Enterprise Manager server (VBEM) with local PostgreSQL database
  • Veeam Gateway server
  • Veeam Mount server
  • Veeam ONE server
  • Veeam Proxy server
  • Veeam Recovery Orchestrator server

 

All servers are currently joined to the Production Domain.

 

VBR is configured with multiple backup jobs.

 

Move VBR from a Production Domain to a Backup Workgroup

In this scenario, like with many existing environments, Veeam components will have been deployed onto the Production Domain. This scenario describes how to better protect the Veeam environment by moving it into a Backup Workgroup.

 

Order of operations

This is the order in which we need to address the Veeam components for a successful move to a Workgroup.

  1. Enterprise Manager server
  2. Veeam Backup and Replication server
  3. All other Veeam components

Enterprise Manager

  • Log into Enterprise Manager Server as a local account Administrator to avoid issues while getting off the Production Domain.
  • Export the Enterprise Manager Keyset and store it in a safe location as per the user guide.
  • Add the local administrator user as a portal administrator.
  • Identify and backup the Enterprise Manager Configuration database (see kb1471).

We will use the DBconfig utility.

  • Stop all Veeam Services.
  • Backup the Enterprise Manager database using pgdump from an elevated powershell console to the directory of your choice.

& "C:\Program Files\PostgreSQL\15\BIN\pg_dump.exe" -U postgres -F c -b -f "C:\BACKUPS\VBEM DB BACKUP\PGDBBackup_$($env:computername)_$(get-date -f yyyy-MM-dd_HH.mm).sql" VeeamBackupReporting

 

  • Remove the Enterprise Manager server from the Production Domain and reboot.
  • Ensure that the Enterprise Manager server was properly removed from the Production Domain.
  • Validate that you can still connect to the database with DBconfig.

Note: If you run into a “SSPI authentication failed for user” then modify the pg_ident.conf with the account used to log in.

For instance, you can add the local administrator used to login to Enterprise Manager to pg_ident.conf (see kb4542).

  • Edit the following registry keys with Enterprise Manager’s machine name.

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup Reporting\EnterpriseServerName

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup Reporting\XMLURL

  • Note that HTTP access works but the certificate must be fixed to enable HTTPS access (see kb1168).
  • Remove Production Domain accounts and groups.
  • Add a static DNS entry for Enterprise Manager on the Production Domain DNS.
  • Note that after VBR has been removed from the Production Domain it will be disconnected.

To reinstate the connection to the VBR server one can:

    • After joining the Backup Workgroup, add a static DNS entry on the Production DNS server and update every Veeam Server’s primary DNS suffix to match the Production Domain.

Note: Alternatively, DNS can be handled with local hosts files (more cumbersome).

  • Edit the connection by using VBR local administrator credentials.
  • Note that the connection vCenter is broken. Follow similar DNS steps to fix the connection.

Veeam Backup and Replication

  • Add the VBR local admin as a Veeam Backup Administrator (BUILTIN\Administrators group is not enough)
  • Wait for all jobs to complete.
  • Backup the Veeam Backup and Replication server config. Make sure encryption is enabled.
  • Disable running jobs (CDP, T-Logs, BCJ …) and close the console.
  • Remove Veeam Backup and Replication server from the Production Domain and reboot.
  • Ensure that the Veeam Backup and Replication server was properly removed from the Production Domain.
  • Update VBR’s DNS records, either on the Production’s domain DNS or in a local hosts file.

Domain joined CDP proxy

  • After joining the Backup Workgroup, add a static DNS entry on the Production DNS server.
  • Under Managed Server, update the CDP proxy credentials.
  • Note that the I/O filters are still managed by VBR registered with the Production FQDN.

 

 

 

App-Aware Backups and Domain joined Guest Interaction Proxy

WARNING: Leave the Guest Interaction Proxy on the Production Domain as stated in the Veeam documentation in order for Application-Aware backups to function properly.

If the Guest Interaction Proxy is removed for the Production Domain, Veeam will fail to inject the necessary runtimes and Application Aware backups will fail.

 

 

Domain joined Proxy

  • Remove the proxy from the Production Domain and ensure that the server has been removed from the Production Domain AD.
  • Note that the proxy is no longer available.
  • Ensure proper DNS resolution by either updating the local hosts file on all Veeam Servers or by adding a static entry on your Production Domain’s DNS. Adding DNS suffix is also recommended.
  • Update the proxy server’s credentials using a local account.

 

 

Domain joined Gateway or Repository

  • Remove the proxy from the Production Domain and ensure that the server has been removed from the Production Domain AD.
  • Note that the server is no longer available.
  • Ensure proper DNS resolution by either updating the local hosts file on all Veeam Servers or by adding a static entry on your Production Domain’s DNS. Adding DNS suffix is also recommended.
  • Update the server’s credentials using a local account.

Summary

In this blog post, we provided detailed step by step instructions to Migrate the Veeam Infrastructure OFF the Production Domain onto a Child Domain.

Moving to a Child Domain only satisfies a requirement to be off Production Domain, however a Child Domain and its Parent have a two-way transitive trust; therefore, it is not the most secure option.

Moving Veeam to a Workgroup or onto a separate Backup Domain with a one-way trust to the Production Domain offer a better approach to security domain separation.

Stay tuned for part 4 of this series. Coming up next:

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

Great to see part 3 of this series.  It is interesting to see the Workgroup option as we are doing a segragated domain for Veeam in our migration.

Another fine, detailed post @olivier.rossi . I think one can create a Hosts file with all components and just copy it to all Veeam components, yes?

Also, I think, just to make sure no one gets confused, in the part you talk about the local Administrators group not being good enough, maybe should add the ‘s’ to the word Administrator? (BUILT\Administrator → BUILT\Administrators). Unless I misunderstood it 😊

@coolsport00 Good catch on the typo. Thank you. I have made the correction.

@coolsport00 Good catch on the typo. Thank you. I have made the correction.

No problem Olivier...just didn’t want anyone to get confused 😊 Again, great posts!

I love this… I am compelled to reference this on a “Defence in Depth” blog post I am working on. Hopefully, I can share this next week as this topic covers an aspect of it/best practices for deploying VBR but is not sufficient to protect the VBR server.

Comment


Terms & Conditions